AWS Application Migration Service(AWS MGN)のアーキテクチャとライフサイクルの関係、使い方の注意点まとめ − AWS Server Migration Service(AWS SMS)との違いも含めて

小西秀和です。
今回はAWS Application Migration Service(AWS MGN)について実際に使ってみた経験からアーキテクチャとライフサイクルの関係、使い方の注意点をまとめてみたいと思います。

今回の記事の内容は次のような構成になっています。

AWS Application Migration Service(AWS MGN)とは
AWS Application Migration Service(AWS MGN)とAWS Server Migration Service(AWS SMS)との違い
AWS MGNの基本的なアーキテクチャとライフサイクルの関係、使い方の注意点
- AWS MGNにおけるライフサイクルの状態と次の状態に進むためのアーキテクチャにおけるステップの関係
まとめ

AWS Application Migration Service(AWS MGN)とは

AWS MGNはオンプレミス、プライベートクラウド、AWSおよびそれ以外のパブリッククラウドの仮想マシン(VM)上で動作している既存のアプリケーションをリフト・アンド・シフトでAWSクラウドへそのままの構成で移行するサービスです。
AWS MGNでは継続的なブロックレベルのレプリケーションを使用してAWS上に最新の移行元VMのデータを保存し、そのデータからAmazon EC2インスタンスを起動してテストとカットオーバーの手順を実行することができます。

AWS Application Migration Service(AWS MGN)とAWS Server Migration Service(AWS SMS)との違い

AWS Application Migration Service(AWS MGN)がアナウンスされる前からAWS Server Migration Service(AWS SMS)という移行サービスがあります。
AWS MGNとAWS SMSはVM環境をAWSへ移行するという観点では似ているサービスですが、大きく以下の点が異なります。

比較項目	AWS Application Migration Service(AWS MGN)	AWS Server Migration Service(AWS SMS)
移行の焦点	オンプレミス、プライベートクラウド、AWSおよびそれ以外のパブリッククラウドの仮想マシン(VM)上で動作している既存のアプリケーションの移行に焦点を当てている(ブロックレベルの継続的なデータレプリケーションを使用する)。	オンプレミス、プライベートクラウドのVM(VMware vSphere、Microsoft Hyper-Vなど)の移行に焦点を当てている。
対象としている環境	オンプレミスやプライベートクラウドのVM(VMware vSphere、Microsoft Hyper-Vなど)、加えてAWSおよびそれ以外のパブリッククラウドのVMを対象としている。	オンプレミスやプライベートクラウドのVM(VMware vSphere、Microsoft Hyper-Vなど)とAmazon EC2を対象としている。
使用できる移行方法	VMにエージェントをインストールしてアウトバウンドアクセスを使用した移行ができる。また、VMware vCenter環境にClientをインストールするエージェントレスレプリケーションもサポートしている。	SMS ConnectorをVMware vSphereのVMware vCenter環境やMicrosoft Hyper-Vホストにインストールして移行する(エージェントを使用した移行はサポートされていない)。

このようにAWS MGNはAWS SMSよりもより広い環境のVMをより柔軟で自動化された方法で移行できるという特徴があります。

AWS MGNの基本的なアーキテクチャとライフサイクルの関係、使い方の注意点

次にAWS MGNの基本的なアーキテクチャの各ステップに番号(A-1, B-1など)を付与した構成図を使用してAWS MGNのライフサイクルとの関係と使い方の注意点を説明していきます。

このアーキテクチャでは、次の移行方法を前提としています。
・移行元のVMサーバーにAWS Replication Agentをインストールして移行する(エージェントレスレプリケーションではない)。
・転送中のデータを暗号化し、インターネット経由で移行する(AWS Direct Connect、AWS Site-to-Site VPNは使用していない)。

AWS MGNにおけるライフサイクルの状態と次の状態に進むためのアーキテクチャにおけるステップの関係

AWS MGNのライフサイクルの状態にはNot ready, Ready for testing, Test in progress, Ready for cutover, Cutover in progress, Cutover completeがあり、状態遷移図にすると次のようになります。

この状態遷移図のアクションに前述の「AWS MGNの基本的なアーキテクチャとステップ」の構成図にある各ステップを関連付けると次のようになります。

上記のAWS MGNにおけるライフサイクルの状態と次の状態に進むためのアーキテクチャにおけるステップの関係について詳細を以下で説明していきます。

[Not ready(準備ができていません)]

この状態は、サーバーが初期同期プロセス中で、まだテストの準備ができていない状態です。
次の状態に進むには、まず構成図中の次のステップを実行します。

(A-1). Install AWS Replication Agent(AWS Replication Agentのインストール)

