Effingo: データを大規模に移動する Google の内部コピーサービス

※この投稿は米国時間 2023 年 5 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

毎日、毎時間、Google は世界中で大量のデータを移動しています。これには、Google Cloud のお客様に代わって内部でデータを移動する Google 専用のサービス、Effingo（ラテン語で「複製」または「コピー」を意味する）のデータコピー サービスが使用されています。

Google Cloud をご利用の皆様は、おそらく Storage Transfer Service を使用してデータを移動されていることと思います。Storage Transfer Service は、そのまま使用できるセキュリティ、信頼性、パフォーマンスを提供するマネージド転送オプションです。スクリプトの最適化や保守、再試行の処理を行う必要がなくなることに加え、別々のプロジェクトのデータを統合したり、データをバックアップ場所に移動したり、データの場所を変更したりするのに役立ちます。

Google の内部サービスもまた、データを管理する上でよく似た機能を必要としています。これには、BigQuery や Cloud Spanner などの Google Cloud サービスのエコシステムを担うデータが含まれます。

Effingo は、さまざまなトラフィック特性、ならびにデータ複製、耐久性、レイテンシに関連するさまざまな要件をもつ幅広いワークロードをサポートし、グローバル規模のデータ移動に伴う難題を解決します。この投稿では、データ移動の背後にある主な動機と、日常的にエクサバイトのデータをコピーするなかで直面するコア インフラストラクチャの問題に対処するソリューションについて取り上げます。

データを移動するそもそもの理由

まず、なぜデータを移動したり、地理的に分散したりする必要があるのか考えてみましょう。

1 つ目は、データを複製しておくことで耐久性と信頼性を確保するためです。当然ながら、データのコピーを 1 つしか保管していないとリスクが高まります。結局のところ、ファイルが保存されているのはハードドライブだからです。どのようなハードドライブであっても、いつか故障する可能性があります。そのため、複数のコピーを別々の場所に保管しておけば、どんな時でもファイルのコピーを読み取ることができます。また、それぞれの保管場所を互いに地理的に離れた場所にすることで、自然災害、ネットワークの切断といった特定の地域に影響を及ぼす恐れのあるインシデントによる一時的なデータの損失を回避できます。

2 つ目は、データとユーザーの距離を近くすることで、レイテンシを短縮するためです。優れたユーザー エクスペリエンスを提供するには、レイテンシを最小限に抑えてデータを提供する必要があります。遠隔地からのデータ転送に起因するレイテンシにより、アプリケーションの利便性が損なわれたり、サービスが機能していないと認識されたりすることが多々あります。Google の調査によると、モバイル ユーザーの 53% が、読み込みに 3 秒以上かかるサイトを放棄しています。データの近接性が低いことによる影響は他にもあります。たとえば、離れた場所からデータを転送するとネットワーク リソースの浪費につながり、環境に悪影響を及ぼす可能性があります。Google は 2007 年以来、事業におけるカーボン ニュートラルを実践しており、2017 年からは毎年、事業で消費する電力の 100% を再生可能エネルギーを購入してまかなっています。そしてさらに高い目標を掲げ、2030 年までにすべてのデータセンターとオフィスの運営を 24 時間 365 日カーボンフリー エネルギーで行えるようにすることを目指しています。

データを地理的に分散する 3 つ目の理由は、クラスタ間のストレージ容量のバランスを取ることです。これにより、データセンターの全体的な容量を増やし、負荷の少ないクラスタの演算能力を使用できるため、データ保存の費用が削減されます。さらに、無駄なリソースの量を制限し、アイドル状態のハードウェアを別の目的に使用できます。これは特に、正確な保存場所がそれほど重要ではないバッチ処理やコールドデータの保存に適しています。

課題

Google が行っているような大規模な運用では、いくつかの理由からデータの移動が難題になっています。例を挙げてみましょう。

データは、転送先において安全で一貫性が必要ですが、これには複雑な条件が伴います。たとえば、ある場所から別の場所にファイルをコピーするには、ディスクの読み取りと書き込みを行うためのスループット、データセンター間でバイトを転送するためのネットワーク容量、操作全体を計測するためのコンピューティング リソースが必要です。

Google が運用するデータの量を考慮すると、スループットが高く、予測可能なことは大規模なコピーサービスの重要な機能の一つです。通常、1 秒あたり数テラバイトのデータが転送されるため、パターンが急激に変化するトラフィックを処理できるスケーラブルなサービスが不可欠です。このようなサービスを実行し、リソース効率を維持するにはどうしたらいいのか、という疑問も出てきます。

最後に、高いシステム可用性を確保することが重要です。Google のインフラストラクチャは動的であるため、任意の 2 つのクラスタ間でデータをコピーする動作は、その時々で異なる場合があります。Effingo は、クラスタの停止、ネットワークのボトルネック、リソースの需要と容量の急速な変化などに柔軟に対応する必要があります。

