AWS から Google Cloud への移行: Amazon EC2 から Compute Engine への移行

Last reviewed 2023-10-13 UTC

Google Cloud では、仮想マシン（VM）とそのデータを Amazon Elastic Compute Cloud（Amazon EC2）から Compute Engine に移行するためのツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。このドキュメントでは、Amazon EC2 から Compute Engine に移行する計画を設計、実施、検証する方法について説明します。

このドキュメントの説明は、移行プロセスを計画して実施する方法を詳しく知りたいクラウド管理者を対象としています。また、移行の時期を考え、移行がどのようなものかを知りたい意思決定者を対象としています。

このドキュメントは、AWS から Google Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。

このシリーズは、次のドキュメントを読み、その内容を理解していることを前提としています。

次の図は、移行の過程を示しています。移行シナリオの場合、デプロイ フェーズは移行プロセスの実行と同じです。

4 フェーズの移行パス

Amazon EC2 から Compute Engine には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行し、他のワークロードを後で移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに沿って操作します。

  1. ワークロードとデータを評価して検出します。
  2. Google Cloud で基盤を計画し、構築します。
  3. ワークロードとデータを Google Cloud に移行します。
  4. Google Cloud 環境を最適化します。

このフレームワークのフェーズの詳細については、Google Cloud への移行: スタートガイドをご覧ください。

移行元の環境を評価する

評価フェーズでは、Amazon EC2 から Compute Engine に移行するリソースの要件と依存関係を決定します。

評価フェーズは、次のタスクで構成されます。

  1. ワークロードの包括的なインベントリを構築する。
  2. プロパティと依存関係に応じてワークロードを分類する。
  3. チームを Google Cloud でトレーニングして教育する。
  4. Google Cloud 上でテストと概念実証を作成する。
  5. ターゲット環境の総所有コスト（TCO）を計算する。
  6. 移行するワークロードの順序と優先度を決定する。

評価フェーズとこれらのタスクの詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。

Amazon EC2 インスタンスのインベントリを構築する

移行の対象範囲を設定するには、Amazon EC2 インスタンスのインベントリを構築します。このインベントリを使用して、インスタンスにワークロードをデプロイするデプロイ プロセスと運用プロセスを評価できます。

Amazon EC2 インスタンスのインベントリを構築するには、Google Cloud の統合プラットフォームである Migration Center を使用することをおすすめします。これを使用すると、現在の環境から Google Cloud へのエンドツーエンドのクラウド移行を加速できます。Migration Center を使用すると、Amazon EC2 やその他の AWS リソースからデータをインポートできます。Migration Center は、関連性が高い Google Cloud サービスを移行先として推奨します。

Migration Center を使用して環境を評価したら、Migration Center ディスカバリー クライアント CLI を使用して移行に関する技術評価レポートを作成することをおすすめします。詳細については、オフライン評価のために Amazon EC2 インスタンスからゲストデータを収集するをご覧ください。

Migration Center と Migration Center ディスカバリー クライアント CLI が提供するデータでは、対象項目を完全には取得できない場合があります。その場合は、該当のデータを、AWS API、AWS デベロッパー ツール、AWS コマンドライン インターフェースに基づいて作成した他のデータ収集メカニズムの結果と統合できます。

Migration Center と Migration Center ディスカバリー クライアント CLI から取得するデータに加えて、移行する Amazon EC2 インスタンスごとに次のデータポイントを考慮します。

  • デプロイのリージョンとゾーン
  • インスタンスのタイプとサイズ
  • インスタンスの起動元となる Amazon マシンイメージ（AMI）
  • インスタンスのホスト名と、他のインスタンスとワークロードがこのホスト名を使用してインスタンスと通信する方法
  • インスタンス タグ、メタデータ、ユーザーデータ
  • インスタンスの仮想化タイプ
  • インスタンス購入オプション（オンデマンド購入、スポット購入など）
  • インスタンスのデータ保存方法（インスタンス ストアや Amazon EBS ボリュームの使用など）
  • インスタンスのテナンシー構成
  • インスタンスが特定のプレースメント グループに属しているかどうか
  • インスタンスが特定の自動スケーリング グループに属しているかどうか
  • インスタンスが属するセキュリティ グループ
  • インスタンスに関連するすべての AWS ネットワーク ファイアウォール構成
  • インスタンスで実行されるワークロードが AWS Shield と AWS WAF によって保護されるかどうか
  • インスタンスのプロセッサ状態を制御しているかどうか、インスタンスで実行されるワークロードにプロセッサ状態がどのような影響を与えるか
  • インスタンス I/O スケジューラの構成
  • インスタンスで実行されるワークロードを、AWS 環境で実行されているクライアント（他のワークロードなど）と外部クライアントに公開する方法

デプロイと運用のプロセスを評価する

Amazon EC2 インスタンスのインベントリを構築したら、デプロイと運用のプロセスを評価することをおすすめします。デプロイ プロセスと運用プロセスの仕組みを明確に理解することが重要です。これらは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。

