Google Cloud には、仮想マシン(VM)とそのデータを Amazon Elastic Compute Cloud(Amazon EC2)から Compute Engine に移行するためのツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。このドキュメントでは、Amazon EC2 から Compute Engine に移行する計画を設計、実施、検証する方法について説明します。
このドキュメントの説明は、移行プロセスを計画して実施する方法を詳しく知りたいクラウド管理者を対象としています。また、移行の時期を考え、移行がどのようなものかを知りたい意思決定者を対象としています。
このドキュメントは、AWS からGoogle Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。
- 始めましょう
- Amazon EC2 から Compute Engine に移行する(本ドキュメント)
- Amazon S3 から Cloud Storage への移行
- Amazon EKS から Google Kubernetes Engine への移行
- Amazon RDS for MySQL および Amazon Aurora for MySQL から Cloud SQL for MySQL への移行
- Amazon RDS for PostgreSQL と Amazon Aurora for PostgreSQL から Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL への移行
- Amazon RDS for SQL Server から Cloud SQL for SQL Server への移行
- AWS Lambda から Cloud Run に移行する
Google Cloudに移行する場合は、 Google Cloudへの移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。
次の図は、移行の過程を示しています。
移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。
- ワークロードとデータを評価して検出します。
- Google Cloudで基盤を計画して構築します。
- ワークロードとデータを Google Cloudに移行します。
- Google Cloud 環境を最適化する。
このフレームワークのフェーズの詳細については、 Google Cloudへの移行: スタートガイドをご覧ください。
効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、Migrate to Google Cloud: 移行計画の検証に関するベスト プラクティスをご覧ください。
移行元の環境を評価する
評価フェーズでは、移行元の環境を Google Cloudに移行するための要件と依存関係を確認します。
移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、 Google Cloudへの移行を計画して実施するための出発点も理解する必要があります。
評価フェーズは、次のタスクで構成されます。
- ワークロードの包括的なインベントリを作成する。
- プロパティと依存関係に応じてワークロードを分類する。
- チームを Google Cloudでトレーニングして教育します。
- Google Cloudでテストと概念実証を作成する。
- ターゲット環境の総所有コスト(TCO)を計算する。
- ワークロードの移行戦略を選択する。
- 移行ツールを選択する。
- 移行計画とタイムラインを定義する。
- 移行計画を検証する。
評価フェーズとこれらのタスクの詳細については、 Google CloudGoogle 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 環境で実行されているクライアント(他のワークロードなど)と外部クライアントに公開する方法
デプロイと運用のプロセスを評価する
デプロイ プロセスと運用プロセスの仕組みを明確に理解することが重要です。これらのプロセスは、本番環境とそこで実行されるワークロードを準備して維持するプラクティスの基本となる部分です。
デプロイ プロセスと運用プロセスで、ワークロードが機能するために必要なアーティファクトをビルドする場合があります。したがって、各アーティファクト タイプに関する情報を収集する必要があります。たとえば、アーティファクトには、オペレーティング システム パッケージ、アプリケーションのデプロイ パッケージ、オペレーティング システム イメージ、コンテナ イメージなどがあります。
アーティファクト タイプに加えて、次のタスクの実施方法を検討してください。
- ワークロードを開発する。ワークロードを構築するために開発チームが実施しているプロセスを評価します。たとえば、開発チームはワークロードの設計、コーディング、テストをどのように行っているのか評価します。
- 移行元の環境にデプロイするアーティファクトを生成する。移行元の環境にワークロードをデプロイするには、コンテナ イメージやオペレーティング システム イメージなどのデプロイ可能なアーティファクトを生成するか、ソフトウェアをインストールして構成することで、サードパーティのオペレーティング システム イメージなどの既存のアーティファクトをカスタマイズします。これらのアーティファクトの生成方法に関する情報を収集すると、生成されたアーティファクトがGoogle Cloudへのデプロイに適していることを確認できます。
アーティファクトを保存する。移行元環境のアーティファクト レジストリに保存するアーティファクトを生成する場合は、 Google Cloud 環境でアーティファクトを利用可能にする必要があります。これは、次のような方法で実行できます。
- 環境間の通信チャネルを確立する: 移行元の環境のアーティファクトが移行先の環境からアクセスできるようにします。Google Cloud
- アーティファクトのビルドプロセスのリファクタリング: 移行元の環境と移行先の環境の両方にアーティファクトを保存できるように、移行元の環境のマイナー リファクタリングを完了します。このアプローチでは、ターゲット環境にアーティファクトのビルドプロセスを実装する前に、アーティファクト リポジトリなどのインフラストラクチャを構築することで、移行をサポートします。 Google Cloudこのアプローチは直接実装することも、最初に通信チャネルを確立する以前のアプローチをベースにして実装することもできます。
移行元環境と移行先環境の両方でアーティファクトを使用できるため、移行の一部としてターゲット環境にアーティファクト ビルド プロセスを実装する必要はありません。 Google Cloud
コードをスキャンして署名する。アーティファクトのビルドプロセスの一環として、コードスキャンを使用して一般的な脆弱性や意図しないネットワーク公開を防ぐことができます。また、コード署名を使用して、環境で実行されるコードが信頼できるものであることを確認できます。
ソース環境にアーティファクトをデプロイする。デプロイ可能なアーティファクトを生成した後、それらを移行元の環境にデプロイしていることがあります。各デプロイ プロセスを評価することをおすすめします。この評価により、デプロイ プロセスに Google Cloudとの互換性があるかどうかを確認できます。また、最終的にプロセスをリファクタリングするために必要な作業についても把握できます。たとえば、デプロイ プロセスが移行元の環境で機能する場合は、 Google Cloud 環境をターゲットとするようにリファクタリングが必要になることがあります。
ランタイム構成を挿入する。特定のクラスタ、ランタイム環境、ワークロード デプロイのランタイム構成を挿入していることがあります。この構成では、環境変数と、シークレット、認証情報、キーなどの構成値が初期化される場合があります。ランタイム構成の挿入プロセスが Google Cloudで機能するように、移行元の環境で実行されるワークロードの構成を評価することをおすすめします。
ロギング、モニタリング、プロファイリング。移行元環境の健全性、関心のある指標、これらのプロセスによって提供されるデータの使用方法をモニタリングするために、実装されているロギング、モニタリング、プロファイリングのプロセスを評価します。
認証。移行元の環境に対して認証を行う方法を評価します。
リソースのプロビジョニングと構成。移行元の環境を準備するために、リソースをプロビジョニングして構成するプロセスを設計して実装している場合があります。たとえば、Terraform を構成管理ツールとともに使用して、ソース環境でリソースをプロビジョニングして構成している場合があります。
基盤の計画と構築
計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。
- 環境でワークロードをサポートします。 Google Cloud
- 移行元の環境と Google Cloud 環境を接続して、移行を完了します。
計画と構築のフェーズは、次のタスクで構成されます。
- リソース階層を構築する。
- Google Cloudの Identity and Access Management(IAM)を構成します。
- お支払い情報を設定する。
- ネットワーク接続を設定する。
- セキュリティを強化する。
- ロギング、モニタリング、アラートを設定する。
これらの各タスクの詳細については、 Google Cloudへの移行: 基盤の計画と構築をご覧ください。
ワークロードの移行
Amazon EC2 から Compute Engine にワークロードを移行する手順は次のとおりです。
- Amazon EC2 から Compute Engine へ VM を移行する。
- VM ディスクを Persistent Disk に移行します。
- Compute Engine で実行されるワークロードをクライアントに公開します。
- 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 にインポートすることもできます。
VM ディスクを Persistent Disk に移行する
Migrate to VMs を使用して、Amazon EC2 VM で実行されているワークロードの中断を最小限に抑えながら、移行元の Amazon EC2 VM から Persistent Disk にディスクを移行することもできます。詳細については、VM ディスクを移行して新しい VM に接続するをご覧ください。
たとえば、Amazon EC2 VM にアタッチされているデータディスクを Persistent Disk に移行し、新しい Compute Engine VM にアタッチできます。
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 インスタンスへ適用できます。
SSH や RDP などのリモート アクセス プロトコルを使用して Amazon EC2 VM に接続する場合は、VM のパブリック IP アドレスを削除し、Identity-Aware Proxy(IAP)を使用して VM にリモートで接続できます。IAP TCP 転送を使用すると、暗号化されたトンネルを確立できます。このトンネルを使用すると、VM にパブリック IP アドレスを割り当てることなく、SSH、RDP、その他のインターネット トラフィックを VM に転送できます。IAP サービスからの接続は予約済みのパブリック IP アドレス範囲から発信されるため、一致する VPC ファイアウォール ルールを作成する必要があります。Windows ベースの VM があり、Windows ファイアウォールを有効にしている場合は、Windows ファイアウォールが IAP からの RDP 接続をブロックするように構成されていないことを確認します。詳細については、RDP のトラブルシューティングをご覧ください。
トラフィックのロード バランシング
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で以下を使用できます。
- Cloud Domains: DNS ドメインを登録できます。
- Cloud DNS: 一般公開と限定公開 DNS ゾーンと DNS レコードを管理できます。
たとえば、Amazon Route 53 を使用してドメインを登録した場合は、ドメイン登録を Cloud Domains に移管できます。同様に、Amazon Route 53 を使用して一般公開 DNS ゾーンと限定公開 DNS ゾーンを構成した場合は、その構成を Cloud DNS に移行できます。
DDoS 対策とウェブ アプリケーション ファイアウォール
AWS 環境で AWS Shield と AWS WAF を構成している場合は、Google Cloud Armor を使用して、 Google Cloud ワークロードを DDoS 攻撃や一般的な脆弱性利用型不正プログラムから保護できます。
デプロイ プロセスと運用プロセスのリファクタリング
ワークロードをリファクタリングしたら、デプロイ プロセスと運用プロセスをリファクタリングして、次のことを行います。
- 移行元の環境でリソースをプロビジョニングするのではなく、環境でリソースをプロビジョニングして構成します。 Google Cloud
- ワークロードを構築して構成し、移行元の環境にデプロイするのではなく、 Google Cloudにデプロイします。
このプロセスの前の評価フェーズで、これらのプロセスに関する情報を収集しました。
これらのプロセスで検討すべきリファクタリングの種類は、どのように設計し実装したかによって異なります。リファクタリングは、プロセスごとに最終状態をどうするのかによっても異なります。たとえば、次の点を考えます。
- これらのプロセスを移行元の環境に実装した可能性があり、 Google Cloudでも同様のプロセスを設計して実装したい場合もあります。たとえば、Cloud Build、Cloud Deploy、Infrastructure Manager を使用するようにこれらのプロセスをリファクタリングできます。
- これらのプロセスを移行元の環境外の別のサードパーティ環境に実装している場合もあります。この場合、移行元の環境ではなく Google Cloud 環境を対象とするように、これらのプロセスをリファクタリングする必要があります。
- 前述のアプローチを組み合わせたケース。
デプロイ プロセスと運用プロセスのリファクタリングは複雑になり、多大な労力が必要になる場合があります。ワークロードの移行の一環としてこれらのタスクを実行すると、ワークロードの移行が複雑になり、リスクが発生する可能性があります。デプロイ プロセスと運用プロセスを評価すると、その設計と複雑さを理解できるはずです。デプロイ プロセスと運用プロセスのリファクタリングに多大な労力が必要になると予想される場合は、これらのプロセスを別の専用プロジェクトの一部としてリファクタリングすることをおすすめします。
Google Cloudでデプロイ プロセスを設計して実装する方法については、以下をご覧ください。
このドキュメントでは、デプロイするアーティファクトを生成し、ターゲット ランタイム環境にデプロイするデプロイ プロセスについて説明します。リファクタリング戦略は、これらのプロセスの複雑さに大きく依存します。次のリストに、一般的なリファクタリング戦略の概要を示します。
- Google Cloudにアーティファクト リポジトリをプロビジョニングします。たとえば、Artifact Registry を使用してアーティファクトを保存し、依存関係をビルドできます。
- 移行元の環境と Artifact Registry の両方にアーティファクトを保存するように、ビルドプロセスをリファクタリングします。
- デプロイ プロセスをリファクタリングして、移行先のGoogle Cloud 環境にワークロードをデプロイします。たとえば、Artifact Registry に保存されているアーティファクトを使用して、 Google Cloudにワークロードの小さなサブセットをデプロイできます。次に、移行するすべてのワークロードがGoogle Cloudで実行されるまで、 Google Cloudにデプロイされるワークロードの数を徐々に増やします。
- アーティファクトを Artifact Registry にのみ保存するようにビルドプロセスをリファクタリングします。
- 必要に応じて、以前のバージョンのアーティファクトを移行して、移行元環境のリポジトリから Artifact Registry にデプロイします。たとえば、コンテナ イメージを Artifact Registry にコピーできます。
- リポジトリが不要になったら、移行元の環境のリポジトリを廃止します。
移行中に予期しない問題が発生した場合のロールバックを容易にするために、 Google Cloud への移行中に、 Google Cloud の現在のアーティファクト リポジトリと Artifact Registry の両方にコンテナ イメージを保存できます。最後に、移行元の環境の運用停止の一環として、コンテナ イメージのビルドプロセスをリファクタリングして、アーティファクトをGoogle Cloud にのみ保存できます。
移行の成功に不可欠ではないかもしれませんが、以前のバージョンのアーティファクトを移行元の環境から Google Cloudのアーティファクト リポジトリに移行することが必要になる場合があります。たとえば、ワークロードを任意の時点にロールバックできるようにするには、以前のバージョンのアーティファクトを Artifact Registry に移行する必要があります。詳細については、サードパーティ レジストリからイメージを移行するをご覧ください。
Artifact Registry を使用してアーティファクトを保存する場合は、アクセス制御、データ流出防止、脆弱性スキャン、Binary Authorization など、アーティファクト リポジトリを保護する制御を構成することをおすすめします。詳細については、アクセスを制御してアーティファクトを保護するをご覧ください。
Google Cloud 環境を最適化する
最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。
- 現在の環境、チーム、最適化ループを評価する。
- 最適化の要件と目標を設定する。
- 環境とチームを最適化する。
- 最適化ループを調整する。
最適化の目標を達成するまで、このシーケンスを繰り返します。
Google Cloud 環境の最適化の詳細については、 Google Cloudへの移行: 環境を最適化すると Google Cloud アーキテクチャ フレームワーク: パフォーマンスの最適化をご覧ください。
次のステップ
- AWS から他のプラットフォームへの移行の工程を確認する。 Google Cloud
- AWS サービスや Azure サービスと Google Cloudを比較する方法を学習する。
- 移行に関するヘルプを確認するタイミングを確認する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Marco Ferrari | クラウド ソリューション アーキテクト