Cloud Storage バケット間の転送

Storage Transfer Service を使用すると、同じ Google Cloud プロジェクト内、異なるプロジェクト間、さらに Cloud Storage バケット間でも大量のデータを転送できます。

バケットの移行は、さまざまなシナリオにおいて有用です。たとえば、個別のプロジェクトからのデータを統合したり、データをバックアップのロケーションに移動したりする場合に使用できます。また、データのロケーションを変更する場合にも使用可能です。

Storage Transfer Service の用途

Google Cloud では、Cloud Storage バケット間でデータを転送するための複数のオプションが用意されています。次のガイドラインに従うことをおすすめします。

• 1 TB 未満のデータ転送: gcloud を使用します。手順については、バケットの移動と名前の変更をご覧ください。

• 1 TB を超えるデータ転送: Storage Transfer Service を使用します。Storage Transfer Service は、すぐに使用できるセキュリティ、信頼性、パフォーマンスを提供するマネージド転送オプションです。これにより、スクリプトの最適化や保守、再試行の処理を行う必要がなくなります。

このガイドでは、Storage Transfer Service を使用して Cloud Storage バケット間でデータを転送する際のベスト プラクティスについて説明します。

転送方法を定義する

転送方法は、状況の複雑さによって異なります。計画を作成する際は、次の点を考慮してください。

バケット名を選択する

別の場所にあるストレージ バケットにデータを移動するには、次のいずれかの方法を選択します。

• 新しいバケット名を指定する。別の名前のストレージ バケットを参照するようにアプリケーションを更新します。
• バケット名を維持する。ストレージ バケットを置き換えて現在の名前を維持します。アプリケーションを更新する必要はありません。

どちらの場合もダウンタイムを計画し、ダウンタイムが発生することをユーザーに適切に通知する必要があります。次の説明を確認して、最適な選択肢を選択してください。

新しいバケット名

現在のバケットを使用するすべてのコードとサービスを新しいバケット名で更新する必要があります。この方法は、アプリケーションの構築方法とデプロイ方法によって異なります。

一部の設定では、この方法でダウンタイムが短縮される可能性がありますが、スムーズな移行を実現するために、多くの作業が必要になります。次の作業を行います。

1. 新しいストレージ バケットにデータをコピーする。
2. ダウンタイムを開始する。
3. 新しいバケットを参照するようにアプリケーションを更新する。
4. すべてが想定どおりに動作することを確認する。関連するすべてのシステムとアカウントがバケットにアクセスできることを確認する。
5. 元のバケットを削除する。
6. ダウンタイムを終了する。

バケット名を維持する

新しいバケット名を参照するようにコードを変更しない場合は、この方法を使用します。次の作業を行います。

1. 一時ストレージ バケットにデータをコピーする。
2. ダウンタイムを開始する。
3. 元のバケットを削除する。
4. 元のバケットと同じ名前の新しいバケットを作成する。
5. 一時バケットから新しいバケットにデータをコピーする。
6. 一時バケットを削除する。
7. すべてが想定どおりに動作することを確認する。関連するすべてのシステムとアカウントがバケットにアクセスできることを確認する。
8. ダウンタイムを終了する。

ダウンタイムの最小化

Storage Transfer Service は、転送中に転送元バケットまたは転送先バケットに対する読み取りまたは書き込みをロックしません。

バケットの読み取り / 書き込みを手動でロックする場合は、2 段階（シードと同期）でデータを転送することで、ダウンタイムを最小限に抑えることができます。

1. シード転送: ソースに対して読み取り / 書き込みをロックすることなく、一括転送を実行します。

2. 同期転送: 最初の実行が完了したら、ソースバケットで読み取り / 書き込みオペレーションをロックし、別の転送を実行します。Storage Transfer Service の転送はデフォルトで増分的であるため、この 2 回目の転送では、シード転送中に変更されたデータのみが転送されます。

転送速度を最適化する

転送ジョブにかかる時間を見積もるときは、考えられるボトルネックを考慮してください。たとえば、ソースに数十億の小さなファイルがある場合、転送速度は QPS の制約を受けます。オブジェクトのサイズが大きいと、帯域幅がボトルネックになるおそれがあります。

帯域幅の上限はリージョン レベルで設定され、すべてのプロジェクトに公平に割り当てられます。十分な帯域幅がある場合、Storage Transfer Service は 1 秒あたり約 1,000 個のタスクを処理できます。この場合、たとえば、包含接頭辞と除外接頭辞を使用して特定のファイルを転送するなど、ジョブを複数の小さな転送ジョブに分割することで転送を高速化できます。

ロケーション、ストレージ クラス、暗号鍵が同じである場合、Storage Transfer Service はバイトの新しいコピーを作成しません。代わりに転送元 blob を指す新しいメタデータ エントリを作成します。その結果、大規模なコーパスの同じロケーションとクラスのコピーが QPS の制約内で非常に迅速に完了します。

削除もメタデータのみのオペレーションになります。このような転送では、転送を複数の小さなジョブに分割して並列処理することで、速度が向上します。

メタデータを保持する

次のオブジェクト メタデータは、Storage Transfer Service を使用して Cloud Storage バケット間でデータを転送するときに保持されます。

• ユーザー作成のカスタム メタデータ。
• Cache-Control、Content-Disposition、Content-Type、Custom-Time などの Cloud Storage 固定キー メタデータ フィールド。
• オブジェクト サイズ。
• 世代番号は、キー x-goog-reserved-source-generation を持つカスタム メタデータ フィールドとして保持され、後で編集や削除ができます。

API を使用して転送する場合、必要に応じて次のメタデータを保持できます。