最初にAWS Replication Agentを実行するIAMユーザーを作成し、次のAWSマネージドポリシーを必要に応じてアタッチします。

AWSApplicationMigrationAgentInstallationPolicy
AWSApplicationMigrationAgentPolicy
AWSApplicationMigrationAgentPolicy_v2
AWSApplicationMigrationFullAccess
AWSApplicationMigrationReplicationServerPolicy

その後、IAMユーザーのアクセスキー、シークレットキーを作成します。
続いてAWS MGNのAWS Management ConsoleでSource servers > Add serverに遷移し、必要情報を入力して出力される次のようなコマンドを移行元のVMサーバーで実行してAWS Replication Agentをインストールします。

[ho2k_com@ho2k-com ~]$ sudo wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init
[ho2k_com@ho2k-com ~]$ sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init --region ap-northeast-1 --aws-access-key-id XXXXXXXXXXXXXXXXXXXX --aws-secret-access-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --no-prompt

Note: AWS Replication Agentのインストールに失敗する場合にはInstallation requirementsの要件を満たしているかを確認してください。
その中でも特に次の点を確認することをおすすめします。
- 移行元のVMサーバーのRAMの容量が十分か
  上記のドキュメントには少なくとも300MBのRAMが必要と記載がありますが、実際のエージェント実行にはそれ以上のRAM容量を使用することがあります。そのため、可能であれば2GB以上のRAMでAWS Replication Agentをインストール、実行を試みることを個人的におすすめします。
- インターネット経由の接続の場合、移行元のVMサーバーがHTTPS(TCP 443)でAWS MGNのサービスエンドポイントにアウトバウンドアクセスできるか
  移行元のVMサーバーがあるネットワークやファイアウォールのアクセス制限の設定、Webプロキシサーバーがある場合はその設定ができているかを確認することをおすすめします。

また、その他の問題が発生する場合はTroubleshootingを参考にして対処します。

問題が解決し、AWS Replication AgentのインストールとAWS MGNのサービスエンドポイントへのアクセスが成功すると、構成図中の次のステップが自動的に実行されます。

(B-1). API Calls for Authentication, Configuration, Monitoring, and Synchronize Status(認証、設定、監視、ステータス同期のためのAPI呼び出し)
(B-2). Retrieve Software Component(ソフトウェアコンポーネントの取得)
(B-3). Launch Replication Server(レプリケーションサーバーの起動)
(B-4). Data Replication(データレプリケーション)
(B-5). Create Launchable Snapshot(起動可能なスナップショットの作成)

Note: これらのステップでエラーが発生した場合はTroubleshootingを参考にして対処します。
その中でも特に次の点を確認することをおすすめします。
- 移行元のVMサーバーからレプリケーションサーバーにデータレプリケーションに必要なTCP 1500ポートでアクセスできるか
  移行元のVMサーバーがあるネットワークやファイアウォールのアクセス制限の設定を確認することをおすすめします。

問題が解決し、初期同期のデータレプリケーションが完了すると移行元のVMサーバーに対してテストインスタンスを立ち上げれる状態になります。

Note: 移行元のVMサーバーがあるネットワークからTCP 1500ポートにアクセスするIPアドレスを限定したい場合は、Elastic IPアドレスをレプリケーションサーバーに割り当て、Elastic IPアドレスに対してTCP 1500ポートのアクセスを許可します。
AWS Replication Agentはレプリケーションサーバーに割り当てられたElastic IPアドレスを自動的に判別してトラフィックを送信するようです。
Note: 「(B-4). Data Replication(データレプリケーション)」のステップではレプリケーションサーバーのEBSボリュームにブロックレベルの継続的なデータレプリケーションでデータを書き込み、ソースサーバーを最新の状態に保ちます。
後述するテストインスタンスまたはカットオーバーインスタンスの起動のステップではこのEBSボリュームからデータ変換したSnapshotが使用されるため、このSnapshotを作成する直前までに移行元のVMサーバーからEBSボリュームへレプリケートしたデータがテストインスタンスまたはカットオーバーインスタンスに反映されます。

一方でレプリケーションサーバーのあるStaging Area Subnetから構成図中の次のステップが必要に応じて実行されます。

(E). API Calls for Authentication, Configuration, Monitoring, etc.
(E). API Calls for Retrieve Software Component, etc.

[Ready for testing(テストの準備完了)]

この状態は、サーバーの初期同期が完了し、サーバーに対してテストインスタンスを立ち上げれる状態です。
この状態から次の状態に進むには、まずAWS MGNのAWS Management ConsoleにあるActive source serversからVMサーバーに対応するソースサーバーを選択し、テストインスタンスおよびカットオーバーインスタンスで使用する「Launch settings」を設定します。