次のタスクの実行方法を検討してください。

  • AWS リソースをプロビジョニングして構成する。AWS 環境を準備するために、リソースをプロビジョニングして構成するプロセスを設計して実装したかも知れません。たとえば、AWS CloudFormation や Terraform を構成管理ツールとともに使用して、AWS クラウド リソースのプロビジョニングや構成をしている場合もあります。
  • Amazon EC2 インスタンスの AMI を生成する。AMI の生成方法と、その AMI に適用するカスタマイズの種類を評価することが重要です。この情報により、ワークロードに適したランタイム環境を確保できます。たとえば、オペレーティング システム（OS）パッケージのインストールや OS の構成の調整などを行います。
  • Amazon EC2 インスタンスにデプロイするアーティファクトを生成する。Amazon EC2 にワークロードをデプロイする場合、パッケージ化されたワークロードやコンテナ イメージなど、デプロイ可能なアーティファクトを生成する場合があります。これらのアーティファクトの生成方法に関する情報を収集すると、生成されたアーティファクトが Google Cloud へのデプロイに適していることを確認できます。たとえば、AWS のアーティファクト レジストリに保存するアーティファクトを生成する場合は、これらのアーティファクトを Google Cloud 環境で使用できるようにする方法を検討する必要があります。
  • Amazon EC2 インスタンスにアーティファクトをデプロイする。デプロイ可能なアーティファクトを生成した後、それらを Amazon EC2 にデプロイできます。各デプロイ プロセスを評価することをおすすめします。この評価により、デプロイ プロセスに Google Cloud との互換性があるかどうかを確認できます。また、最終的にプロセスをリファクタリングするために必要な作業についても把握できます。たとえば、デプロイ プロセスが Amazon EC2 でのみ機能する場合は、Google Cloud 環境をターゲットとするようにリファクタリングが必要になることがあります。
  • ランタイム構成を挿入する。特定の Amazon EC2 インスタンス、ランタイム環境、ワークロード デプロイの環境変数や他の構成値を初期化しているなど、インスタンスのランタイム構成を挿入していることがあります。ランタイム構成の挿入プロセスが Google Cloud で機能するように、Amazon EC2 でのワークロードの構成を評価することをおすすめします。

デプロイと運用のプロセスを評価したら、これらのプロセスが Google Cloud への移行にどのように役立つか、また移行のスコープとリスクを軽減する方法を評価することもおすすめします。たとえば、移行中に、AWS と Google Cloud の両方にアーティファクトを保存するように、アーティファクト ビルド プロセスをリファクタリングできます。両方の環境にアーティファクトが存在するため、移行プロセスの開始時にターゲットの Google Cloud 環境にアーティファクト ビルド プロセスを実装しなくても、Amazon EC2 インスタンスの移行に集中できます。

評価を完了する

Amazon EC2 環境からインベントリを構築したら、Google Cloud への移行: ワークロードの評価と検出で説明されている評価フェーズの残りの作業を実施します。

基盤の計画と構築

計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。

  • Google Cloud 環境でワークロードをサポートします。
  • AWS 環境と Google Cloud 環境を接続して、移行を完了します。

計画と構築のフェーズは、次のタスクで構成されます。

  1. リソース階層を構築する。
  2. Identity and Access Management を構成する。
  3. お支払い情報を設定する。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. ロギング、モニタリング、アラートを設定する。

これらの各タスクの詳細については、Google Cloud への移行: 基盤の構築をご覧ください。

ワークロードを移行する

Amazon EC2 から Compute Engine にワークロードを移行する手順は次のとおりです。

  1. Amazon EC2 から Compute Engine へ VM を移行する。
  2. Compute Engine で実行されるワークロードをクライアントに公開します。
  3. Amazon EC2 ではなく Google Cloud を対象にデプロイ プロセスと運用プロセスをリファクタリングします。

以降のセクションでは、これらの各タスクについて詳しく説明します。

Compute Engine への VM の移行

Amazon EC2 から Compute Engine に VM を移行するには、フルマネージド サービスである Migrate to Virtual Machines を使用することをおすすめします。詳細については、Migrate to VMs による移行の流れをご覧ください。

Migrate to Virtual Machines は移行処理の中で、必須の構成変更を除いて状態を維持したまま Amazon EC2 インスタンスを移行します。Amazon EC2 インスタンスがカスタマイズされた Amazon EC2 AMI を実行している場合、Migrate to Virtual Machines はこれらのカスタマイズを Compute Engine インスタンスに移行します。ただし、インフラストラクチャを再現性のあるものにするには、このドキュメントで後述するように、デプロイ プロセスと運用プロセスの一環として、Compute Engine オペレーティング システムのイメージを作成して、同等のカスタマイズを適用する必要があるかもしれません。Amazon EC2 AMI を Compute Engine にインポートすることもできます。

Compute Engine で実行されるワークロードを公開する

Amazon EC2 インスタンスを Compute Engine インスタンスに移行した後は、ワークロードをクライアントに公開するように Google Cloud 環境をプロビジョニングして構成する必要があります。

