AWS Application Migration Serviceの紹介と設定のポイント

こんにちは。エンジニアの中井です。
在宅勤務中はラジオを聞くことが多くなりました。
私の場合は、音楽だけより、適度に会話が聞こえてきた方が良いみたいです。

本記事では、AWS Application Migration Service（以下、AWS MGN）についてご紹介します。
また、AWS MGNを使った実際の移行作業について、設定変更作業を中心に説明していきます。

目次

1. AWS Application Migration Service（AWS MGN）とは
2. AWS Application Migration Serviceでの移行手順
3. 気付いた点
4. まとめ

AWS Application Migration Service（AWS MGN）とは

AWS MGNは、AWSが提供する移行サービスです。
オンプレミス・仮想・パブリッククラウドからAWSへの移行をサポートしており、シンプルな移行プロセスで、サーバをリフトアンドシフトできます。

（参考）リフトアンドシフト – AWS Application Migration Service

サービスのアーキテクチャとネットワークの概要図の詳細は公式のドキュメントをご覧ください。

（参考）AWS Application Migration Service「Service architecture and network architecture overview」

CloudEndure Migration、AWS Server Migration Serviceとの違い

従来、AWSではリフトアンドシフトの移行サービスとして、CloudEndure Migrationが提供されていました。
AWS MGNは、CloudEndureにもとづいているサービスですが、CloudEndureと違ってAWSマネジメントコンソールと統合されているのが大きな違いです。
AWSに統合されたことによって、Amazon CloudWatch や AWS CloudTrail、IAMなどとの連携がより簡単になりました。

今後は、基本的にはAWS MGNを利用することが推奨されております。
ただし移行対象サーバが、AWS MGNでは対応していないOSの場合は、引き続きCloudEndureを利用できます。

各サポート対象OSについては、公式ドキュメントをご確認ください。
2021年10月時点では、CloudEndureの方が古いOSまでサポートしているみたいです。

（参考）AWS Application Migration Service「Supported operating systems」
（参考）CloudEndure Documentation「Supported Operating Systems」

また、AWS Server Migration Service（以下、AWS SMS）は、仮想アプライアンスを使用したエージェントレスの移行サービスとなっており、オンプレミスのVMware、Hyper-Vからの大規模移行をサポートしています。

AWS SMSを利用するケースとしては、サーバにエージェントをインストールできない/インストールしたくない場合が想定されています。
AWS MGNとCloudEndure/AWS SMSのどちらを選択するかについては、公式ドキュメントに詳しく記載されておりますので、こちらもご確認ください。

（参考）AWS Application Migration Service「AWS Application Migration Service を選ぶべき場合」

AWS Application Migration Serviceでの移行手順

それではAWS MGNでの移行手順を簡単に説明していきます。
今回は、WindowsサーバとLinuxサーバそれぞれ1台をAWSへ移行するケースを想定しました。

詳細な移行手順および環境準備などについては割愛しておりますので、公式ドキュメントやBlack Belt Onlineの資料もご確認ください。
Black BeltはCloudEndureのものですが、日本語で丁寧に解説されていてとても参考になります。

（参考）AWS Application Migration Service Documentation
（参考）AWS公式オンラインセミナー資料「20200811 AWS Black Belt Online Seminar CloudEndure」

構成イメージ

以下が今回の移行の構成イメージとなります。
オンプレミスのサーバ想定で、AWS上にWindowsサーバとLinuxサーバをそれぞれ用意します。
インターネット経由でのデータ転送を行い、移行先のAWSを想定した、別VPCへの移行を行います。

AWS Application Migration Serviceのセットアップ

AWS MGNのコンソールから初めて「Get started」ボタンをクリックすると、「Replication Settings template」の設定画面が表示されます。

ここではレプリケーションサーバに関する設定を行います。

• Staging area subnet：AWS MGN用に用意したサブネットなどを指定します
• Replication Server instance type：デフォルトのまま、t3.smallとします。
  実際にレプリケーションを実施して、遅延が発生する場合はより大きいインスタンスに変更することが推奨されています
• EBS volume type（for replicating disks over 500GiB）：デフォルトのまま、gp2とします。
  補足として、500GiBより小さいディスクはこの設定に関わらず、「EBS Magnetic」で作成されます
• EBS Encryption：デフォルトのままとします。
  CMKでの暗号化が社内ポリシーなどで定められている場合は、適切なKMSの選択もできます

続いて、以下の項目でレプリケーションサーバに関する設定は完了です。