• ACL（acl）
• ストレージ クラス（storageClass）
• CMEK（kmsKey）
• 一時保留（temporaryHold）
• オブジェクトの作成日時（customTime）

詳しくは、TransferSpec API リファレンスをご覧ください。

次のメタデータ フィールドは保持されません。

• 最終更新時刻（updated）
• etag
• componentCount

保持する場合、オブジェクト作成時間はカスタム フィールド customTime として保存されます。オブジェクトの updated 時間は転送時にリセットされるため、オブジェクトのストレージ クラスで費やされた時間もリセットされます。つまり、早期削除の料金が発生しないように、転送後、Coldline Storage のオブジェクトは転送先で 90 日間存在する必要があります。

customTime を使用して、createTime ベースのライフサイクル ポリシーを適用できます。既存の customTime 値は上書きされます。

保持される内容と保持されない内容の詳細については、メタデータの保持をご覧ください。

バージョニングされたオブジェクトを処理する

最新のストレージ オブジェクトだけでなく、すべてのバージョンのストレージ オブジェクトの転送を行う場合は、Storage Transfer Service の マニフェスト機能を使用できます。

すべてのオブジェクト バージョンを転送するには:

1. バケット オブジェクトを一覧表示して、JSON ファイルにコピーします。

   gcloud storage ls --all-versions --recursive --json [SOURCE_BUCKET] > object-listing.json
   

   このコマンドは通常、1 秒あたり約 1,000 個のオブジェクトをリストします。

2. 現在のオブジェクト以外のオブジェクトを CSV ファイルにコピーします。

   jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted"))) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > non-current-object-manifest.csv
   

3. 転送先のバケットでオブジェクトのバージョニングを有効にします。

4. 次の転送オプションを使用して、現在のバージョン以外のバージョンを転送します。

   • マニフェスト ファイルを指定します。
   • シンク内のオブジェクトを常に上書きするように選択します（OVERWRITE_WHEN=always）。まれに、ファイルの重複バージョンが作成されることがあります。
   • timeCreated メタデータを保持します (MetdataOptions.timeCreated=TIME_CREATED_PRESERVE_AS_CUSTOM_TIME)。

5. 通常の転送ジョブを使用して、ライブ バージョンを転送します。

転送オプションを構成する

転送を設定するときに使用できるオプションは次のとおりです。

• ロギング: Cloud Logging では、個々のオブジェクトの詳細なログが記録されます。このログを使用して、 転送のステータスを確認し、追加データの完全性チェックを実行できます。

• フィルタリング: 包含接頭辞と除外接頭辞を使用して、Storage Transfer Service の対象オブジェクトを制限できます。このオプションを使用すると、転送を複数の転送ジョブに分割し、並列実行できるようになります。詳細については、転送速度を最適化するをご覧ください。

• 転送オプション: 転送先バケット内の既存のアイテムを上書きするように転送を構成できます。この方法で、転送セットに存在しない転送先のオブジェクトを削除することも、転送されたオブジェクトを転送元から削除することもできます。

データを転送する

転送方法を定義したら転送を実行できます。

新しいバケットを作成する

転送を開始する前に、ストレージ バケットを作成します。適切なバケットのロケーションについては、ロケーションに関する考慮事項をご覧ください。

新しいバケットを作成するときに、いくつかのバケット メタデータをコピーすることをおすすめします。転送元バケットのメタデータを表示する方法については、バケット メタデータの取得をご覧ください。これにより、新しいバケットに同じ設定を適用できるようになります。

新しいバケットにオブジェクトをコピーする

コンソール、gcloud CLI、REST API、またはクライアント ライブラリを使用して、転送元バケットから新しいバケットにオブジェクトをコピーできます。 Google Cloud どの方法を選択するかは転送方法によって異なります。

次の手順は、バケット間でオブジェクトを転送する基本的なユースケースを想定しているため、ニーズに合わせて変更する必要があります。

転送ジョブ名に、個人を特定できる情報（PII）やセキュリティ データなどの機密情報を含めないでください。リソース名は、他の Google Cloud リソースの名前に反映され、プロジェクト外部の Google 内部システムに公開される場合があります。

gcloud init

gcloud storage buckets add-iam-policy-binding gs://bucket_name \
--member=serviceAccount:project-12345678@storage-transfer-service.iam.gserviceaccount.com \
--role=roles/storage.admin

gcloud transfer jobs create SOURCE DESTINATION

gcloud transfer jobs create gs://old-bucket gs://new-bucket \
  --include-prefixes="folder1/"

POST https://storagetransfer.googleapis.com/v1/transferJobs
{
  "description": "YOUR DESCRIPTION",
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "schedule": {
      "scheduleStartDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      },
      "startTimeOfDay": {
          "hours": 1,
          "minutes": 1
      },
      "scheduleEndDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      }
  },
  "transferSpec": {
      "gcsDataSource": {
          "bucketName": "GCS_SOURCE_NAME"
      },
      "gcsDataSink": {
          "bucketName": "GCS_SINK_NAME"
      },
      "transferOptions": {
          "deleteObjectsFromSourceAfterTransfer": true
      }
  }
}

200 OK
{
  "transferJob": [
      {
          "creationTime": "2015-01-01T01:01:00.000000000Z",
          "description": "YOUR DESCRIPTION",
          "name": "transferJobs/JOB_ID",
          "status": "ENABLED",
          "lastModificationTime": "2015-01-01T01:01:00.000000000Z",
          "projectId": "PROJECT_ID",
          "schedule": {
              "scheduleStartDate": {
                  "day": 1,
                  "month"