クライアント ライブラリを使用してアップロードとダウンロードを高速化
Andrew Gorcester
Senior Software Engineer
Vivek Saraswat
Group Product Manager, Cloud Storage
※この投稿は米国時間 2024 年 7 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。
分析や AI / ML など大量のデータを処理するアプリケーションは Google Cloud Storage で急速に成長しているワークロードですが、これらのワークロードの高いスループットを確保するのは簡単ではありません。Cloud Storage クライアント ライブラリ transfer manager は、主要なクライアント ライブラリにアップロードとダウンロードを並列化する機能を追加することで、ワークロードのスループットを最大化します。
新しい transfer manager モジュールは、スレッドまたはプロセスで複数のワーカーを使用し、スループットを最大化します。Cloud Storage のコマンドライン インターフェース（例: gcloud storage）は、必要に応じてアップロードとダウンロードの両方を自動的に並列化しますが、フルマネージドの並列化は最近まで Cloud Storage クライアント ライブラリでは使用できませんでした。
transfer manager モジュールは Java、Node.js、Python 向けに一般提供されており、Go への対応はプレビュー版で提供されています。それ以外の言語のサポートについても現在開発中です。この投稿では、Cloud Storage クライアント ライブラリ transfer manager の機能により、Sequential モデルと比較してメディア オペレーションのパフォーマンスが向上する事例をいくつか紹介します。多くの場合、パフォーマンスは劇的に向上します。
クライアント ライブラリによる並行処理の実行
Cloud Storage クライアント ライブラリの transfer manager は、複数のファイルを 1 つずつループで処理するのではなく、オペレーションを一度に同時実行できます。ファイルと blob の組み合わせを受け入れるメソッドのほかに、transfer manager にはフォルダ全体を一度にアップロードまたはダウンロードする便利なメソッドもあります。詳しくは、以下の「使ってみる」セクションのドキュメントをご覧ください。
サイズの大きいファイルを含むワークロードの場合は、transfer manager は「分割統治」の戦略により、ファイルのデータをシャードに分割し、すべてのシャードを同時に転送します。分割によるダウンロードは、範囲を限定した読み取りにより実装されています。使用しているクライアント ライブラリによって XML マルチパート アップロード API または gRPC compose API のどちらかをアップロード オペレーションで使用します。
出典: Graffle diagram
パフォーマンス上のメリット
並列処理を構成してさまざまな運用環境およびワークロードに対応できます。構成時の変数の設定により、transfer manager のパフォーマンスへの影響は異なります。並行処理でスレッド、プロセス、コルーチンのどれを使用するかはプログラム言語によって決まります。
通常の転送から transfer manager による転送に切り替えることで、アプリケーションで同時に大量のデータを移動する必要のある場合に大きな影響があります。転送するオブジェクト数が多ければ多いほど、またはオブジェクトのサイズが大きければ大きいほど、あるいはその両方の場合において、アプリケーションが受けるメリットも大きくなります。
たとえば、大量の 16 KB 未満のファイルを 64 個のワーカーを使用して c3-highcpu-8 Compute Engine インスタンスでダウンロードする場合、Python ライブラリの transfer manager モジュールでは、単一のワーカーで処理する場合と比較して 50 倍のスループットを実現しました。テストの結果、多数のワーカーを使うことは、ファイルが非常に小さい場合に最も効果的であるとわかりました。この例では、比較的小さいインスタンスに対して極端に多数のワーカーを使用しましたが、ワーカー数を減らした場合でもパフォーマンスが大幅に向上します。
同じインスタンスで、よりサイズの大きい 64 MB のファイルをワーカーを 8 個まで減らして移動した場合、Cloud Storage クライアント ライブラリ transfer manager により、最初のベースラインが前の例より高いにもかかわらずスループットが 4.5 倍に向上しました。チャンクサイズ 32～64 MB にシャーディングされたアップロードの場合も同様のパフォーマンスが得られました。
特定のワークロードに対してスループットを向上させる最適な構成は、ネットワーキングのレイテンシ、CPU のタイプ、メモリによって異なります。たとえば、Compute Engine インスタンスにもさまざまなネットワーキング構成があり、CPU、メモリリソースもさまざまです。同様に、Compute Engine の外部から Cloud Storage にアクセスする場合は、ネットワークのスループットとラウンドトリップ時間について、根本的に異なる制限があります。
使ってみる
Cloud Storage クライアント ライブラリ transfer manager の利用を開始するには、主なユースケースのコードサンプル、各クライアント ライブラリ向けの API リファレンス ドキュメントをご覧ください。
新しいクライアント ライブラリの機能により問題が解決できたか、向上が見られたかどうか、皆様からのフィードバックをお待ちしております。フィードバックを提供するには、Cloud Storage クライアント ライブラリのドキュメントページにある [フィードバックを送信] ボタンをクリックするか、クライアント ライブラリのリポジトリにある GitHub の問題からご連絡ください。