• Security groups：レプリケーションサーバに設定するセキュリティグループの設定です。
  デフォルトのSGは、全てのソースIPからのTCP1500によるアクセスが許可されています
  • インターネット経由でレプリケーションを行う場合は、AWS MGN用に新しくソースIPを制限したセキュリティグループを作成して、「Always use Application Migration Service security group」のチェックを外してそれを指定すると良いでしょう
• Data routing and throttling：今回はデフォルトのままとします
• Replication resources tags：この後起動するレプリケーションサーバ、コンバージョンサーバへタグが付与できます＞
  コストタグなどを付与しておくと良いでしょう

設定が完了すると、以下のようなソースサーバの一覧画面（空っぽですね）が表示されます。

ソースサーバへのエージェントインストール

次に、移行する対象のサーバへ、AWS MGNのエージェントをインストールします。
手順は公式ドキュメントをご確認ください。

（参考）AWS Application Migration Service 「Installation instructions」

インストール要件についても公式ドキュメントをご確認ください。
LinuxではPythonが必要となるので、まず初めにチェックしておくと良いでしょう。

（参考）AWS Application Migration Service 「Installation requirements」

また、エージェントのインストール実行時に、IAMユーザーのアクセスキーとシークレットアクセスキーが必要になるので、あらかじめ作成しておきます。必要なポリシーは以下のとおりです。

• AWSApplicationMigrationAgentPolicy

エージェントのインストール例です。

・Linuxインストール例

[root@ip-10-0-1-29 ~]# wget -O ./aws-replication-installer-init.py https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
--2021-10-11 07:12:24--  https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
Resolving aws-application-migration-service-ap-northeast-1.s3.amazonaws.com (aws-application-migration-service-ap-northeast-1.s3.amazonaws.com)... 52.219.0.205
Connecting to aws-application-migration-service-ap-northeast-1.s3.amazonaws.com (aws-application-migration-service-ap-northeast-1.s3.amazonaws.com)|52.219.0.205|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12400 (12K) [binary/octet-stream]
Saving to: ‘./aws-replication-installer-init.py’
 
100%[=================================================================================================================>] 12,400      --.-K/s   in 0s
 
2021-10-11 07:12:24 (78.4 MB/s) - ‘./aws-replication-installer-init.py’ saved [12400/12400]
 
[root@ip-10-0-1-29 ~]# sudo python3 aws-replication-installer-init.py --region ap-northeast-1 --aws-access-key-id AKIA5PQPMCEFX6SAMPLE --aws-secret-access-key 0gjp8q4/KdrJR64v+1zvdyXZVeRbSAMPLESAMPLE
The installation of the AWS Replication Agent has started.
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/xvda,/dev/nvme0n1
To replicate some of the disks, type the path of the disks, separated with a comma (for example, /dev/sda,/dev/sdb). To replicate all disks, press Enter:
Identified volume for replication: /dev/nvme0n1 of size 10 GiB
All volumes for replication were successfully identified.
Downloading the AWS Replication Agent onto the source server... Finished.
Installing the AWS Replication Agent onto the source server... Finished.
Syncing the source server with the Application Migration Service Console... Finished.
The following is the source server ID: s-6cf7a61230bSAMPLE.
The AWS Replication Agent was successfully installed.

・Windowsインストール例

PS C:\Users\Administrator\Desktop> Invoke-WebRequest -Uri https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/windows/AwsRepli
cationWindowsInstaller.exe -OutFile AwsReplicationWindowsInstaller.exe
PS C:\Users\Administrator\Desktop>
PS C:\Users\Administrator\Desktop> ./AwsReplicationWindowsInstaller.exe --region ap-northeast-1 --aws-access-key-id AKIA5PQPMCEFX6SAMPLE --aws-secret-acces
s-key 0gjp8q4/KdrJR64v+1zvdyXZVeRbSAMPLESAMPLE
The installation of the AWS Replication Agent has started.
Verifying that the source server has enough free disk space to install the AWS Replication Agent.
(a minimum of 2 GB of free disk space is required)
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: c:
To replicate some of the disks, type the path of the disks, separated with a comma (for example, C:,D:). To replicate all disks, press Enter:
Disk to replicate identified: c:0 of size 30 GiB
All volumes for replication were successfully identified.
Downloading the AWS Replication Agent onto the source server... Finished.
Installing the AWS Replication Agent onto the source server... Finished.
Syncing the source server with the Application Migration Service Console... Finished.
The following is the source server ID: s-69239c85573SAMPLE.
The AWS Replication Agent was successfully installed.
Press Enter to close...

インストールが成功すると、サーバの一覧が表示されます。
サーバ名をクリックすると、詳細なレプリケーションの状況も表示されます。

起動テンプレートの編集

まず、「Launch settings」タブから「General launch settings」を編集します。

