このドキュメントでは、地理的なロケーション間でバケットをサーバーレスで再配置する Cloud Storage バケットの再配置サービスについて説明します。バケットの再配置を使用すると、既存のバケットの名前を変更したり、バケット内のデータを手動で転送することなく、既存のバケットをある場所から別の場所に移動できます。
目標とバケットの使用状況に基づいて、中断を最小限に抑え、バケットを正常に再配置できるように、バケットの再配置を慎重に計画する必要があります。バケットを再配置する方法の詳細については、バケットを再配置するをご覧ください。
利点
バケットの再配置のメリットは次のとおりです。
シンプルな移行: 最小限の運用オーバーヘッドでバケットを再配置できます。複雑なスクリプトや複数の手順は必要ありません。
継続的な運用: 再配置プロセス全体を通してアプリケーションにアクセスできます。読み取りオペレーションのダウンタイムはなく、書き込みオペレーションのダウンタイムは最小限に抑えられます。
パフォーマンスの向上: Compute Engine リソースと Cloud Storage リソースを同じリージョンに配置すると、レイテンシが短縮され、パフォーマンスが向上します。
メタデータの保持: バケットの再配置プロセスでは、オブジェクトのメタデータが保持されます。オブジェクトのメタデータを保持すると、バケットの移動後に既存のアプリケーションとワークフローと互換性を確保できます。
ストレージ クラスの構成: Autoclass など、既存の Cloud Storage クラスの設定を維持できます。ストレージ クラスを保持すると、移行後も費用構造が維持されます。
ユースケース
バケットを再配置することで実現できるユースケースは次のとおりです。
データ転送コストを削減する: バケットのデータにアクセスするワークロードの近くにバケットを再配置することで、データ転送コストを回避します。たとえば、データが米国に保存されていて、主にヨーロッパからアクセスしている場合は、バケットをヨーロッパのロケーションに移動することでデータ転送の費用を削減できます。
パフォーマンスの向上: データを Compute Engine ワークロードの近くに移動することで、アプリケーションの速度とレスポンスを向上させることができます。たとえば、アプリケーションが
us-central1で実行され、データがasia-east1にある場合は、バケットをus-central1に再配置してレイテンシを短縮できます。復元力の強化: リージョンの停止から重要なデータを保護します。たとえば、データが単一リージョンに保存されている場合は、デュアルリージョンまたはマルチリージョンに再配置して、可用性と障害復旧を強化できます。
再配置のタイプ
バケットの再配置には次の 2 つのタイプがあります。
書き込みのダウンタイムがあるバケットの再配置: 書き込みのダウンタイムがあるバケットの再配置では、バケットの再配置プロセス中にオブジェクトの書き込みオペレーションを実行できない期間があります。
書き込みのダウンタイムなしでのバケットの再配置: 書き込みのダウンタイムなしでのバケットの再配置では、バケットの再配置がバックグラウンドで行われると同時に、オブジェクトの書き込みオペレーションを中断することなく続行できます。
バケットの再配置に書き込みのダウンタイムが発生するかどうかは、バケットの転送元と転送先のロケーションによって異なります。次の表に、バケットのロケーションが再配置中の書き込みダウンタイムにどのように影響するかを示します。これには、ダウンタイムを伴う再配置とダウンタイムなしの再配置の違いも含まれます。
| 仕様 | 書き込みのダウンタイムを伴うバケットの再配置 | 書き込みのダウンタイムなしでのバケットの再配置 |
|---|---|---|
| バケットのロケーション | 次のロケーション間でバケットを再配置すると、ダウンタイムが発生します。
|
次のロケーション間でバケットを再配置する場合、両方のロケーションが同じマルチリージョン コードを共有していれば、ダウンタイムは発生しません。
|
| 書き込みの可用性 | 最後の同期ステップでは書き込みオペレーションを実行できません。 | 再配置中も書き込みオペレーションは中断されずに続行されます。 注: 書き込みダウンタイムのないポリシー変更は、進行中の再開可能なアップロードが完了するのを待つ必要があるため、完了までに少なくとも 7 日かかります。 |
| ユーザーの関与 | 書き込みのダウンタイムの最終手順を開始する必要があります。 | 明示的な最終手順は必要ありません。 |
| パフォーマンスへの影響 | 最後の同期ステップ中は、バケット内のオブジェクトの書き込みや更新はできません。 | 再配置中は、オブジェクトの読み取りと書き込みのレイテンシが増加する可能性があります。 |
| バケットの再配置のキャンセル | 書き込みのダウンタイムなしの再配置よりも高速です。 | キャンセルは即時に行われず、オブジェクトのバックフィルが必要になるため、時間がかかることがあります。 |
| 機能サポート | 書き込みのダウンタイムなしの再配置よりも機能サポートが少なくなります。サポートされていない機能の詳細については、サポートされていない機能をご覧ください。 | マルチパート アップロード、保持ポリシー、Firebase、appspot などの機能には制限があります。これらの制限事項について詳しくは、制限事項をご覧ください。 |
| 最小再配置期間 | なし | 7 日間 |
バケットの再配置プロセスを理解する
バケットの再配置は、転送元バケットから転送先バケットにデータを移動するのに役立ちます。転送元バケットでは移動するデータを保持し、転送先バケットにはデータを移動します。
次の図は、バケットの再配置プロセスのフローを示しています。
* 最終的な同期は、書き込みのダウンタイムを伴う再配置でのみ必要です。
次の表に、3 つの主なステップと各ステップの説明を示します。
| ステップ | 説明 |
|---|---|
ドライランを実行する | バケットの再配置プロセスをシミュレートして、実際のデータ転送が開始される前に潜在的な問題を特定します。 |
ソースバケットから宛先バケットにデータをコピーします。バケットのメタデータは書き込みロックされ、再配置プロセスに影響する可能性のあるバケットの変更を防ぎます。ただし、バケット内のオブジェクトの書き込み、変更、削除は可能です。所要時間に影響を及ぼす要因は以下のとおりです。
|
|
最終同期ステップを開始する | 最終同期を開始すると、バケットは書き込みロックされます。その結果、この期間中はバケット内のオブジェクトを書き込むことも更新することもできず、データの不整合を防ぐことができます。ただし、バケットからの読み取りは引き続き行うことができます。 すべてのデータが転送され、検証され、バケットが新しいロケーションで動作すると、書き込みロックが自動的に解除されます。その後、バケット内のオブジェクトの書き込みと更新を再開できます。 |
制限事項
バケットの再配置サービスは、プロジェクト内の同じロケーションから最大 5 つの同時再配置をサポートしています。
次のセクションでは、書き込みのダウンタイムがある再配置と書き込みのダウンタイムがない再配置に適用される制限事項について説明します。
書き込みのダウンタイム制限のある再配置
書き込みのダウンタイムがある再配置には、次の制限があります。
データ処理の制限事項
再配置中にデータを処理する場合の制限事項は次のとおりです。
テーブルの破損: Apache Iceberg を使用する BigLake 外部テーブルと BigQuery テーブルは破損し、手動で再作成する必要があります。影響を受けるテーブルの自動検出は使用できません。
Autoclass によるオブジェクトの処理: Autoclass はアクセス パターンを使用して、オブジェクトをコールド ストレージ クラスに移行するタイミングを決定します。バケットの再配置プロセスの最終同期中、Autoclass は一時停止され、オブジェクトはコールド ストレージ クラスに移行されません。最終的な同期が完了すると、Autoclass が再開されます。
Standard Storage クラス内のオブジェクトは次のように処理されます。
- Standard Storage クラスのオブジェクトは、Nearline Storage などのコールド クラスに移行する前に 30 日間のアクセス不可期間があります。再配置中に Standard Storage クラスのオブジェクトが移動されると、アクセスされたものとして扱われます。そのため、再配置プロセスでアクセス不可期間がリセットされます。移動前にオブジェクトが Nearline Storage に移行されそうだった場合でも、再配置が完了してから 30 日間待つ必要があります。
Standard 以外のストレージ クラス内のオブジェクトは、次のように処理されます。
Nearline Storage、Coldline Storage、Archive Storage のストレージ クラス内のオブジェクトを再配置する場合は、アクセスとしてカウントされません。そのため、これらのオブジェクトのアクセス不可期間は影響を受けません。
バケットを再配置するときに、Nearline Storage、Coldline Storage、Archive Storage などの Standard 以外のストレージ クラスのバケット内のオブジェクトに頻繁にアクセスしても、バケットは自動的によりウォームなストレージ クラスに移行されません。たとえば、オブジェクトに頻繁にアクセスしても、バケットが Archive Storage から Coldline Storage に、または Coldline Storage から Standard Storage に自動的に移行されることはありません。この動作により、再配置中のストレージ クラスの自動移行が防止されます。
オブジェクトがよりコールドなストレージ クラス（Nearline Storage から Coldline Storage など）に移行されるようにスケジュールされている場合、再配置プロセスはスケジュールに影響しません。再配置が完了すると、移行は予定どおりに進みます。
オブジェクト サイズの上限: 再配置のオブジェクト サイズには 2 TB の上限が適用されます。
マルチパート アップロード
マルチパート アップロードは、状態（完了、進行中、再配置中に開始）にかかわらず、書き込みダウンタイムを伴うバケットの再配置ではサポートされていません。再配置するバケットでマルチパート アップロードが完了している場合は、マルチパート メソッドを使用せずにオブジェクトを再アップロードし、マルチパート アップロードを削除する必要があります。そうしないと、再配置が失敗します。書き込みのダウンタイムを伴うバケットの再配置中にマルチパート アップロードを使用してオブジェクトをアップロードすると、FAILED_PRECONDITION エラーが発生します。
サポートされていない機能
次の機能を使用しているバケットは再配置できません。
ロックされた保持ポリシー。
一時保留が設定されているオブジェクト。
階層型名前空間が有効になっているバケット。
タグ再配置中にタグを追加すると、再配置プロセスが失敗するため、おすすめしません。
Anywhere Cache を無効にします。Anywhere Cache は増分データのコピーステップで有効にできますが、最終同期ステップの完了を妨げます。
Appspot バケット。App Engine によって作成されたデフォルトのバケットの回避策として、Container Registry を Artifact Registry に移行することを検討してください。
Firebase バケット。Firebase に関連付けられたバケットは再配置できません。
オペレーションの制約
書き込みのダウンタイムがあるバケットの再配置には、次の運用上の制限があります。
プロジェクトの制限: プロジェクト間でバケットを再配置することはできません。
再開可能なアップロード: データ損失を回避するには、進行中の再開可能なアップロードを最終的な同期ステップの前に完了する必要があります。
メタデータの更新: 再配置中にバケットのメタデータを更新することはできません。
リクエスト レートの増加: 再配置されたバケットには、新しく作成されたバケットと同じリクエスト率の増加ガイドラインが適用されます。
書き込みのダウンタイム制限なしの再配置
書き込みのダウンタイムなしでバケットを再配置する場合は、次の制限があります。
保持ポリシー: 再配置する前に、すべての保持ポリシーのロックを解除する必要があります。
Firebase バケットと Appspot バケット: Firebase または Appspot に関連付けられたバケットでは、再配置はサポートされていません。
進行状況の更新: 再配置の進行状況の更新はリニアにならない場合があります。
マルチパート アップロード: バケットの再配置中にサポートされるのは、完了したマルチパート アップロードのみです。バケットの再配置中にオブジェクトで進行中のマルチパート アップロードはサポートされていません。バケットの再配置前に完了またはキャンセルする必要があります。マルチパート メソッドを使用せずにオブジェクトを再アップロードする必要があります。バケットの再配置中にマルチパート アップロードを使用してオブジェクトをアップロードすると、
FAILED_PRECONDITIONエラーが発生します。
サポートされていないロケーション
次のロケーションにある転送元バケットと転送先バケットでは、バケットの再配置はサポートされていません。
| ロケーション タイプ | サポートされていないロケーション |
|---|---|
| リージョン |
|
料金
バケットの再配置に関連する料金の詳細については、Cloud Storage の料金をご覧ください。
次のステップ
- バケットの再配置を計画する方法を確認する。
- バケットを再配置する方法を確認する。