バケットを再配置する

このページでは、バケットをあるロケーションから別のロケーションに再配置するプロセスについて説明します。バケットの再配置については、バケットの再配置をご覧ください。

始める前に

バケットを再配置する前に、次のことを完了します。

1. Storage Intelligence を構成します。

2. 削除（復元可能）を有効にします。

3. 割り当てと上限を確認して、新しいロケーションにバケットのデータに対応できる十分な割り当てがあることを確認します。

4. バケットの再配置タイプを決定して、書き込みのダウンタイムが必要かどうかを確認します。

5. 既存のバケットタグを削除します。

6. インベントリ レポートを使用する場合は、構成を保存します。

7. 次のセクションで説明する必要なロールを取得します。

必要なロールを取得する

バケットの再配置に必要な権限を取得するには、プロジェクトに対するストレージ管理者（roles/storage.admin）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

この事前定義ロールには、バケットの再配置に必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

バケットを再配置する

このセクションでは、Cloud Storage バケットをあるロケーションから別のロケーションに再配置するプロセスについて説明します。バケットを再配置する場合は、増分データコピー プロセスを開始してモニタリングし、最終同期ステップを開始します。これらの手順の詳細については、バケットの再配置プロセスを理解するをご覧ください。

ドライランの実行

バケットの再配置プロセス中に発生する可能性のある問題を最小限に抑えるため、ドライランを実行することをおすすめします。ドライランでは、データを移動せずにバケットの再配置プロセスをシミュレートするため、問題を早期に発見して解決できます。ドライランでは、次の非互換性が確認されます。

• 顧客管理の暗号鍵（CMEK）または顧客指定の暗号鍵（CSEK）
• ロックされた保持ポリシー
• 一時保留が設定されているオブジェクト
• マルチパート アップロード

ドライランでは、リアルタイムのリソースの可用性などの要因により、ライブ マイグレーション中にのみ発生する問題があるため、考えられるすべての問題を特定することはできませんが、実際の再配置中に時間のかかる問題が発生するリスクを軽減できます。

gcloud storage buckets relocate gs://BUCKET_NAME --location=LOCATION --dry-run

増分データのコピーを開始する

gcloud storage buckets relocate gs://BUCKET_NAME --location=LOCATION

増分データのコピーをモニタリングする

バケットの再配置プロセスは長時間実行オペレーションであるため、進行状況を確認するためにモニタリングが必要です。長時間実行オペレーションのリストを定期的に確認して、増分データのコピーステップのステータスを確認できます。長時間実行オペレーションの詳細を取得する方法、長時間実行オペレーションのリストを表示する方法、長時間実行オペレーションをキャンセルする方法については、Cloud Storage で長時間実行オペレーションを使用するをご覧ください。

次の例は、増分データのコピー オペレーションによって生成される出力を示しています。

  done: false
  kind: storage#operation
  metadata:
  '@type': type.googleapis.com/google.storage.control.v2.RelocateBucketMetadata
  commonMetadata:
    createTime: '2024-10-21T04:26:59.666Z
    endTime: '2024-12-29T23:39:53.340Z'
    progressPercent: 99
    requestedCancellation: false
    type: relocate-bucket
    updateTime: '2024-10-21T04:27:03.2892'
  destinationLocation: US-CENTRAL1
  finalizationState: 'READY'
  progress:
    byteProgressPercent: 100
    discoveredBytes: 200
    remainingBytes: 0
    discoveredObjectCount: 10
    remainingObjectCount: 8
    objectProgressPercent: 100
    discoveredSyncCount: 8
    remainingSyncCount: 0
    syncProgressPercent: 100
  relocationState: SYNCING
  sourceLocation: US
  validateOnly: false
  estimatedWriteDowntimeDuration: '7200s'
  writeDowntimeExpireTime: '2024-12-30T10:34:01.786Z'
  name: projects//buckets/my-bucket1/operations/Bar7-1b0khdew@nhenUQRTF_R-Kk4dQ5V1f8fzezkFcPh3XMvlTqJ6xhnqJ1h_QXFIeAirrEqkjgu4zPKSRD6WSSG5UGXil6w
  response:
    '@type': type.googleapis.com/google.storage.control.v2.RelocateBucketResponse
      selfLink: https://storage.googleusercontent.com/storage/v1_ds/b/my-bucket1/operations/Bar7-1b0khdew@nhenUQRTF_R-Kk4dQ5V1f8fzezkFcPh3XMvlTqJ6xhnqJ1h_QXFIeAirrEqkjgu4zPKSRD6WSSG5UGXil6w
 