こうした問題の（いくつかの）解決方法

データ移動の主なユースケースの一つは複製です。データの信頼性を確保するには、複数のコピーを保管し、理想的には別々の場所に保持して、データ損失の可能性を低くします。

次の例を考えてみましょう。クラスタ A にファイルがあり、転送先である B から G にコピーを作成したいと考えているとします。

単純なアプローチを採るならば、すべての転送先に並行してコピーを開始します。

残念ながら、この方法でファイルを複製するのは極めて非効率です。このソリューションは拡張性がなく、インフラストラクチャに多額の投資が必要になります。

ネットワーク インフラストラクチャの費用を考慮すると、海を越えてのデータ移動は高額な出費を伴う操作です。Effingo は、海を越えて転送するデータの量を減らすデータ転送計画を作成します。可能であれば、すでに複製されているデータを新しいソースとして再利用します。

データ転送計画を作成するにあたり、Effingo は代替データソースとネットワーク トポロジを把握する必要があります。

代替ソースに移動する場合、Effingo は、転送されたファイルの最近の履歴を、メタデータと、ファイルにアクセスするための期限付きのアクセス許可と一緒に保存します。新しいコピーが発行されるたびに、Effingo は同じソースとして機能する元ファイルのコピーが、別の場所に存在するかどうかを確認します。注目すべきは、Effingo は、高度なセキュリティ基準に準拠するために、両方のファイル（要求されたソースファイルと代替の転送ファイル）が実際に同じであることを非常に厳格に検証している点です。Effingo は、同じユーザーが同じソースからコピーを発行したかどうかを確認するだけでなく、チェックサム、暗号テキスト チェックサム、mtime などのファイル プロパティが一致するかどうかも検証します。

ソースファイルとその代替ソースを把握すると、Effingo は Google ネットワーク経由で転送計画を作成します。Effingo には、ノードがそれぞれ場所を表し、エッジがそれぞれ各ノードを重み付きで連結するグラフ形式のネットワーク モデルがあります。コピーごとに、Effingo はそのようなグラフ上に最小全域木を作成し、転送エンジンへの入力として使用します。このアプローチのおかげで、コピーごとに最適なプランを選択できます。  

次の例では、より効率的なアプローチを紹介します。Effingo は、最初に高額な出費を伴うコピーを遠隔地に作成し、次にそれを新しいソースとして使用します。たとえば、Effingo は最初にファイルを米国（ソース A）からヨーロッパ（転送先 C）にコピーし、次にヨーロッパに所在するファイルをコピーソースとして使用して、同じ大陸内でコピーを作成します。なお、Effingo が最適化のためにファイルを一時的な場所に保存することはありません。このサービスでは、ユーザーが明示的にリクエストした場所のみが使用されます。

リソースの効率に加えて、主な課題は、データ転送の高いスループットを確保することです。Effingo は、発生する可能性のあるさまざまな問題に対処するいくつかのアプローチを適用することで、この問題を解決しています。

前述のように、ユーザーのワークロードはさまざまなトラフィック パターンを示し、その結果、各ネットワーク リンクの容量が動的に変化します。そのため、Effingo はリソースの可用性の変化に対応するだけでなく、そのような状況におけるユーザーの公平性も確保する必要があります。すなわち、Effingo は、リソースを可能な限り最適な方法で使用しながら、コピー操作をそれぞれ同時に進行させる必要があります。これを実現するために、高度な並列処理制御が使用されます。この制御は、サービスの過負荷、パフォーマンスの低下、またはリソースの無駄が発生した場合に、需要の増加に対応し、サービスの容量を制限するためにサービスをスケールアップします。

さらに、Effingo には優れた復元力と、エラーへの迅速な対応が必要になります。ファイルレベルでは、一時的な障害に対して広範囲に再試行を使用し、再試行不可能なエラーを検出した場合は転送をすぐに中止します。Effingo は、指標、ログ、その他のオブザーバビリティ シグナルを使用して、必要に応じてデータ転送を調整します。たとえば、特定のソースからのコピーが遅いことや、別のファイル レプリカが利用可能であることを検出できます。そこから、Effingo はコピー操作を再構成し、他のレプリカを使用してデータの移動を完了します。

グローバル規模でのデータの移動は難題である

以上の説明から、グローバル規模で運用されている Google のインフラストラクチャにとって、データの移動が難題である理由について理解を深めていただければ幸いです。Effingo は、Google Cloud サービスや Google の多くの内部サービスをはじめ、Google インフラストラクチャで実行されるさまざまなサービスをサポートしています。データを大規模に移動するには、リソースの使用と復元力に細心の注意を払い、高いスループットに対応する必要があります。Google はこの問題に継続的に取り組んでおり、インフラストラクチャを日々改善して、Google Cloud でビジネスを運営するユーザーの皆様に、すべてのデータ移動に対する透明性を提供しています。