「Launch settings」では移行元のVMサーバーと移行先のEC2インスタンスの要件に合わせて、実際に起動するEC2インスタンスのインスタンスタイプやサブネットなどを設定しますが、特に注意した方が良い設定は次の点です。

Note:「General launch settings」で「Instance type right sizing」をOnにするかOffにするか
「Instance type right sizing」がOnになっていると「EC2 Launch Template」に設定したインスタンスタイプに関わらずAWS MGNが自動的に最適なインスタンスタイプを指定します。
そのため、ユーザーの意図しないインスタンスタイプでテストインスタンスが起動することがあります。
特に移行元のVMサーバーでEnhanced Networking(拡張ネットワーキング)に必要なENAモジュールがインストールされていない場合などは、Enhanced Networkingをサポートしたインスタンスタイプで起動を試みて失敗するパターンも考えられます。
このような場合には「Instance type right sizing」をOffにして「EC2 Launch Template」で適切なインスタンスタイプを設定することでユーザーの意図したインスタンスタイプでEC2インスタンスが起動するようになります。

「Launch settings」を設定後、AWS MGNのAWS Management Consoleで対象のソースサーバーに対して「Launch test instances」を選択してテストインスタンスを起動すると構成図中の次のステップが実行されます。

(C-1). Launch Conversion Server(コンバージョンサーバーの起動)
(C-2). Convert Disk to Bootable Snapshot(ディスクを起動可能なスナップショットに変換)
(C-3). Launch Test EC2 Instance(テストインスタンスを起動する)

Note: これらのステップでエラーが発生した場合はTroubleshootingを参考にして対処します。
また、前述した「Launch settings」の設定に問題が無いかについても確認することをおすすめします。
Note: 「(C-2). Convert Disk to Bootable Snapshot」のステップではブロックレベルの継続的なデータレプリケーションで移行元のVMサーバーのデータが書き込まれたレプリケーションサーバーのEBSボリュームからデータを変換してSnapshotを作成します。
そのため、このSnapshotを作成する直前までに移行元のVMサーバーからEBSボリュームへレプリケートしたデータがテストインスタンスに反映されます。

また、「Launch settings」の設定に加えて、AWS Systems Manager Agent(SSM Agent)を使用してテストインスタンスおよびカットオーバーインスタンスが起動された後に実行されるアクションを制御および自動化する「Post-launch settings」の設定をしていると構成図中の次のステップが実行されます。

(F). API Calls for Post-launch settings, etc.

一方でレプリケーションサーバーとコンバージョンサーバーのあるStaging Area Subnetから構成図中の次のステップが必要に応じて実行されます。

(E). API Calls for Authentication, Configuration, Monitoring, etc.
(E). API Calls for Snapshot creation, etc.
(E). API Calls for Retrieve Software Component, etc.

[Test in progress(テストが進行中)]

この状態は、サーバーに対するテストインスタンスが起動している状態です。

次の状態に進むには、まずテストインスタンスで移行元のVMサーバーのデータ移行確認、アプリケーションの動作確認などのテストを実施し、カットオーバーできるかどうかを判断します。

カットオーバーできると判断した場合は、AWS MGNのAWS Management Consoleで対象のソースサーバーに対して「Mark as "Ready for cutover"」を選択することで次の「Ready for cutover」の状態に進みます。

一方で、テストを実施して問題がある場合など前の状態である「Ready for testing」に戻したい場合はAWS MGNのAWS Management Consoleで対象のソースサーバーに対して「Revert to "Ready for testing"」を選択します。

[Ready for cutover(カットオーバーの準備完了)]

この状態は、サーバーのテストが完了し、カットオーバーインスタンスを立ち上げれる状態です。
「Ready for cutover」の状態から次の「Cutover in progress」に進む手順は前述の「Ready for testing」の状態から「Test in progress」に進む手順とほぼ同じですが詳細な違いの把握と理解の促進のために記載しておきます。

この状態から次の状態に進むには、まずAWS MGNのAWS Management ConsoleにあるActive source serversからVMサーバーに対応するソースサーバーを選択し、テストインスタンスおよびカットオーバーインスタンスで使用する「Launch settings」を設定します。

「Launch settings」では移行元のVMサーバーと移行先のEC2インスタンスの要件に合わせて、実際に起動するEC2インスタンスのインスタンスタイプやサブネットなどを設定しますが、特に注意した方が良い設定は次の点です。