Google Cloud は、ワークロードをクライアントに公開するための安全で信頼性の高いサービスとプロダクトを提供します。Compute Engine インスタンスで実行されるワークロードの場合、次のカテゴリのリソースを構成します。

  • ファイアウォール
  • トラフィックのロード バランシング
  • DNS 名、ゾーン、レコード
  • DDoS 対策とウェブ アプリケーション ファイアウォール

これらのカテゴリごとに、同等のカテゴリの AWS サービスとリソースを構成したのと同様のベースライン構成を実装することから始めます。その後、構成を反復処理し、Google Cloud サービスで提供される追加機能を使用できます。

以降のセクションでは、これらのカテゴリの Google Cloud リソースをプロビジョニングして構成する方法と、同様のカテゴリの AWS リソースにマッピングする方法について説明します。

ファイアウォール

AWS セキュリティ グループと AWS ネットワーク ファイアウォールのポリシーとルールを構成した場合は、Cloud 次世代ファイアウォールのポリシーとルールを構成できます。VPC Service Controls ルールをプロビジョニングして、VPC 内のネットワーク トラフィックに制限をかけることもできます。VPC Service Controls を使用すると、Compute Engine インスタンスへの不要なネットワーク接続をブロックし、データ漏洩のリスクを軽減できます。

たとえば、AWS セキュリティ グループを使用して Amazon EC2 インスタンスへの接続を許可または拒否する場合、同様の Virtual Private Cloud（VPC）ファイアウォール ルールを構成し、Compute Engine インスタンスへ適用できます。

トラフィックのロード バランシング

AWS 環境で Elastic ロード バランシング（ELB）を構成している場合は、Cloud Load Balancing を構成してネットワーク トラフィックを分散すると、Google Cloud のワークロードのスケーラビリティを向上させることができます。Cloud Load Balancing は、OSI モデルのさまざまなレイヤ（トランスポート レイヤやアプリケーション レイヤなど）で動作するいくつかのグローバルおよびリージョン ロード バランシング プロダクトをサポートしています。ワークロードの要件に適したロード バランシング プロダクトを選択できます。

Cloud Load Balancing では、ネットワーク トラフィックを暗号化する Transport Layer Security（TLS）の構成もサポートされています。Cloud Load Balancing に TLS を構成する場合は、要件に応じてセルフマネージド TLS 証明書または Google マネージド TLS 証明書を使用できます。

DNS 名、ゾーン、レコード

AWS 環境で Amazon Route 53 を使用している場合は、Google Cloud で以下を使用できます。

たとえば、Amazon Route 53 を使用してドメインを登録した場合は、ドメイン登録を Cloud Domains に移管できます。同様に、Amazon Route 53 を使用して一般公開 DNS ゾーンと限定公開 DNS ゾーンを構成した場合は、その構成を Cloud DNS に移行できます。

DDoS 対策とウェブ アプリケーション ファイアウォール

AWS 環境で AWS Shield と AWS WAF を構成している場合は、Google Cloud Armor を使用して、Google Cloud ワークロードを DDoS 攻撃や一般的な脆弱性利用型不正プログラムから保護できます。

デプロイ プロセスと運用プロセスのリファクタリング

VM を Compute Engine に移行したら、プロセスをリファクタリングして、次のことを行います。

  • Amazon EC2 インスタンスや Amazon EC2 AMI などの AWS リソースをプロビジョニングするのではなく、Google Cloud 環境でリソースをプロビジョニングして構成します。
  • Amazon EC2 にワークロードをデプロイするのではなく、Compute Engine でワークロードをビルド、デプロイ、構成します。

このプロセスの前の評価フェーズで、これらのプロセスに関する情報を収集しました。

これらのプロセスで検討すべきリファクタリングの種類は、どのように設計し実装したかによって異なります。リファクタリングは、プロセスごとに最終状態をどうしたいかによっても異なります。たとえば、次の点を考えます。

  • これらのプロセスを AWS 環境に実装した可能性があり、Google Cloud でも同様のプロセスを設計して実装したい場合もあります。
  • これらのプロセスを AWS 環境外の別のサードパーティ環境に実装している場合もあります。この場合、AWS 環境ではなく Google Cloud 環境を対象とするように、これらのプロセスをリファクタリングする必要があります。
  • 前述のアプローチを組み合わせたケース。

デプロイ プロセスと運用プロセスのリファクタリングは複雑になり、多大な労力が必要になる場合があります。VM の移行の一環としてこれらのタスクを実行すると、移行が複雑になり、リスクが発生する可能性があります。デプロイ プロセスと運用プロセスを評価すると、その設計と複雑さを理解できるはずです。デプロイ プロセスと運用プロセスのリファクタリングに多大な労力が必要になると予想される場合は、これらのプロセスを別の専用プロジェクトの一部としてリファクタリングすることをおすすめします。

Google Cloud でデプロイ プロセスを設計して実装する方法については、次のドキュメントをご覧ください。

移行後の環境を最適化する

すべての移行フェーズを完了すると、移行は完了したものとみなされます。ただし、場合によっては Google Cloud 環境をさらに最適化する必要があります。詳細については、Migrate to VMs による移行の流れ: 環境を最適化するをご覧ください。

次のステップ