このページでは、バケットの再配置の概要、メリット、ユースケース、仕組み、制限事項について説明します。
概要
Cloud Storage バケットの再配置により、地理的なロケーション間でバケットをサーバーレスで移行できます。バケットの再配置を使用すると、次のことができます。
既存のバケットの名前を変更したり、バケット内のデータを手動で転送したりすることなく、既存のバケットをある場所から別の場所に移動します。
ワークロードの Cloud Storage 構成を Compute Engine と調整することで、パフォーマンスと費用効率を改善します。
利点
バケットの再配置のメリットは次のとおりです。
シンプルな移行: 最小限のオペレーション オーバーヘッドでバケットを再配置できます。複雑なスクリプトや複数のステップのプロセスは必要ありません。
継続的なオペレーション: 移行プロセス全体でアプリケーションにアクセスできます。読み取りオペレーションのダウンタイムはなく、書き込みオペレーションのダウンタイムは最小限に抑えられます。
パフォーマンスの向上: Compute Engine リソースと Cloud Storage リソースを同じリージョンに配置すると、レイテンシが短縮され、パフォーマンスが向上します。
メタデータの保持: バケットの再配置プロセスでは、オブジェクトのメタデータが保持されます。オブジェクトのメタデータを保持すると、バケットの移動後に既存のアプリケーションとワークフローと互換性を確保できます。
ストレージ クラスの構成: Autoclass など、既存の Cloud Storage クラスの設定を維持できます。ストレージ クラスを保持すると、移行後も費用構造が維持されます。
バケットの再配置を使用する理由
バケットの再配置のユースケースには、次のようなものがあります。
データ転送費用を削減する: データが保存されている場所から離れた場所から頻繁にアクセスされる場合は、アクセス元の近くのロケーションにバケットを再配置することで、データ転送費用を削減できます。たとえば、データに主にヨーロッパからアクセスし、米国に保存されている場合は、バケットをヨーロッパのロケーションに移動して費用を削減できます。
パフォーマンスの向上: データを Compute Engine の近くに移動することで、アプリケーションの速度と応答性を向上させることができます。たとえば、アプリケーションが
us-central1で実行され、データがasia-east1にある場合は、バケットをus-central1に再配置してレイテンシを短縮できます。復元力を強化する: リージョンの停止から重要なデータを保護できます。たとえば、データが単一リージョンに保存されている場合は、デュアルリージョンまたはマルチリージョンのロケーションに再配置して、可用性と障害復旧を強化できます。
転勤の種類
バケットの再配置に書き込みのダウンタイムが発生するかどうかは、バケットの転送元と転送先の場所によって異なります。ロケーションが再配置タイプに与える影響については、バケットの再配置タイプを決定するをご覧ください。バケットの再配置には次の 2 つのタイプがあります。
書き込みの停止時間があるバケットの再配置: 書き込みの停止時間があるバケットの再配置では、バケットの再配置プロセス中にオブジェクトの書き込みオペレーションを実行できない期間があります。
書き込みのダウンタイムなしでのバケットの再配置: 書き込みのダウンタイムなしでのバケットの再配置では、バケットの再配置がバックグラウンドで行われると同時に、オブジェクトの書き込みオペレーションを中断することなく続行できます。
次の表に、書き込みのダウンタイムと書き込みのダウンタイムなしの再配置タイプの主な違いを示します。
| 仕様 | 書き込みのダウンタイムを伴うバケットの再配置 | 書き込みのダウンタイムなしでのバケットの再配置 |
|---|---|---|
| 書き込みの可用性 | 最後の同期ステップ中に書き込みオペレーションを実行できない。 | 書き込みオペレーションの中断なし。 |
| ユーザーの関与 | 書き込みダウンタイムの終了手順をユーザーが開始する必要があります。 | 明示的なファイナライズ ステップは必要ありません。 |
| パフォーマンスへの影響 | 最後の同期ステップで、バケット内のオブジェクトの書き込みまたは更新ができない。 | 再配置中にオブジェクトの読み取りと書き込みのレイテンシが増加する可能性がある。 |
| バケットの再配置のキャンセル | 書き込みのダウンタイムなしの移行よりも高速です。 | キャンセルはすぐには実行されません。オブジェクトのバックアップが必要になるため、時間がかかる場合があります。 |
| 機能のサポート | 書き込みのダウンタイムなしの移行よりも利用できる機能が少ない。 | マルチパート アップロード、保持ポリシー、Firebase、appspot などの機能の制限。これらの制限事項について詳しくは、制限事項をご覧ください。 |
バケットの再配置タイプを決定する
移行の種類は、ソースバケットと宛先バケットのロケーションによって決まります。
リージョン、デュアルリージョン、マルチリージョン間でバケットを再配置すると、バケットに書き込めないダウンタイムが発生します。ただし、次の場合はダウンタイムなしでバケットを再配置できます。
両方のロケーションが同じマルチリージョン コードを共有している場合は、マルチリージョンから構成可能なデュアルリージョンに再配置します。
両方のロケーションが同じマルチリージョン コードを共有している場合は、構成可能なデュアルリージョン間で再配置します。
両方のロケーションが同じマルチリージョン コードを共有している場合は、構成可能なデュアルリージョンからマルチリージョンに再配置します。
バケットの再配置プロセスを理解する
バケットの再配置は、ソースバケットから宛先バケットにデータを移動するのに役立ちます。ソースバケットには移動するデータを保持し、宛先バケットにはデータを移動します。
次の図は、バケットの再配置プロセスのフローを示しています。
説明手順についている番号は、図の中の番号を指します。この図は、次のステップを示しています。
増分データのコピー: 増分データのコピー ステップでは、移行元バケットから移行先バケットにデータをコピーします。バケットのメタデータは書き込みロックされているため、再配置プロセスに影響するバケットの変更を防ぐことができます。ただし、バケット内のオブジェクトの書き込み、変更、削除は可能です。所要時間に影響する要因は次のとおりです。
- バケット内のオブジェクトの更新、削除、追加の頻度は、コピー時間に直接影響します。変化率が高いほど、時間がかかります。オブジェクトの最大移動速度は
Rm, objects/secondです。合計オブジェクト数がNで、更新レートがR objects/secondの場合、コピー ステップの所要時間はN / (Rm - R)秒と見積もられます。
バケットが大きいほど、帯域幅が有限であるため、再配置に時間がかかります。
個々のオブジェクトのサイズは、コピー時間に影響します。10 GB を超えるオブジェクトは、帯域幅の制約により、10 GB 未満のオブジェクトよりも転送に時間がかかります。たとえば、1 TB のオブジェクトのコピーには 1 日かかります。大きなオブジェクトは、0.1 ～ 1 GB の小さなオブジェクトに分割することをおすすめします。
増分データコピーを開始する方法については、増分データコピー ステップを開始するをご覧ください。
- バケット内のオブジェクトの更新、削除、追加の頻度は、コピー時間に直接影響します。変化率が高いほど、時間がかかります。オブジェクトの最大移動速度は
増分データのコピーをモニタリングする: 増分データのコピー ステップのステータスを確認するには、長時間実行オペレーションのリストを定期的に確認します。増分データ コピー ステップのステータスを確認する方法については、増分データ コピー ステップをモニタリングするをご覧ください。
最終的な同期: 書き込みのダウンタイムがある移行では、増分データのコピーが完了したら、最終的な同期ステップをトリガーする必要があります。最後の同期ステップでは、データの整合性を確保するために、バケットへの書き込みができない期間があります。最後の同期ステップには、次のアクションが含まれます。
バケットが一時的に書き込みロックされます。そのため、この期間中はバケット内のオブジェクトを書き込むことも更新することもできず、データの不整合を防ぐことができます。
増分コピー ステップ以降にバケット内のオブジェクトデータに加えられた変更は、転送先バケットにコピーされます。これにより、移行されたバケットに最新のデータが確実に含まれます。オブジェクトのコピーが完了すると、比較が実行され、ソース バケットと宛先バケット間でデータの整合性が確保されます。データの比較後、バケットのロケーションが更新され、すべてのリクエストが新しいロケーションにリダイレクトされます。
すべてのデータが転送され、検証され、バケットが新しいロケーションで動作すると、書き込みロックが解除されます。その後、バケット内のオブジェクトの書き込みと更新を再開できます。
最後の同期ステップを開始する方法については、最後の同期ステップを開始するをご覧ください。
制限事項
バケットの再配置サービスは、プロジェクト内の同じロケーションからの最大 5 つの同時再配置をサポートしています。
以降のセクションでは、書き込みのダウンタイムがある再配置と書き込みのダウンタイムがない再配置に適用される制限事項について説明します。
書き込みのダウンタイム制限のある再配置
書き込みのダウンタイムがある再配置には、次の制限があります。
データ処理の制限事項
再配置中にデータを処理する場合の制限事項は次のとおりです。
- テーブルの破損: Apache Iceberg を使用する BigLake 外部テーブルと BigQuery テーブルは破損し、手動で再作成する必要があります。影響を受けるテーブルの自動検出は使用できません。
Autoclass によるオブジェクトの処理: Autoclass はアクセス パターンを使用して、オブジェクトをコールドなストレージ クラスに移行するタイミングを決定します。バケットの再配置プロセスの最終同期中、Autoclass は一時停止され、オブジェクトはコールドなストレージ クラスに移行されません。最終的な同期が完了すると、Autoclass が再開されます。
Standard Storage クラス内のオブジェクトは次のように処理されます。
- Standard ストレージ クラスのオブジェクトは、Nearline Storage などのコールド クラスに移行する前に 30 日間のアクセス不可期間があります。再配置中に Standard Storage クラスのオブジェクトが移動されると、アクセスされたものとして扱われます。そのため、再配置プロセスでアクセス不可期間がリセットされます。移動前にオブジェクトが Nearline Storage に移行されそうだった場合でも、再配置が完了してから 30 日間待つ必要があります。
標準以外のストレージ クラス内のオブジェクトは、次のように処理されます。
Nearline Storage、Coldline Storage、Archive Storage のストレージ クラス内のオブジェクトの再配置は、アクセスとしてカウントされません。そのため、これらのオブジェクトのアクセス禁止期間は影響を受けません。
再配置中に標準以外のストレージ クラスのバケット内のオブジェクトを読み書きしても、Standard Storage などのウォーマー クラスに自動的にアップグレードされることはありません。これにより、再配置プロセス中に不要なストレージ クラスの移行を防ぐことができます。
オブジェクトがよりコールドなストレージ クラス（Nearline Storage から Coldline Storage など）にダウングレードされるようにスケジュールされている場合、再配置プロセスはスケジュールに影響しません。移行が完了すると、ダウングレードは予定どおりに進みます。
オブジェクト サイズの上限: 再配置のオブジェクト サイズには 2 TB の上限が適用されます。
サポートされていない機能
次の機能を使用しているバケットは再配置できません。
- 顧客管理の暗号鍵（CMEK）または顧客指定の暗号鍵（CSEK）。
- ロックされた保持ポリシー。
- 一時保留が設定されているオブジェクト。
- マルチパート アップロード。バケットの再配置プロセスを開始する前に、完了していないマルチパート アップロードを完了するか、中止する必要があります。
- タグ。再配置中にタグを追加すると、再配置プロセスが失敗するため、おすすめしません。
- Appspot バケット。App Engine によって作成されたデフォルトのバケットの回避策として、Container Registry を Artifact Registry に移行することを検討してください。
- Firebase バケット。Firebase に関連付けられたバケットは再配置できません。
オペレーションの制約
書き込みのダウンタイムがあるバケットの再配置には、次の運用上の制限があります。
- プロジェクトの制限: プロジェクト間でバケットを再配置することはできません。
- 再開可能なアップロード: データ損失を回避するには、進行中の再開可能なアップロードを最終的な同期ステップの前に完了する必要があります。
- メタデータの更新: 移行中にバケットのメタデータを更新することはできません。
- リクエスト レートの増加: 再配置されたバケットには、新しく作成されたバケットと同じリクエスト レートの増加ガイドラインが適用されます。
書き込みのダウンタイム制限なしの再配置
書き込みのダウンタイムなしでバケットを再配置する場合は、次の制限があります。
- マルチパート アップロード: 未完了のマルチパート アップロードはサポートされていません。再配置する前に、完了するか中止する必要があります。移行中は、新しいマルチパート アップロードはブロックされます。
- 保持ポリシー: 再配置する前に、すべての保持ポリシーのロックを解除する必要があります。
- Firebase バケットと Appspot バケット: Firebase または Appspot に関連付けられたバケットでは、再配置はサポートされていません。
- 進行状況の更新: 移転の進行状況の更新はリニアにならない場合があります。
非対応のリージョン
me-central1 リージョンでは、転送元バケットまたは転送先バケットのバケットの再配置は使用できません。
次のステップ
- バケットの再配置を計画する方法を確認する。
- バケットを再配置する方法を学習する。