Note: 「General launch settings」で「Instance type right sizing」をOnにするかOffにするか
「Instance type right sizing」がOnになっていると「EC2 Launch Template」に設定したインスタンスタイプに関わらずAWS MGNが自動的に最適なインスタンスタイプを指定します。
そのため、ユーザーの意図しないインスタンスタイプでカットオーバーインスタンスが起動することがあります。
特に移行元のVMサーバーでEnhanced Networking(拡張ネットワーキング)に必要なENAモジュールがインストールされていない場合などは、Enhanced Networkingをサポートしたインスタンスタイプで起動を試みて失敗するパターンも考えられます。
このような場合には「Instance type right sizing」をOffにして「EC2 Launch Template」で適切なインスタンスタイプを設定することでユーザーの意図したインスタンスタイプでEC2インスタンスが起動するようになります。

「Launch settings」を設定後、AWS MGNのAWS Management Consoleで対象のソースサーバーに対して「launch cutover instances」を選択してカットオーバーインスタンスを起動すると構成図中の次のステップが実行されます。

(D-1). Launch Conversion Server(コンバージョンサーバーの起動)
(D-2). Convert Disk to Bootable Snapshot(ディスクを起動可能なスナップショットに変換)
(D-3). Launch Cutover EC2 Instance(カットオーバーインスタンスを起動する)

Note: これらのステップでエラーが発生した場合はTroubleshootingを参考にして対処します。
また、前述した「Launch settings」の設定に問題が無いかについても確認することをおすすめします。
Note: 「(D-2). Convert Disk to Bootable Snapshot」のステップではブロックレベルの継続的なデータレプリケーションで移行元のVMサーバーのデータが書き込まれたレプリケーションサーバーのEBSボリュームからデータを変換してSnapshotを作成します。
そのため、このSnapshotを作成する直前までに移行元のVMサーバーからEBSボリュームへレプリケートしたデータがカットオーバーインスタンスに反映されます。

(F). API Calls for Post-launch settings, etc.

[Cutover in progress(カットオーバーが進行中)]

この状態は、サーバーに対するカットオーバーインスタンスが起動している状態です。
次の状態に進むには、まずカットオーバーインスタンスで移行元のVMサーバーのデータ移行確認、アプリケーションの動作確認などのテストを実施し、カットオーバーを完了できるかどうかを判断します。

カットオーバーを完了できると判断した場合は、AWS MGNのAWS Management Consoleで対象のソースサーバーに対して「Finalize cutover」を選択することで次の「Cutover complete」の状態に進みます。

一方で、テストを実施して問題がある場合など前の状態である「Ready for cutover」に戻したい場合はAWS MGNのAWS Management Consoleで対象のソースサーバーに対して「Revert to "Ready for cutover"」を選択します。

Note: 「Finalize cutover」を選択して次の「Cutover complete」の状態に進むと移行元のVMサーバーからレプリケーションサーバーのEBSボリュームへのデータレプリケーションは切断されてレプリケートされたデータが全て破棄されます。
また、ソースサーバーに対するデータレプリケーションに使用されていたすべてのAWSリソースも削除され、ライフサイクルの前の状態に戻ることはできなくなります。

[Cutover complete(カットオーバー完了)]

この状態は、サーバーに対するカットオーバーが完了し、データレプリケーションが切断され、移行が完了した状態です。
この状態ではデータレプリケーションは切断されてレプリケートされたデータが全て破棄され、ソースサーバーに対するデータレプリケーションに使用されていたすべてのAWSリソースも削除されています。
AWS MGNのAWS Management Consoleで対象のソースサーバーに対して「Actions 」の「Mark as archived」を選択すると、カットオーバーが完了したソースサーバーとカットオーバーが未完了のソースサーバーをフィルタリングで分けて参照できるようになります。

参考：
AWS Documentation(Application Migration Service User Guide)
How to Use the New AWS Application Migration Service for Lift-and-Shift Migrations | AWS News Blog
AWS Application Migration Service Architecture - YouTube
Tech Blog with related articles referenced

まとめ

今回はAWS Server Migration Service(AWS SMS)との違いも含めて、AWS Application Migration Service(AWS MGN)のアーキテクチャとライフサイクルの関係、使い方の注意点をまとめました。

AWS MGNは要件を満たした上でエージェントを使用すれば、VMware vSphere、Microsoft Hyper-Vなどのハイパーバイザーを変更することなく、アウトバウンドのHTTPS、TCP 1500ポートのトラフィックを許可することで簡単にVMをアプリケーションごとリフト・アンド・シフトでAWSに移行することができます。
ライフサイクルの状態とアーキテクチャのステップの関係を知った上でAWS MGNを活用すれば、自動化された移行フローの内容を把握しながら、複雑な移行作業をシンプルに、かつ安全に行うことが可能です。

これからも機会があれば今回のようなAWSへの移行を支援するようなサービスについてもウォッチしていきたいと思います。