概要
MGNとは、様々なインフラ基盤で動いているアプリケーションをAWSにリフトアンドシフトでの移行をサポートしているサービスです。
今回は、AWS Application Migration Service (MGN)のハンズオンで実際にリホストの体験をしてみたいと思います。
本記事では、MGNとは何かという話はしません。実際に手を動かしてみてイメージをつかもうという趣旨の記事になっています。
AWS Application Migration Service を使用すると、物理インフラストラクチャ、VMware vSphere、Microsoft Hyper-V、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Virtual Private Cloud (Amazon VPC)、およびその他のクラウドから AWS にアプリケーションを移行できます。
MGNのアーキテクチャ概要は以下の通りです。
MGNで使用する用語については、以下になります。
| 用語 | 意味 |
|---|---|
| レプリケーション設定テンプレート | ソースの移行元環境とAWS間でデータをレプリケートするために使用されるレプリケーションサーバ（Replication Servers）とステージングエリアのサブネットStaging Area Subnetの設定を定義するテンプレート |
| AWS Replication Agent | 移行元のサーバにインストールするエージェントのこと。このエージェントがAWS上のレプリケーションサーバに1500番ポートで、データを送信する。 |
| ソースサーバー | 移行元のサーバのこと。 |
| テストインスタンス | システムの動作の検証を行う、その名の通りテスト用のインスタンス。 |
| カットオーバーインスタンス | 本番運用に使用するインスタンス |
| 変換サーバーインスタンス(Application Migration Service Conversion Server) | EBSスナップショットをもとに、ターゲットサーバがAWS上で動作するように変換を行うサーバでMGNによって起動される。主にブートローダーの変更、ハイパーバイザードライバーの挿入、クラウドツールのインストールなどを行う。 |
ステップ0 リージョンの変更
今回のハンズオンでは、us-east-1（バージニア北部）のリージョンを使用します。
1. AWSコンソールにログインして上部右側のリージョンを選択する箇所を押下します。
2. 選択肢の中からバージニア北部 us-east-1を選択します。
ステップ1 IAMユーザーの作成
まずは、IAMユーザーの作成になります。このIAMユーザーは、「AWS Replication Agent」が使用するためのものです。このエージェントは、移行元のサーバにインストールするものになります。
1. AWSコンソールから、IAM > ユーザー > ユーザーの作成を押下します。
2. ユーザー名は「MGNuser」とします。AWSマネージメントコンソールへのアクセスは不要なので、チェックは付けなくてOKです。
3. 続いて、ポリシーの設定で、「ポリシーを直接アタッチする」を選択し、許可ポリシー「AWSApplicationMigrationAgentPolicy」をアタッチします。
AWSApplicationMigrationAgentPolicy ポリシー内容
json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "mgn:SendAgentMetricsForMgn", "mgn:SendAgentLogsForMgn", "mgn:SendClientMetricsForMgn", "mgn:SendClientLogsForMgn" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "mgn:RegisterAgentForMgn", "mgn:UpdateAgentSourcePropertiesForMgn", "mgn:UpdateAgentReplicationInfoForMgn", "mgn:UpdateAgentConversionInfoForMgn", "mgn:GetAgentInstallationAssetsForMgn", "mgn:GetAgentCommandForMgn", "mgn:GetAgentConfirmedResumeInfoForMgn", "mgn:GetAgentRuntimeConfigurationForMgn", "mgn:UpdateAgentBacklogForMgn", "mgn:GetAgentReplicationInfoForMgn" ], "Resource": "*" }, { "Effect": "Allow", "Action": "mgn:TagResource", "Resource": "arn:aws:mgn:*:*:source-server/*" } ] }
4. タグは必要に応じて追加できますが今回は特に必要ないので、そのままユーザーを作成を押下してユーザーを作成します。
5. アクセスキーの作成。後続の作業でアクセスキーが必要になるので、作成しておきます。
IAM > ユーザー > MGNuserを選択して、セキュリティ認証情報のタブに移動します。アクセスキーを作成を押下して作成します。別途アクセスキーとシークレットアクセスキーは控えておいてください。
ステップ2 MGNでの操作
1. 「AWS Application Migration Service」に移動して使用を開始 > サービスをセットアップを押下
2. すると自動でレプリケーション設定テンプレートが作成されます。Replication Serversに使用されるインスタンスタイプやボリュームタイプ、ステージング領域に使用されるサブネットなどをデフォルトから変更したい場合「Application Migration Service > レプリケーションテンプレート」を選択し「編集」ボタンを押下することで修正できます。
（今回は、デフォルトのt3.small、SSD (gp3)とします。）
ステップ3 ソースサーバの作成
今回は、ハンズオン用に移行元のサーバを作成しています。
アーキテクチャ図の以下の部分に当たります。
1. 「EC2 > AMI」に移動し、パブリックイメージから「AWS MGN Workshop Training.」を検索し、選択します。このイメージにはハンズオン用のWordPressが入っています。
2. 続いて、「AMIからインスタンスを起動」を押下してソース用のサーバを作成していきます。
今回は、以下の通り設定します。（変更箇所だけ記載）
| 項目 | 変更内容 |
|---|---|
| 名前(Nameタグ) |
mgn-workshop-srcという名前をつける |
| キーペア | 既存の鍵か新しく作成する（本来セッションマネージャを使用するべき） |
| セキュリティグループ | WordPressの画面を確認するため、インバウンドの80番(http)を許可。AWS Replication Agentをインストールする必要があるため、インバウンドの22番(ssh)を許可 |
ちなみに以下の通りブラウザでアクセスするとWordPressの画面が表示されるのがわかると思います。
http://[作成したソースサーバのパブリックIP]
ステップ4 ソースサーバにReplication Agentのインストール
レプリケーションサーバにソースサーバのデータを送信するため、ソースサーバにはReplication Agentのインストールが必要になります。
1. AWS Replication Agentのインストールのため、作成したソースのインスタンスにSSHします。
2. エージェントのインストーラをwgetでダウンロードしていきます。
wget -O ./aws-replication-installer-init https://aws-application-migration-service-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/aws-replication-installer-init
3. インストーラを実行します。実行すると以下の通り各種情報を入力する必要があります。（ステップ1で作成したIAMユーザのアクセスキーとシークレットキーを使用します。）
※MGNコンソールのサーバーを追加からインストールコマンドを生成することも可能です。
sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init
[ec2-user@ip-172-31-41-87 ~]$ sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init
The installation of the AWS Replication Agent has started.
AWS Region Name: us-east-1
AWS Access Key ID: XXXXXXXXXXXXXXXX
AWS Secret Access Key: ****************************************
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 12 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-3af3a4dfe4d95c45f.
You now have 1 active source server out of a total quota of 150.
Learn more about increasing source servers limit at https://docs.aws.amazon.com/mgn/latest/ug/MGN-service-limits.html
The AWS Replication Agent was successfully installed.
- --region – インストーラーがソースサーバーを登録する AWS リージョン。
- --aws-access-key-id – インストールユーザーの認証に使用するAWS IAMアクセスキー。このパラメータが指定されていない場合は、インストーラーが入力を求めます。
- --aws-secret-access-key – インストールユーザーの認証に使用されるAWS IAMアクセスキーに関連付けられたAWS IAMシークレットアクセスキー。このパラメータが指定されていない場合、インストーラーは入力を求めます。
- --aws-session-token – AWS STS を使用して生成された一時認証情報を使用する際に、セッショントークンが生成されます。一時認証情報を使用する場合、このパラメータを指定しないと、インストーラによって入力を求められます。
4. すると、MGNのコンソールのソースサーバに追加されていることがわかります。すでに初期同期が自動的に開始されスナップショットの作成中であることも確認できます。
5. EC2 > インスタンスを確認するとAWS Application Migration Service Replication Serverという名前のインスタンスが実行されていることがわかります。
これは、MGNが自動的に立ち上げたインスタンスでソースサーバーにインストールしたReplication AgentがこのReplication Serverに対してデータを継続的に送信TCP1500番を使用して送信しています。アーキテクチャ図の以下箇所に当たります。
6. しばらくすると以下の通り「テストの準備完了」という状態になります。この状態は、ソースサーバにレプリケーションエージェントがインストールされ、ステージングエリア（レプリケーションサーバ）に最新のデータが反映されている状態です。
サーバー情報のタブを見てみると、ソースサーバの情報が色々と表示されています。推奨のインスタンスタイプも表示してくれていて、c5.largeとなっています。（移行元は、t3.micro）
c5.largeとt3.microを比べてみましたが、ちょっとオーバースペックかな・・？
| インスタンス名 | オンデマンドの時間単価 | vCPU | メモリ | ストレージ | ネットワークパフォーマンス |
|---|---|---|---|---|---|
| t3.micro | USD 0.0104 | 2 | 1 GiB | EBS のみ | 最大 5 ギガビット |
| c5.large | USD 0.085 | 2 | 4 GiB | EBS のみ | 最大 10 ギガビット |
ステップ5 起動テンプレートの編集
テストインスタンス/カットオーバーインスタンスの起動時には、起動テンプレートが使用されます。その起動設定を行っていきます。
1. MGNのコンソールからソースサーバーを選択して「起動設定」のタブを開きます。
2. 一般的な起動設定の編集ボタンを押下します。
3. デフォルトだとインスタンスタイプの適切なサイズ設定の部分がオンになっているので、オフに変更して「設定を保存」します。（ここがオンの状態だと推奨されたインスタンスタイプがMGNによって勝手に選択されてしまいます。）
4. 続いて、EC2 起動テンプレートを編集を押下します。そうするとEC2 > 起動テンプレート > テンプレートを変更 (新しいバージョンを作成)に遷移します。
5. インスタンスタイプをt3.microに設定します。
6. ネットワーク設定 > 高度なネットワーク設定のパブリック IP の自動割り当てを有効化に修正し「テンプレートバージョンを作成」を押下し起動テンプレートを作成します。
7. 先ほど作成した「起動テンプレート」を選択して、「アクション」を押下します。デフォルトバージョンを設定を選択し、「テンプレートのバージョン」を3に設定します。
8. 最後にMGNコンソールに戻りインスタンスタイプがt3.microになっていて、テンプレートIDも先ほど作成したものになっているかを確認します。
ステップ6 テストインスタンスの起動
続いて、テストインスタンスを起動します。移行ダッシュボードのライフサイクルが「テストの準備完了」という状態になっていればテストインスタンスを起動することができます。
1. テストおよびカットオーバー > テストインスタンスを起動を押下
2. 以下の通り「ジョブの詳細を表示」という部分を押下すると進行中のジョブログが確認できます。また、ソースサーバのダッシュボードに戻ると、移行ライフサイクルが「テスト進行中」となっているかと思います。
3. テストインスタンスを起動を実行すると「AWS Application Migration Service Conversion Server」という名称のインスタンスがMGNによって起動されます。これは、EBSスナップショットをもとに、ターゲットサーバがAWS上で動作するように変換を行うサーバです。
4. 移行ダッシュボードに移動して、起動を確認できたら「EC2コンソールで表示」を押下して、テストインスタンスのパブリックIPを確認します。
5. 今回は、http://52.205.213.240 にアクセスして問題なくwordpressの画面が表示されたらテストOKとします。
6. テストが完了したらテストおよびカットオーバー > 「カットオーバーの準備完了」としてマークを押下してテストを完了させます。
7. 移行ライフサイクルが「カットオーバーの準備完了」となっていることを確認します。
ステップ7 カットオーバーインスタンスの起動
ようやく、カットオーバーインスタンスの起動準備が整いました。それでは、やっていきましょう
1. テストおよびカットオーバー > カットオーバーインスタンスを起動を押下し、カットオーバーインスタンスを起動します。
2. 移行ダッシュボードに移動して、起動を確認できたら「EC2コンソールで表示」を押下して、テストインスタンスのパブリックIPを確認します。
3. http://54.158.63.225 にアクセスして問題なくwordpressの画面が表示されたらOKです。これで、カットオーバーを完了し移行を完了させることができます。
4. テスト > カットオーバー > カットオーバーを最終処理を押下し移行プロセスを完了します。
5. カットオーバーの最終処理を完了すると、データレプリケーションのステータスが「切断済み」となっていることがわかります。
6. 続いて、アクション > アーカイブ済みとしてマークを押下してソースサーバをアーカイブします。これで一連の移行作業は完了となります。
まとめ
今回は、様々なインフラ基盤で動いているアプリケーションをAWSにリフトアンドシフトでの移行をサポートしているサービスのMGNを試してみました。実際に手を動かして移行を実践してみると、かなり理解が深まるかと思います。各種リソースを立てるので多少お金はかかってしまいますが、面白いので是非試してみてください。