マルチクラウド ワークロードの移行

このページでは、アマゾン ウェブ サービス（AWS）または Microsoft Azure から Google Cloudにワークロードを移行するためのアーキテクチャ ガイダンス、クロス クラウド サービス マッピング、移行戦略について説明します。

クラウド アーキテクト、プラットフォーム エンジニア、インフラストラクチャ リードは、このページの情報を使用して、サードパーティのクラウド サービスをGoogle Cloud の同等のサービスにマッピングし、クラウド間の直接データ転送を実行して、マルチクラウドの障害復旧（DR）アーキテクチャを設計します。

このページを読む前に、移行元の AWS または Azure リソースのインベントリを作成し、組織のビジネス継続性とフェイルオーバーの要件を理解しておく必要があります。

AWS と Azure のサービス マッピング

AWS または Azure から移行する場合は、次の表を使用して、以前のクラウド サービスを Google Cloud の同等のサービスにマッピングします。

部署 AWS サービス Azure サービス Google Cloud 相当
仮想マシン Amazon EC2 Azure Virtual Machines Compute Engine
マネージド Kubernetes Amazon EKS Azure Kubernetes Service（AKS） Google Kubernetes Engine（GKE）
オブジェクト ストレージ Amazon S3 Azure Blob Storage Cloud Storage
リレーショナル データベース Amazon RDS Azure SQL Database Cloud SQL または AlloyDB for PostgreSQL
クラウド データ ウェアハウス Amazon Redshift Azure Synapse Analytics BigQuery

他のクラウドからのデータ転送

Storage Transfer Service を使用して、ペタバイト規模のオブジェクト データを Amazon S3 または Azure Blob Storage から Cloud Storage に直接転送します。

Storage Transfer Service の主な機能

Storage Transfer Service には、次のデータ転送機能があります。

  • 自動転送ジョブ: ローカルのオンプレミス ネットワークを介してデータをルーティングすることなく、クラウド間のオブジェクトのコピーを定期的または 1 回限りでスケジュールします。
  • チェックサム検証: 自動ハッシュ検証を使用して、転送中にエンドツーエンドのデータの完全性を確保します。
  • 帯域幅制御: 転送レートをスロットリングして、ソース クラウド プロバイダの API 割り当て上限に達しないようにします。

詳細については、Amazon S3 からの転送と Microsoft Azure Blob Storage からの転送をご覧ください。

マルチクラウドの復元性とフェイルオーバー

Google Cloud をセカンダリ フェイルオーバー環境として確立すると、障害復旧がサポートされ、単一クラウドのリスクが軽減され、他のクラウド プラットフォームでの停止中にビジネスの継続性が維持されます。

障害復旧の構成

マルチクラウド障害復旧アーキテクチャを設計する場合は、次のデプロイ構成から選択します。

  • コールド スタンバイ: バックアップと復元のためにデータを Cloud Storage に継続的に複製し、オンデマンド デプロイに対応できる Compute Engine テンプレートを維持します。
  • ウォーム スタンバイ: Google Cloudで最小限のベースライン コンピューティング容量（小規模な GKE クラスタやリードレプリカ データベースなど）を実行し、フェイルオーバー中に迅速にスケールアップできるようにします。
  • アクティブ / アクティブのデュアル処理: グローバル Cloud Load Balancing を使用して、アクティブなユーザー トラフィックをプライマリ クラウド プロバイダと Google Cloud の両方に分散します。

詳細については、災害復旧計画ガイドとハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンをご覧ください。

次のステップ