ファイル システム転送のベスト プラクティス

このページでは、ファイル システム転送のベスト プラクティスについて説明します。

パフォーマンスに関するベスト プラクティス

良好な転送パフォーマンスを維持するため、次のことをおすすめします。

  • 転送エージェントのパフォーマンスを最大にします

  • サイズの大きなデータコーパス(少なくとも 100 GB)を転送して、パフォーマンスのベンチマーク評価を行います。

    Storage Transfer Service はスループットが最適化された大規模なサービスです。小規模なテスト データセットのパフォーマンスから、本番環境での大きなデータセットのパフォーマンスを判断することはできません。

  • 個々のソースフォルダ内のファイル数を 100 万個に制限します。数百万のファイルを含むディレクトリがあると、転送全体の速度が低下する可能性があります。

  • リソースの消費量を効果的にスケーリングできるように、エージェントを個別の仮想マシン(VM)で実行します。

  • エージェント マシンのネットワーク インターフェースのサイズが、必要な読み取り / 書き込み帯域幅に応じて設定されていることを確認します。

    たとえば、20 Gbps の広域ネットワーク(WAN)を最大限活用するには、エージェント マシンのネットワーク インターフェースは、ネットワーク ファイル システムからのデータの読み取りに 20 Gbps を使用し、さらに Cloud Storage へのデータ転送に 20 Gbps を使用する必要があります。つまり、合計で 40 Gbps の帯域幅が必要になります。

  • 他のワークロードでマシンが過負荷状態にならないように、エージェント マシンの CPU、メモリ、ネットワークをモニタリングします。過負荷状態になると、パフォーマンスが低下する可能性があります。推奨されるメモリと CPU の数については、エージェントのハードウェア要件をご覧ください。

マルチパート アップロード

POSIX ファイル システムから Cloud Storage への転送、または POSIX ファイル システム間の転送では、マルチパート アップロードの有効化を検討してください。マルチパート アップロードでは、大きなファイル(1 MiB 超)を小さなパーツに分割し、それらを並列でアップロードすることで、サイズの大きいファイルを含む転送を最大 300% 高速化できます。

HDFS および S3 互換のファイル システムでは、マルチパート アップロードはサポートされません。

マルチパート アップロードを有効にする

マルチパート アップロードを有効にするには:

  • 転送エージェントを承認するアカウント(ユーザー アカウントまたはサービス アカウント)に必要な権限を割り当てる必要があります。

  • 転送先バケットまたは中間バケットに保持ポリシーやオブジェクト保留を設定することはできません。

有効にすると、Storage Transfer Service は、マルチパート アップロードを自動的に使用します。これにより、転送が高速化される可能性があります。

マルチパート オブジェクト ライフサイクル ルールを構成する

Cloud Storage オブジェクトのライフサイクル管理を使用すると、不完全なマルチパート アップロードを中止して、関連するパーツを削除できます。Cloud Storage ドキュメントの不完全なマルチパート アップロードの中止をご覧ください。

age の値を 7 日に設定することをおすすめします。

マルチパート アップロードを無効にする

マルチパート アップロードを無効にするには、docker run を使用して転送エージェントを再インストールし、--enable-multipart=false を渡します。

sudo docker run --ulimit memlock=64000000 -d --rm \
-v /usr/local/research:/usr/local/research \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--agent-pool=AGENT_POOL \
--creds-file=CREDENTIAL_FILE \
--hostname=$(hostname) \
--enable-multipart=false

次のように置き換えます。

  • PROJECT_ID には、転送をホストしているプロジェクト ID を指定します。
  • CREDENTIAL_FILE: 転送エージェントが認証にサービス アカウントを使用する場合は、JSON 形式のサービス アカウントの認証情報ファイルのパスを指定します。

あるいは、転送エージェントを認可するユーザー アカウントまたはサービス アカウントのアカウントから必要な権限を取り消します

転送エージェントのパフォーマンスを最大にする

転送のパフォーマンスは、次の要因によって変わります。

  • ファイル システムの機能。

  • 基盤となるハードウェアの制限。

    ハードドライブのメディアタイプ、入出力バス、ローカルエリア ネットワーク(LAN)の接続状況もパフォーマンスに影響します。

  • WAN のスループットと使用率

    WAN の処理速度が遅い場合や使用率が高い場合、パフォーマンスが低下します。

  • ファイルの特性。

    たとえば、ネットワークのオーバーヘッドのため、サイズの小さいファイルを大量に処理する場合よりも、サイズの大きなファイルのほうがネットワーク スループットが高くなります。

こうした要因があるため、実際のパフォーマンスを予測することや、最適なエージェント数を示すことはできません。

少なくとも 3 つのエージェントを使用することにより(できれば別々のマシンで)、転送をフォールト トレラントにすることをおすすめします。転送の実行中に転送エージェントを追加することで、パフォーマンスを動的に向上させることができます。

エージェントの追加による影響を確認し、環境に最適なエージェント数を選択するには、次の操作を行います。

  1. 1 時間以上かかる大規模な転送を開始します。たとえば、少なくとも 10 万個のファイルで、合計サイズが 100 GB 以上の転送を開始します。

  2. Cloud Monitoring でエージェントの全体的なスループットをモニタリングします

  3. スループットが安定するまで待機し、WAN の容量や帯域幅の上限で制限されているかどうかを判断します。

  4. WAN の容量不足で、目的の転送上限に達していない場合は、別のエージェントを追加します。エージェントを追加することで、転送のスループットが自動的に向上します。Cloud Monitoring でスループットが安定するまでに 3 分ほどかかります。

手順 3 と 4 を繰り返して、目的の上限に達するまで一度に 1 つずつエージェントを追加します。計算リソース、ファイル システム、ネットワーク リソースが使用可能であれば、エージェント プールごとに最大 100 個のエージェントを同時に実行できます。

必要な上限に達する前に送信帯域幅が飽和した場合は、次のいずれかを行います。

エージェントを追加してもスループットが向上しない場合、WAN が飽和状態でなければ、ファイル システムのスループットを調査します。まれに、ファイル システムのスループットが飽和状態になり、転送パフォーマンスを向上できない場合があります。

エージェント名の設定方法

エージェント名を指定する場合は、次のことをおすすめします。

  • エージェント名に必ずホスト名を含めます。これは、エージェントが実行されているマシンの特定に役立ちます。--hostname=$(hostname) を Docker の run コマンドに渡すことをおすすめします。

  • モニタリングやインフラストラクチャ統合のコンテキストでエージェントの識別に役立つエージェント接頭辞スキームを選択します。例:

    • 3 つの転送プロジェクトがある場合、チーム名をエージェントに含めます。例: logistics

    • 2 つのデータセンターでそれぞれ異なる転送プロジェクトを実行する場合、エージェント接頭辞にデータセンター名を含めます。例: omaha