Cloud Storage バケットの再配置: 業界初の中断を伴わないバケット移行

※この投稿は米国時間 2025 年 7 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

運用ニーズの変化に伴い、レジリエンスの向上、パフォーマンスの最適化、コンプライアンス ニーズへの対応、または単にインフラストラクチャの再編成を目的として、Google の Cloud Storage に保存されているデータを新しいロケーションに移動する必要が生じる場合があります。しかし、バケットの移動は、手動スクリプト、入念な調整、データ損失のリスク、さらにはダウンタイムの延長を伴う、困難で複雑かつ危険な作業となる可能性があります。このため、組織がストレージ環境に必要な変更を加えることを躊躇する可能性があります。

Google は最近、Cloud Storage バケットの再配置を導入しました。これは、主要なハイパースケーラーの中でも独自の機能で、バケットのロケーションを簡単に変更できます。バケットの再配置により、複雑な手動での計画が不要になり、ダウンタイムの長期化を防ぐことができます。アプリケーションの中断を最小限に抑え、データの完全性を確保しながら、簡単に移行できます。バケットの名前と、その中のすべてのオブジェクト メタデータは、再配置後も同一のままです。そのため、パスは変更されず、基盤となるストレージが移動している間も、アプリケーションのダウンタイムは最小限に抑えられます。さらに、オブジェクトは元のストレージ クラス（例: Standard、Nearline、Coldline、Archive）と、新しいロケーションでのクラス内時間を保持します。これは、多くの費用効率戦略の鍵となります。Autoclass などの機能が引き続きインテリジェントに動作し、移行後のストレージ費用を最適化できるようにします。

バケットの再配置は、Storage Intelligence スイートの重要な機能です。Storage Insights などのツールと併用することで、ストレージ環境を詳細に可視化し、最適化の機会を特定できます。バケットの再配置により、こうした分析情報を活用して、さまざまな Cloud Storage のロケーション（低レイテンシのリージョン、高可用性と障害復旧のデュアルリージョン、グローバル アクセスのマルチリージョン）間でデータを移動し、ビジネス、パフォーマンス、コンプライアンスの目標を達成できます。

バケットの再配置の仕組み

バケットの再配置は、2 つの重要な手法に依存しています。

• 非同期データコピー: バケットの再配置では、独自の最適化された非同期データ転送メカニズムを利用して、バックグラウンドでデータをコピーし、進行中のオペレーションへの影響を最小限に抑えます。データセット全体のコピー中も、オブジェクトの書き込み、読み取り、更新などの既存のオペレーションは継続されます。

• メタデータの保持: 従来、Google Cloud のお客様はデータの移動に Storage Transfer Service を使用していました。ここでは、オブジェクトを新しいバケットにコピーし、既存のオブジェクトを削除していました。一方、バケットの再配置では、バケットとオブジェクトに関連付けられたすべてのメタデータが自動的かつ綿密に移動されるため、状態が保持されます。これには、次のような情報が含まれます。

• ストレージ クラス: オブジェクトは元のストレージ クラス（例: Standard、Nearline、Coldline、Archive）を新しいロケーションで保持します。

• バケット名とオブジェクト名: バケットとオブジェクトの命名構造は同じままです。

• 作成と更新のタイムスタンプ: これらのマーカーは保持されるため、オブジェクトのライフサイクル管理（OLM）ルールなどの機能は引き続き動作します。

• アクセス制御リスト（ACL）と IAM ポリシー: バケットレベルとオブジェクト レベルの権限が移行され、セキュリティ ポスチャーの維持に役立ちます。

• カスタム メタデータ: オブジェクトに関連付けられたユーザー定義のメタデータも移行されます。

バケットの再配置は、非同期データ転送とメタデータの自動移行の複雑さを処理することで、手動によるバケット移行に伴うリスクとオーバーヘッドを最小限に抑えます。重要な点として、バケット名は再配置プロセス全体で保持されるため、バケットにアクセスするアプリケーションを変更する必要はありません。