• Instance type right sizing：Off
  後述する、EC2のインスタンスタイプを変更する場合、こちらをOffにする必要があります

次に、カットオーバーするサーバに関する設定を編集します。
「Launch settings」タブから「EC2 Launch Template」を編集します。

その名のとおり、EC2の起動テンプレートの編集画面が表示されます。

• インスタンスタイプ：今回はc5.largeを選択します。
  AWS MGNが設定したものはc4.largeだったので、より新しいインスタンスを選択した方が良いでしょう
• ストレージ：今回はgp3を選択します。
  AWS MGNが設定したものはio1でしたので、特別な要件がない限りは汎用タイプにしておいた方が良いかと思います
• ネットワークインターフェイス：移行したいサブネットを選択します。
  デフォルトのままだと、AWS MGNのセットアップ時に指定したレプリケーションサーバと同じサブネットに起動されます

最後に、今回のバージョンをデフォルトバージョンに指定します。

AWS MGNの画面から、インスタンスタイプ、ストレージ、サブネットが変わっていることが確認できます。

カットオーバー

テンプレートを編集した後は、テストインスタンスを起動して、稼働確認を行います。

この辺りは「Next actions」に記載されているとおりに進めれば良いことになってますので、複数台のサーバを同時に移行するときに、これから何をすれば良いのかわかるようになってて便利です。

この後はコンソール右上の「Test and Cutover」から、各タスクを実施していきます。

ちなみに、テストインスタンスを起動する前に、いきなりカットオーバーはできないようになってました。
ちゃんとライフサイクルどおりに実施してくださいという意思を感じます。。

次に示す順番で、各タスクを実施し、最後に「Finalize cutover」を実行すると、移行作業が完了します。

• テストインスタンスの起動
• テストインスタンスの稼働確認
• テストインスタンスの削除
• レプリケーションのラグが無いことを確認
  （必要に応じて）移行対象サーバのサービスを停止
• カットオーバーインスタンスの起動
• カットオーバーインスタンスの稼働確認
• カットオーバーの完了

気付いた点

1. レプリケーションサーバとコンバージョンサーバというものが作成されます。
   今回の作業で起動してきたレプリケーションサーバは、Amazon Linuxでした。
   その一方、コンバージョンサーバはWindowsはWindows、LinuxはAmazon Linuxでした
2. 上記で起動されるサーバについては、レプリケーション設定画面のタグを設定することにより、サーバへのタグ付与ができます。
   ただし、テストインスタンス起動後に設定した場合は反映されないようですので、最初に設定しておいた方が良さそうです
3. レプリケーションサーバのセキュリティグループですが、インターネット経由で実施する場合、デフォルトのままですとソースIPは全てのIPを許可（0.0.0.0/0）になっています。
   「Replication Settings template」にて、「Always use Application Migration Service security group」のチェックを外したうえで、必要なIPを指定したセキュリティグループを設定しましょう
4. Windowsサーバのカットオーバーですが、AWS MGNのコンソール上でのタスクが完了した後も、何度か再起動を繰り返していました。
   ステータスチェックに失敗することもあるみたいですので、カットオーバー後はしばらく（今回は10～15分）待ってから、稼働確認を行いましょう
5. 移行対象サーバの移行先のVPCおよびサブネットは、起動テンプレートを編集して決められます。
   デフォルト設定のままですと、レプリケーションサーバの設定と同じサブネットになりました。
   また、起動テンプレートを編集し、レプリケーションサーバと違うVPCでもOKでした

まとめ

AWS MGNはCloudEndureにもとづいているサービスのため、CloudEndureと同様にシンプルな手順でサーバの移行が行えました。
また、AWSマネジメントコンソールと統合されたため、他のAWSサービスと同じ操作感にて設定ができました。

ただ、2021年10月の現時点では、公式ドキュメント・コンソールどちらも日本語化がされておりませんので、注意しながら内容を確認しなければならない点が、英語が苦手な人には少し辛いかもしれません。
この辺りはブラウザの翻訳機能などを使い、事前に手順を確認するかパイロット移行などを行うと良さそうです。

以上、AWS MGNについての簡単なご説明でした。

AWS運用の決定版
ガイドブックを差し上げます

はじめてでも安心！
AWS運用支援ツール「AWSクラウドポータル」
（PDF：13ページ）

インスタンス稼働状況や、バックアップのスケジュール実行など、おすすめの機能や機能一覧を掲載！

ダウンロード（無料）

この記事を読んだらチェックしたいサービス

初めての方でも直感的に使えるAWS管理・運用支援ツール

AWSクラウドポータル

DL資料あり

AWSマネジメントコンソールを分かりやすく「見える化」