このドキュメントは、将来の拡張や他の Google Cloud リージョンへのワークロードの移行、またはリージョン間でのワークロードの移行の影響を最小限に抑えるようにワークロードを設計する場合に役立ちます。また、こうしたアクティビティを行う予定がある場合や、将来実施する可能性を評価していて、その概要を把握する場合にも役立ちます。
このドキュメントはシリーズの一部です。
- 始めましょう
- Google Cloud で復元性に優れた単一リージョン環境を設計する
- ワークロードを設計する（このドキュメント）
- 移行用のデータとバッチ ワークロードを準備する
このシリーズのガイダンスは、リージョン間の移行や複数リージョンへの拡張を事前に計画していない場合にも役立ちます。この場合、リージョン間の移行や複数のリージョンへの拡張のために、インフラストラクチャ、ワークロード、データの準備に追加の作業が必要になることがあります。
このドキュメントでは、次の方法について説明します。
- ランディング ゾーンを準備する
- リージョン間の移行のためにワークロードを準備する
- コンピューティング リソースを準備する
- データ ストレージ リソースを準備する
- 移行元の環境の廃止に向けて準備する
ランディング ゾーンを準備する
このセクションでは、リージョン間で移行するときにランディング ゾーン（クラウドの基盤とも呼ばれます）を拡張する際に考慮すべき事項について説明します。
まず、既存のランディング ゾーンのさまざまな側面を再評価します。ワークロードを移行する前に、ランディング ゾーンがすでに存在している必要があります。ワークロードをホストしているリージョンにランディング ゾーンが存在する場合でも、ランディング ゾーンが別のリージョンへのワークロードのデプロイをサポートしていない可能性があるため、ターゲット リージョンへのゾーンの拡張が必要になります。すでに導入されている一部のランディング ゾーンは、ランディング ゾーンを大幅に変更することなく、別のリージョンをサポートできる設計になっている場合があります（ID とアクセス管理、リソース管理など）。ただし、ネットワークやデータなどの追加要因によっては、拡張機能の計画が必要になる場合があります。再評価プロセスでは、ワークロードの主な要件を考慮し、移行中に特化できる汎用の基盤を設定できるようにする必要があります。
エンタープライズ向けの検討事項
業界や政府の標準、規制、認証などの点で、ワークロードを別のリージョンに移行する際に異なる要件が適用される場合があります。地理的に異なる国にある Google リージョンで実行されるワークロードは、その国の法律と規制を遵守する必要があります。また、業界標準によって、海外で実行されるワークロードに固有の要件（特にセキュリティに関する要件）が定められている場合があります。Google Cloud リージョンは 1 か国でリソースを実行するように構築されているため、特定の規制に準拠するために、ワークロードが別の Google リージョンからその国に移行されることがあります。このような「国内」移行を行う場合は、オンプレミスで実行されているデータを再評価し、新しいリージョンで Google Cloud へのデータ移行が可能かどうかを確認することが重要です。
ID とアクセスの管理
移行を計画する際、多くの場合、すでに Google Cloud に存在するリージョンの ID とアクセスについて変更を計画する必要はほとんどありません。Google Cloud での ID の決定とリソースへのアクセスは通常、リソースが実行されているリージョンではなく、リソースの性質に基づいています。考慮すべき点は次のとおりです。
- チームの設計: 会社によっては、さまざまなリソースを異なるチームが処理するように構成されていることがあります。ワークロードが別のリージョンに移行された結果、リソースの構造が変更され、特定のリソースを担当する最適な候補が別のチームに変わることがあります。その場合は、アクセスを適宜調整する必要があります。
- 命名規則: 命名規則は、機能に対して技術的な影響を与えないこともありますが、特定のリージョンを参照する命名規則で定義されたリソースがある場合は、再検討が必要になる場合があります。典型的な例としては、Compute Engine 仮想マシン（VM）など、リージョン名を接頭辞として使用している複数のレプリケーション リージョンがすでに存在する場合です（例:
europe-west1-backend-1）。移行プロセス中に、混乱や、特定の命名規則に依存するパイプラインの破損を防ぐため、新しいリージョンを反映するように名前を変更することが重要です。
接続性とネットワーキング
ネットワーク設計は、移行の実行方法のさまざまな側面に影響します。ワークロードの移行方法を計画する前に、この設計に対応することが重要になります。
Google Cloud とのオンプレミス接続は、リージョン固有に設計できるため、移行時に再評価する必要がある要素の一つとなります。たとえば、Cloud Interconnect はこうした要因の一つです。これは、特定のリージョンへの VLAN アタッチメントを介して Google Cloud に接続しています。リージョン間のトラフィックを回避するには、VLAN アタッチメントが接続しているリージョンを削除する前に、そのリージョンを変更する必要があります。また、Partner Interconnect も考慮すべき要因の一つです。リージョンの移行により、VLAN アタッチメントと Google Cloud の接続ポイントとして別の物理ロケーションを選択したほうが良い場合があります。この考慮事項は、Cloud VPN を使用していて、移行中にサブネット アドレスを変更する場合にも関連します。新しいネットワーキングを反映するようにルーターの再構成が必要になります。
Google Cloud 上の Virtual Private Cloud（VPC）はグローバル リソースですが、単一のサブネットは常にリージョンにバインドされます。つまり、移行後に同じサブネットをワークロードに使用することはできません。サブネットでは IP の重複は許可されないため、同じアドレスを維持するには新しい VPC の作成が必要になります。Cloud DNS を使用している場合は、このプロセスが簡素化されます。Cloud DNS では、DNS ピアリングなどの機能を使用して、移行されたワークロードのトラフィックをルーティングしてから、古いリージョンを削除できます。
Google Cloud で基盤を構築する方法については、Google Cloud への移行: 基盤の計画と構築をご覧ください。
リージョン間の移行のためにワークロードを準備する
現在 Google Cloud でインフラストラクチャを設定していて、将来的には別のリージョンに移行する予定がある場合でも、すでに Google Cloud を使用していて別のリージョンに移行する必要がある場合でも、ワークロードを最も簡単な方法で移行し、労力を削減して、リスクを最小限に抑える必要があります。すべてのワークロードが移行可能な状態になるように、次の方法をおすすめします。
- 簡単に複製可能で、特定のネットワーク トポロジから疎結合されたネットワーク設計を優先する。Google Cloud には、現在のネットワーク構成をそのネットワークを使用するリソースから分離できるさまざまなプロダクトが用意されています。このようなプロダクトの例として Cloud DNS があります。これにより、内部サブネット IP を VM から分離できます。
- マルチリージョンまたはグローバル構成をサポートするプロダクトを設定する。通常、複数のリージョンを含む構成をサポートするプロダクトは、別のリージョンに移行するプロセスを簡素化します。
- データ用にマネージド クロスリージョン レプリカを使用するマネージド サービスを検討する。このドキュメントの後半で説明するように、一部のマネージド サービスでは、バックアップや高可用性のために別のリージョンにレプリカを作成できます。この機能は、リージョン間でデータを移行する際に重要です。
一部の Google Cloud サービスは、マルチリージョン デプロイまたはグローバル デプロイをサポートするように設計されています。これらのサービスを移行する必要はありませんが、一部の構成の調整が必要になる場合があります。
コンピューティング リソースを準備する
このセクションでは、Google Cloud 上のコンピューティング リソースの概要と、別のリージョンへの移行に備えた設計原則について説明します。
このドキュメントでは、次の Google Cloud コンピューティング プロダクトについて説明します。
Compute Engine
Compute Engine は、お客様に VM を提供する Google Cloud のサービスです。
Compute Engine リソースをリージョン間で移行するには、ネットワーキングに関する考慮事項に加えて、さまざまな要素を評価する必要があります。
次のことをおすすめします。
- コンピューティング リソースを確認する: VM のホスティング リージョンを変更する際に最初に発生する制限の一つは、新しいターゲット リージョンで利用可能な CPU プラットフォームです。移行中にマシンシリーズを変更する必要がある場合は、現在の VM のオペレーティング システムがシリーズでサポートされていることを確認してください。一般的に、この問題はすべての Google Cloud コンピューティング サービスに拡張できます（一部の新しいリージョンでは Cloud Run や Cloud GPU などのサービスがない場合があります）。そのため、移行を計画する前に、必要なすべてのコンピューティング サービスが移行先のリージョンで利用可能であることを確認してください。
- ロード バランシングとスケーリングを構成する: Compute Engine は、Compute Engine インスタンス間のトラフィックのロード バランシングと、需要に応じて MIG から仮想マシンを自動的に追加または削除する自動スケーリングをサポートしています。環境の信頼性と柔軟性を高め、セルフマネージド ソリューションの管理の負担を回避するには、ロード バランシングと自動スケーリングを構成することをおすすめします。Compute Engine のロード バランシングとスケーリングの構成について詳しくは、ロード バランシングとスケーリングをご覧ください。
- ゾーン DNS 名を使用する: 複数のリージョンにまたがるサービスの停止によるリスクを軽減するには、ゾーン DNS 名を使用して、環境内で DNS 名を使用する仮想マシンを一意に識別することをおすすめします。Google Cloud では、デフォルトで Compute Engine 仮想マシンにゾーン DNS 名が使用されます。Compute Engine の内部 DNS の仕組みについては、内部 DNS の概要をご覧ください。将来的なリージョン間の移行を容易にし、構成の保守性を高めるために、将来変更する可能性のある構成パラメータとしてゾーン DNS 名を検討することをおすすめします。
- 同じマネージド インスタンス グループ（MIG）テンプレートを使用する: Compute Engine では、リージョン内の複数のゾーンに仮想マシンを自動的にプロビジョニングするリージョン MIG を作成できます。古いリージョンでテンプレートを使用している場合は、同じテンプレートを使用して新しいリージョンに MIG をデプロイできます。
GKE
Google Kubernetes Engine（GKE）を使用すると、Kubernetes でコンテナ化されたワークロードのデプロイ、管理、スケーリングを行うことができます。
GKE ワークロードを移行に向けて準備するには、次の設計ポイントと GKE の機能を検討してください。
- Cloud Service Mesh: Istio メッシュのマネージド実装。クラスタで Cloud Service Mesh を利用すると、クラスタに対するネットワーク トラフィックをより細かく制御できます。Cloud Service Mesh の主な機能の一つは、2 つのクラスタ間にサービス メッシュを作成できることです。この機能を使用すると、新しいリージョンに GKE クラスタを作成してサービス メッシュに追加することで、リージョン間の移行を計画できます。このアプローチでは、新しいクラスタにワークロードのデプロイを開始し、トラフィックを段階的にルーティングできます。これにより、メッシュ ルーティングを編集してロールバックするオプションを備えながら、新しいデプロイのテストを行うことができます。
- Config Sync: オープンソース コア上に構築された GitOps サービス。クラスタ オペレータとプラットフォーム管理者は、単一のソースから構成をデプロイできます。Config Sync は 1 つまたは複数のクラスタをサポートできるため、単一の信頼できる情報源を使用してクラスタを構成できます。この Config Sync の機能を使用すると、新しいリージョンのクラスタに既存のクラスタの構成を複製し、リージョンの特定のリソースをカスタマイズできます。
- Backup for GKE: この機能を使用すると、クラスタの永続データを定期的にバックアップし、同じクラスタまたは新しいクラスタに復元できます。
Cloud Run
Cloud Run では、Google Cloud にコンテナを簡単にデプロイできます。Cloud Run サービスはリージョン リソースであり、リージョン内の複数のゾーンに複製されます。Cloud Run サービスをデプロイするときに、インスタンスをデプロイするリージョンを選択し、この機能を使用して別のリージョンにワークロードをデプロイできます。
VMware Engine
Google Cloud VMware Engine は、Google Cloud で VMware プラットフォームを運用できるフルマネージド サービスです。VMware 環境は、vSphere、vCenter、vSAN、NSX-T、HCX、対応するツールなどを Google Cloud のロケーションにある Google Cloud ベアメタル インフラストラクチャ上でネイティブに実行できます。
VMware Engine インスタンスを別のリージョンに移行するには、新しいリージョンにプライベート クラウドを作成する必要があります。その後、VMware ツールを使用してインスタンスを移動します。
移行を計画する際には、Compute Engine 環境の DNS とロード バランシングも考慮する必要があります。VMware Engine は、Google Cloud DNS を使用します。これは、公共のインターネットに公開された正式な DNS ホスティング、VPC ネットワークに表示される限定公開ゾーン、VPC ネットワーク上の名前解決の管理に使用される DNS 転送とピアリングを提供するマネージド DNS ホスティング サービスです。
移行計画では、マルチリージョン ロード バランシングと DNS 構成のテストがサポートされます。
データ ストレージ リソースを準備する
このセクションでは、Google Cloud のデータ ストレージ リソースの概要と、別のリージョンに移行するための準備方法の基本について説明します。
データがすでに Google Cloud にあると移行が簡単になります。これは、変換なしでデータをホストするソリューションが存在するか、Google Cloud でホストできることを意味します。
データベース データを別のリージョンにコピーし、別の場所に復元する機能は、障害復旧（DR）の一般的なパターンです。このため、このドキュメントで説明するパターンの一部は、データベースのバックアップや復元などの DR メカニズムに依存しています。
このドキュメントでは、次のマネージド サービスについて説明します。
このドキュメントでは、使用しているストレージ ソリューションが、コンピューティング リソースと共存するリージョン インスタンスであることを前提としています。
Cloud Storage
Cloud Storage には、さまざまなシステムから Cloud Storage へのファイル転送を自動化する Storage Transfer Service があります。これを使用して、バックアップ用のデータを別のリージョンに複製したり、リージョン間の移行を行うことができます。
Cloud SQL
Cloud SQL は、さまざまなタイプのデータベースをホストするリレーショナル データベース サービスを提供します。Cloud SQL には、インスタンス データを別のリージョンに複製できるリージョン間レプリケーション機能があります。この機能は、Cloud SQL インスタンスのバックアップと復元の一般的なパターンですが、他のリージョンの 2 番目のレプリカをメインレプリカに昇格させることもできます。この機能を使用すると、2 番目のリージョンにリードレプリカを作成し、ワークロードを移行したらメインレプリカに昇格できます。一般に、データベースの場合、マネージド サービスはデータ レプリケーションのプロセスを簡素化し、移行中の新しいリージョンにレプリカを簡単に作成できるようにします。
移行を処理するもう一つの方法は、Database Migration Service を使用することです。これにより、さまざまなソースから Google Cloud に SQL データベースを移行できます。サポートされているソースには、別の Cloud SQL インスタンスも含まれます。唯一の制限は、別のリージョンに移行することはできても、別のプロジェクトに移行することはできないことです。
Filestore
このドキュメントの前半で説明したように、Filestore のバックアップと復元機能を使用すると、別のリージョンに復元できるファイル共有のバックアップを作成できます。この機能を使用して、リージョン間の移行を実行できます。
Bigtable
Cloud SQL と同様に、Bigtable はレプリケーションをサポートしています。この機能を使用して、説明した同じパターンを複製できます。宛先リージョンでサービスが利用可能かどうかは、Bigtable のロケーション リストで確認できます。
また、Filestore と同様に、Bigtable はバックアップと復元をサポートしています。この機能は、Filestore と同様に、バックアップを作成して新しいリージョンの別のインスタンスに復元することで、移行を実装するために使用できます。
最後のオプションは、Cloud Storage などのテーブルのエクスポートです。これらのエクスポートでは、別のサービスでデータをホストし、そのデータをリージョンのインスタンスにインポートします。
Firestore
Firestore のロケーションは、プロジェクト内の App Engine の存在にバインドされる場合があります。この場合、一部のシナリオでは、Firestore インスタンスが強制的にマルチリージョンになります。このような移行シナリオでは、App Engine も考慮して、Firestore に適したソリューションを設計する必要があります。実際、us-central または europe-west のいずれかのロケーションを使用する App Engine アプリをすでに導入している場合、Firestore データベースはマルチリージョンとみなされます。
リージョンのロケーションがあり、別のロケーションに移行する場合は、マネージド エクスポート / インポート サービスにより、Cloud Storage バケットを使用して Firestore エンティティをインポートまたはエクスポートできます。この方法は、インスタンスをあるリージョンから別のリージョンに移動する場合に使用できます。別の方法として、Firestore のバックアップと復元機能を使用する方法もあります。この方法は、インポートとエクスポートよりも費用が低く、簡単です。
移行元の環境の廃止に向けて準備する
移行元の環境を廃止して新しい環境に切り替える前に、事前に準備を行う必要があります。
移行元の環境を廃止する前に、大まかに次の点を考慮する必要があります。
- 新しい環境のテスト: トラフィックを古い環境から新しい環境に切り替える前に、テストを実施してアプリケーションの正確性を検証できます。移行したばかりのアプリで行うことができる従来の単体テストと統合テスト以外にも、さまざまなテスト戦略があります。新しい環境は新しいバージョンのソフトウェアとして扱うことができ、トラフィックの移行は、検証に使用される A/B テストなどの一般的なパターンで実装できます。別の方法として、受信トラフィックをソース環境と新しい環境に複製して、機能が維持されるようになっていることを確認します。
- ダウンタイムの計画: トラフィックを環境間で切り替える blue/green などの移行戦略を選択する場合は、計画的なダウンタイムの導入を検討してください。ダウンタイムにより、移行を適切にモニタリングし、クライアント側で予期しないエラーを回避できます。
- ロールバック: トラフィックの移行に採用した戦略に応じて、新しい環境でエラーが発生した場合や構成ミスが発生した場合にロールバックの実施が必要になります。環境をロールバックできるようにするには、新しい環境のステータスを検出するモニタリング インフラストラクチャを用意する必要があります。
最初のリージョンで拡張テストを実行し、新しいリージョンでエラーが発生することなく本番環境に移行した場合にのみ、最初のリージョンでサービスをシャットダウンできます。新しく移行したリージョンに問題がないことが確認できるまで、最初のリージョンのバックアップを一定期間保持することをおすすめします。
また、古いリージョンを障害復旧サイトに昇格させるかどうかも検討する必要があります（まだソリューションが実装されていない場合）。このアプローチでは、サイトの信頼性を確保するために追加の設計が必要になります。DR を正しく設計して計画する方法については、障害復旧計画ガイドをご覧ください。
次のステップ
- 信頼性の高い単一リージョンおよびマルチリージョン環境を設計するための一般的な設計原則と、Google がリージョン サービスとマルチリージョン サービスでどのように高い信頼性を実現するのかについて確認する。クラウド インフラストラクチャの停止に対する障害復旧の設計: 共通のテーマをご覧ください。
- この設計ガイドで使用する Google Cloud プロダクトの詳細を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Valerio Ponza | テクニカル ソリューション コンサルタント
その他の寄稿者:
- Marco Ferrari | クラウド ソリューション アーキテクト
- Travis Webb | ソリューション アーキテクト
- Lee Gates | グループ プロダクト マネージャー
- Rodd Zurcher | ソリューション アーキテクト