このページでは、ファイル システム転送のベスト プラクティスについて説明します。
パフォーマンスに関するベスト プラクティス
良好な転送パフォーマンスを維持するため、次のことをおすすめします。
サイズの大きなデータコーパス（少なくとも 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 時間以上かかる大規模な転送を開始します。たとえば、少なくとも 10 万個のファイルで、合計サイズが 100 GB 以上の転送を開始します。
スループットが安定するまで待機し、WAN の容量や帯域幅の上限で制限されているかどうかを判断します。
WAN の容量不足で、目的の転送上限に達していない場合は、別のエージェントを追加します。エージェントを追加することで、転送のスループットが自動的に向上します。Cloud Monitoring でスループットが安定するまでに 3 分ほどかかります。
手順 3 と 4 を繰り返して、目的の上限に達するまで一度に 1 つずつエージェントを追加します。計算リソース、ファイル システム、ネットワーク リソースが使用可能であれば、エージェント プールごとに最大 100 個のエージェントを同時に実行できます。
必要な上限に達する前に送信帯域幅が飽和した場合は、次のいずれかを行います。
エージェントを追加してもスループットが向上しない場合、WAN が飽和状態でなければ、ファイル システムのスループットを調査します。まれに、ファイル システムのスループットが飽和し、転送パフォーマンスを向上できない場合があります。
エージェント名の設定方法
エージェント名を指定する場合は、次のことをおすすめします。
エージェント名に必ずホスト名を含めます。これは、エージェントが実行されているマシンの特定に役立ちます。
--hostname=$(hostname)を Docker のrunコマンドに渡すことをおすすめします。モニタリングやインフラストラクチャ統合のコンテキストでエージェントの識別に役立つエージェント接頭辞スキームを選択します。例:
3 つの転送プロジェクトがある場合、チーム名をエージェントに含めます。例:
logistics2 つのデータセンターでそれぞれ異なる転送プロジェクトを実行する場合、エージェント接頭辞にデータセンター名を含めます。例:
omaha