簡単な手順でバケットを再配置

バケットの再配置では、3 つの簡単なステップで Cloud Storage バケットを移動できます。詳細は次のとおりです。

1. ドライランを開始する:

• 再配置を実際に開始する前に、ドライランを行うことを強くおすすめします。データは移動せずにプロセスをシミュレートするため、互換性のない構成など、潜在的な問題を早期に特定できます。

• ドライランでは、顧客管理の暗号鍵（CMEK）、ロックされた保持ポリシー、一時的な保持が設定されたオブジェクト、バケットタグなどの非互換性がチェックされます。これらの項目を個別に手動で検証する必要はありません。

• --dry-run フラグを追加してください。

BUCKET_NAME をバケットの名前に、LOCATION を目的の宛先に置き換えます。

2. 再配置プロセスを開始する:

このステップでは、ソースバケットから宛先バケットへの実際のデータ転送が開始されます。このフェーズでは、バケット内のオブジェクトの読み取り、変更、削除は可能です。ただし、バケットのメタデータ（バケットレベルのパラメータと構成）は書き込みロックされ、再配置に影響する可能性のある変更を防ぎます。注: ドライラン コマンドから --dry-run フラグを削除すると、再配置が開始されます。

3. 再配置プロセスを完了する:

• 増分データのコピーが完了したら、最終的な同期ステップを開始できます（マルチリージョンと構成可能なデュアルリージョン間の移動を除く）。このステップでは、データの完全性を確保するためにバケットへの書き込みが短時間無効になります。増分コピーの進行中にバケット内のオブジェクトに加えられた直前の変更は、転送先にコピーされます。データの完全性が検証されると、バケットのロケーションが更新され、すべてのリクエストが新しいロケーションに自動的にリダイレクトされます。最終的な同期ステップで、バケット内のオブジェクトを更新しようとすると、HTTP 412 エラーが発生します。

• 再配置プロセスの進行状況が 99% 程度に達するまで、最終的な同期プロセスを開始しないでください。これにより、ほとんどのデータがバックグラウンドで同期済みとなるため、ダウンタイムを最小限に抑えることができます。

注: 同じマルチリージョン コード内でマルチリージョンと構成可能なデュアルリージョン間を 移動する場合は、バケットの再配置によってバックグラウンドで移行が処理されるため、最終処理やダウンタイムは発生しません。

OPERATION_ID はステップ 2 の出力として提供されます。OPERATION_ID はキーワード名とともに表示されます。次に例を示します。

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

これで完了です。わずか 3 ステップで、バケット全体とそのデータとメタデータを新しいロケーションに移動できました。

バケットの再配置を早期に利用したユーザーは、この新機能で大きな成果を上げています。

「Storage Intelligence とバケットの再配置により、デュアルリージョン バケットへの移行を簡単に実現できました。バケットの再配置によって実現したシームレスなプロセスにより、ダウンタイムを最小限に抑え、データの完全性を確保しました。手動で苦労することなく、安心してバケットを移行できたのです」- Spotify、プロダクト マネージャー Adam Steele 氏

「最近、Storage Intelligence のバケットの再配置機能を利用して、ネットワーク データ転送コストを最適化するために、マルチリージョンからリージョン ストレージへの約 300 個のバケットとペタバイト単位のデータ プロジェクトの移行を成功させました。バケットの再配置がなければ、このプロセスには広範な自動化とスクリプト化が必要となり、ダウンタイムと労力が増加していました」 - Groupon、データ プラットフォーム インフラストラクチャ マネージャー、Deepak Mahato 氏

Storage Intelligence のバケットの再配置で、Cloud Storage バケットを簡単かつ効率的に管理できます。詳しくは、 バケットの再配置に関するドキュメントとStorage Intelligence の概要をご覧ください。

ー Google Cloud、シニア プロダクト マネージャー、Vaibhav Khunger