Cloud Storage データをマルチリージョンからリージョンに移行する方法

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

Cloud Storage バケットのロケーション タイプを選択する際には多くの考慮事項がありますが、後になってビジネス上のニーズが変化し、マルチリージョンやデュアルリージョンよりもリージョン ストレージのほうが費用の削減やパフォーマンスの向上につながるということが判明する場合があります。Cloud Storage の仕様では、バケットにデータをいったん格納すると、ロケーション タイプを変更することはできません。つまり、新しいリージョン バケットを作成し、既存のデータをそこに移行する必要があります。

マルチリージョンからリージョン ストレージへの移行

この作業を行うためのツールが Storage Transfer Service（STS）であり、パラメータ化によって、ファイルの一括移行を行えます。基本的な手順は次のとおりです。

1. ご希望のリージョンで新しいバケットを作成します。

2. STS を使って、元のマルチリージョン バケットから新しいリージョン バケットへとオブジェクトを移行します。

3. 新しいバケットでオブジェクトをテストし（Cloud Storage Insights などを使用します）、テストが正常に終了したら、古いバケットを削除します。

STS 自体は無料で使用できますが、移行の実行に伴う Cloud Storage 料金が発生します。具体的には、移行元バケットを削除するまでの移行元および移行先データのストレージ料金、オブジェクトの一覧表示、読み取り、書き込みに関連するクラス A およびクラス B オペレーションの料金、ネットワーク間のデータ移行に伴う下り（外向き）料金、Nearline、Coldline、Archive オブジェクトの移行に伴う取得料金と早期削除料金がかかります。詳しくは、STS の料金に関するドキュメントをご覧ください。

ここまでは、マルチリージョンからリージョンへの Cloud Storage の移行を前提として説明しましたが、以下の手順では、そのほかのロケーション タイプの変更についても基本的に同じ注意事項やプロセスがあてはまります。たとえば、マルチリージョンから、ひとまずデュアルリージョンに移行する場合や、あるリージョン ロケーションから別のロケーションにリージョン バケットを移行する場合なども、同様の手順で行えます。

移行の計画

まず最初に、移行対象のバケットを特定します。古いデータや不要なデータを含むバケットなど、移行が不要なケースも多々あるでしょう。また、国内外にユーザーを抱える画像ホスティング サービスのワークロードなど、マルチリージョンのほうが適しているバケットもあります。

大量のデータを移行する場合は、移行にかかる時間を考慮することも重要になってきます。一部のお客様がサービスに過剰な負担をかけることを回避するため、STS では秒間クエリ数および帯域幅の上限がプロジェクトごとに設定されています。大規模な移行を計画している場合は（100 PB を超えるデータまたは 10 億を超えるオブジェクトなど）、Google Cloud セールスチームにあらかじめ連絡するか、サポート チケットを作成して、移行を実行するリージョンで必要な容量を確保しておくようにしましょう。移行に要する時間については、さまざまな要因が絡み合い、複雑な計算が必要になります。セールスチームが時間の計算についてご相談にのりますので、お問い合わせください。

移行にかかる時間の目安としては、11 PB のデータ、7,000 万のオブジェクトを含むバケットの場合、およそ 24 時間ぐらいとお考えください。11 PB のデータ、840 億のオブジェクトの場合、ジョブを同時実行しないと移行に 3 年ほどかかります。移行対象のオブジェクト数が 10 億を超える場合、移行に極めて長い時間がかかるのが普通です。この場合は、Google Cloud の技術者の協力を得て、移行を同時実行し、時間を短縮するようにしましょう。なお、これはクラウド間の移行を前提とした数字です。HTTP による移行ではないことにご注意ください。

また、古いバケットから新しいバケットに移行したいメタデータが存在する場合もあるでしょう。ユーザーが作成したカスタム フィールドなど、一部のメタデータは STS によって自動的に移行されます。一方、ストレージ クラスや CMEK などのフィールドは、STS API を使って移行を手動で有効にする必要があります。オブジェクトの最新バージョンだけでなく、全バージョンを移行したい場合も、API や gcloud CLI を使用する必要があります。宛先バケットで Cloud Storage の Autoclass を使用する場合は（バケット生成時に有効にする必要があります）、移行後、全オブジェクトを Standard Storage クラスとして開始する必要があります。注意事項について詳しくは、Cloud Storage バケット間の転送に関するドキュメント をご覧ください。

最後に、バケットの名前をそのまま維持するか、新しい名前に変更するかを決定します。たとえば、アプリケーションに特に変更がなく、同じバケット名を維持したい場合があります。バケット名を維持する必要がある場合は、追加の手順が必要になります。これについては、次のセクションを続けてお読みください。

移行の手順

以下の図は、1 つのバケットの移行プロセスを示しています。

すべてのダウンストリーム アプリケーションのコード内でバケット名を変更する手間を省くため、元のマルチリージョン バケットと同じリージョン バケット名を維持したいケースもあるでしょう。ロケーション タイプと同じく、バケット名も変更することはできません。また、バケット名は、グローバルに一意である必要があります。したがって、バケット名を維持したい場合は、データをまず一時的な中間バケットに移行してから、元のバケットの削除後に新しく作成したバケットに移行するという、２ 段階の移行が必要になります。この方法の場合、さらに時間がかかることになりますが、2 回目の移行は同一リージョン内のコピーにすぎないので、最初の移行にかかる時間の 10 分の 1 ほどです。

新しいバケットに切り替える際は、サービスのダウンタイムが発生することにご注意ください。また、元のマルチリージョン バケットを削除したらすぐに、同じ名前でリージョン バケットを作成してください。いったんバケットを削除すると、そのバケット名を誰でも使用可能な状態になります。

複数のバケットを移行したい場合は、複数のジョブを同時に実行することによって、移行の開始から完了までにかかる時間を短縮できます。STS では、プロジェクトごとに 200 個のジョブを同時に実行できます。なお、各ジョブ内でのオブジェクトのコピーは 1 つずつ行われるため、サイズが非常に大きいバケットや、大量のオブジェクトを含むバケットの場合、データ移行をすべて完了するのに数日かかる可能性があります。この場合は、1 つのバケットにつき複数のジョブを実行し、接頭辞を使ってオブジェクトをフィルタするように各ジョブを構成することが可能です。この方法は、正しく構成すれば、非常に大規模なバケットで移行時間を大幅に短縮できる可能性があります。また、STS ジョブの処理や移行済みオブジェクトのテストに役立つライブラリも公開されています。

次のステップ

多様なストレージ オプションから自由に選択できるということには、選択に対する責任を引き受けるということでもあります。移行が必要かどうかを判断する際は、データおよび関連するワークロードについて吟味するようにしましょう。また、新しいロケーション タイプのバケットにどのデータやメタデータを移行すべきかをよく検討してください。これらのことをいったん決めてしまえば、Cloud Storage と STS を使って、簡単に移行を行えます。データの移行が完了したら、Cloud Storage の使用量を最適化するほかの方法、たとえば、カスタマイズ可能なモニタリング ダッシュボードの利用などもご検討ください。移行の規模が小さい場合や、分析用ワークロードのためにデータを VM にダウンロード、アップロードするといった目的には、STS の必要性を感じないかもしれません。その場合は、gcloud storage CLI の使用をご検討ください。