このページでは、バケットの再配置の概要、メリット、ユースケース、仕組み、制限事項について説明します。
概要
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 Storage クラスのオブジェクトは、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 リージョンでは、転送元バケットまたは転送先バケットのバケット再配置は使用できません。
次のステップ
- バケットの再配置を計画する方法を確認する。
- バケットを再配置する方法を確認する。