次の表は、増分データのコピー オペレーションによって生成される出力のキーフィールドに関する情報を示しています。

他の Cloud Storage 機能と連携する際に問題が発生した場合は、制限事項をご覧ください。

最終同期ステップを開始する

最終同期ステップでは、バケットに対して書き込みオペレーションを実行できない期間があります。最終同期ステップは、アプリケーションの中断を最小限に抑える時間にスケジュールすることをおすすめします。

続行する前に、増分データのコピーステップの出力で finalizationState 値を確認して、バケットが完全に準備されていることを確認します。続行するには、finalizationState の値が READY である必要があります。

最終同期ステップを早期に開始すると、コマンドからエラー メッセージ The relocate bucket operation is not ready to advance to finalization running state が返されますが、再配置プロセスは続行されます。

progressPercent 値が 99 になるまで待ってから、最終同期ステップを開始することをおすすめします。

gcloud storage buckets relocate --finalize --operation=projects/_/buckets/BUCKET_NAME/operations/OPERATION_ID

 `name: projects/_/buckets/my-bucket/operations/AbCJYd8jKT1n-Ciw1LCNXIcubwvij_TdqO-ZFjuF2YntK0r74` 

gcloud storage buckets relocate --finalize --ttl TTL_DURATION --operation=projects/_/buckets/BUCKET_NAME/operations/OPERATION_ID

バケットの再配置プロセスを検証する

再配置を開始したら、正常に完了したことを確認します。このセクションでは、データの転送が正常に完了したことを確認する方法について説明します。

次の方法で、再配置プロセスが正常に完了したことを確認します。

• 長時間実行オペレーションをポーリングする: バケットの再配置は長時間実行オペレーションです。operation id を使用して長時間実行オペレーションをポーリングして、オペレーションの進行状況のモニタリングし、success 状態を検証することで、オペレーションが正常に完了したことを確認できます。これには、オペレーションが完了状態に達するまで、オペレーションのステータスを定期的にクエリする必要があります。長時間実行オペレーションのモニタリングについては、Cloud Storage で長時間実行オペレーションを使用するをご覧ください。

• Cloud Audit Logs エントリを分析する: Cloud Audit Logs は、 Trusted Cloud by S3NS 環境のイベントとオペレーションの詳細な記録を提供します。再配置に関連付けられた Cloud Audit Logs エントリを分析して、成功を確認できます。転送中に問題の可能性を示唆するエラー、警告、予期しない動作がないかログを分析します。Cloud Audit Logs でのログの表示については、監査ログの表示をご覧ください。

  次のログエントリは、移動が成功したかどうかを判断するのに役立ちます。

  • 再配置に成功: Relocate bucket succeeded. All existing objects are now in the new placement configuration.

  • 再配置に失敗: Relocate bucket has failed. Bucket location remains unchanged.

  Pub/Sub 通知を使用して、特定の成功または失敗イベントがログに表示されたときに通知するアラートを設定することもできます。Pub/Sub 通知の設定については、Cloud Storage の Pub/Sub 通知を構成するをご覧ください。

バケットの再配置後のタスクを完了する

バケットの再配置が正常に完了したら、次の手順を完了します。

1. 省略可: バケットのタグベースのアクセス制御を復元します。
2. 既存のインベントリ レポートの構成は、再配置プロセス中に保持されないため、手動で再作成する必要があります。インベントリ レポート構成の作成については、インベントリ レポート構成を作成するをご覧ください。
3. Terraform や Google Kubernetes Engine 構成コネクタなどの Infrastructure as Code 構成を更新して、バケットの新しいロケーションを指定します。
4. リージョン エンドポイントは特定のロケーションに関連付けられているため、新しいエンドポイントを反映するようにアプリケーション コードを変更する必要があります。

失敗したバケットの再配置オペレーションを処理する方法

失敗したバケットの再配置オペレーションを処理する前に、次の要素を検討してください。

• バケットの再配置に失敗すると、一時ファイルや不完全なデータコピーなどの古いリソースが宛先に残る可能性があります。同じ宛先への別のバケットの再配置を開始するには、7～14 日間待つ必要があります。別の宛先へのバケットの再配置は、すぐに開始できます。

• 宛先ロケーションがデータに最適な場所でない場合は、再配置をロールバックすることをおすすめします。ただし、すぐに再配置を開始することはできません。再び再配置プロセスを開始するには、最長 14 日間の待機期間が必要です。この制限事項は、安定性を確保し、データの競合を防ぐために設けられています。

次のステップ

• バケットの再配置について学習する。