（出典）AWS Application Migration Service
今年1月末にMGNハンズオンを試しましたが、それから数サーバで実際に使ってみました。それを通じて判明したことをQ&A形式で記します。
実際の構成でMGNを使うとぶつかる疑問に踏み込んでいると思うので、同じ疑問を持つ方の参考になれば嬉しいです。
- AWS Application Migration Service（MGN）とは
- MGNハンズオン
- Ｑ１．閉域網を使って通信させることはできる？
- Ｑ２．MGNと実運用する環境を別のAWSアカウントにすることはできる？
- Ｑ３．MGNの流量制限って厳密に効くの？
- Ｑ４．MGNのデータ転送量・転送時間はどのくらい？
- Ｑ５．MGNエージェントインストールと同時にレプリケーションを開始させない方法は？
- Ｑ６．移行後サーバにはいつ統合CloudWatchエージェント等をインストールすべき？
- まとめ
AWS Application Migration Service（MGN）とは
MGNはオンプレで運用しているシステムをアーキテクチャを変更することなくAWSへ移行できるサービスです。
これまでサーバ移行ではServer Migration Service（SMS）が良く使われていましたが、残念ながらSMSは2022年3月31日にサービス廃止されます。MGNはその後継サービスです。
MGNハンズオン
MGNハンズオンはこちらからアクセスできます。
ハンズオンの内容を記事にしてみているので「MGNってなんだ？」という方はまずこちらを参照してみてください。
その時にいくつか疑問も湧いてきて上の記事の末尾にも記しているのですが、それにも答えていきたいなと思います。
Ｑ１．閉域網を使って通信させることはできる？
移行元サーバにインストールするMGNエージェントは、デフォルトだとインターネット公開されたMGNエンドポイントに対して通信します。
ですが、社内のセキュリティ要件などで「閉域網で通信させたい」ということがあり得ます。
次のステップを踏むことで全通信を閉域網経由にすることができます（Direct ConnectまたはSite-to-Site VPNが敷設済である前提）。
- MGN、EC2、S3エンドポイントを作成する
- 移行元サーバとレプリケーションサーバからエンドポイントへ443番通信可能にする
- 移行元サーバからレプリケーションサーバへ1500番通信可能にする
- オプション指定してMGNエージェントをインストールする
まずレプリケーションサーバを立てるステージングVPCにMGN、EC2、S3エンドポイントを作成します。オンプレ環境からアクセスするため、S3エンドポイントはInterface型で構築するようにしてください。
次に移行元サーバとレプリケーションサーバからこれらのエンドポイントに443番で通信できるようにします。具体的には「移行元のWindows FW/iptables」「エンドポイントのセキュリティグループ」「レプリケーションサーバのセキュリティグループ」に設定が必要なはずです。
私はエンドポイントのセキュリティグループに、レプリケーションサーバからのInbound通信を許可していなかったため、
Failed to authenticate with service
のエラーが発生し、何度やってもレプリケーションサーバの起動に失敗しました。
あわせて移行元サーバからレプリケーションサーバへの1500番通信も開けておきます。
最後にMGNエージェントをインストールする際にMGNエンドポイントとS3エンドポイントのDNSをオプション指定します。具体的には次のようなインストールコマンドになります（Windows Serverの例）。
awsReplicationWindowsInstaller.exe --region ap-northeast-1 --aws-access-key-id <ACCESS_KEY_ID> --aws-secret-access-key <SECRET_ACCESS_KEY> --s3-endpoint vpce-1234567890abcdefgh-1234abcd.s3.ap-northeast-1.vpce.amazonaws.com --endpoint vpce-1234567890abcdefgh-1234abcd.mgn.ap-northeast-1.vpce.amazonaws.com
これで閉域網を通じたサーバ移行が可能になります！
Ｑ２．MGNと実運用する環境を別のAWSアカウントにすることはできる？
マルチAWSアカウントで運用している場合、移行するサーバが複数のAWSアカウントにまたがることがあるかと思います。
その際、個々のAWSアカウントにMGNのステージングVPCを用意するのは面倒なので、MGN用にAWSアカウントを1つ用意し、クロスアカウントでテスト/カットオーバサーバを起動したくなります。
つまりこういう構成です。
残念ながら2022年3月現在、MGNにこれを実現する機能はありません。
従って、これを実現するには次のステップを踏む必要があります。
- カットオーバサーバをMGN用アカウント上のVPCに起動する
- カットオーバサーバからAMIを作成する
- AMIをクロスアカウントで共有する
- システム用アカウントでAMIからサーバを復元する
ここで１点、注意事項があります。
MGNから作成されたカットオーバサーバにアタッチされているEBSは、デフォルトのKMSキー（aws/ebs）で暗号化されており、そこから作ったAMIも同じくデフォルトKMSキーで暗号化された状態です。
デフォルトKMSキー（＝AWS Managed CMK）はクロスアカウントで共有できないため、AMIを共有しようとするとエラーになります。
そこでカットオーバサーバから作成したAMIを一度コピーして、別のキー（＝Customer Managed CMK）で暗号化しなおします。
さらにAMIを共有したいAWSアカウントに、そのキーの使用権限を付与することでAMIが共有できるようになります。
現状、この構成を作り上げるのはやや面倒なので今後のMGNアップデートに期待ですね！
Ｑ３．MGNの流量制限って厳密に効くの？
MGNには移行元サーバからの同期通信に対して、流量制限を効かせることができます。
これはSMSには無かった機能で、既にDirect Connectを通じた本番通信と並行してサーバ移行する際に「MGNがネットワーク帯域を使いすぎて本番運用に障害が出た」ということを避けることができます。
具体的にはMGN > Settingsの下記赤枠部分の設定ですね。
では、この流量制限はどのくらい厳密に適用されるのでしょう？
私が実際に試した際の結果を共有します。
他の通信がほぼ無い状態でMGNでデータ通信させたときのDirect Connectのスループットのグラフです。MGNのネットワーク帯域は「25Mbps」で制限しています。
ほぼ25Mbpsで頭打っているのが分かりますが、同期始めだけ例外的に制限値の2倍近くまでスパイクしてしまっています。
この結果からMGNのネットワーク帯域制限は許容ギリギリの値にするのではなく「許容値の半分くらいの値で制限する」or 「同期を開始するタイミングを調整する」のいずれかが必要だと思います。
Ｑ４．MGNのデータ転送量・転送時間はどのくらい？
MGNは移行元サーバのストレージをビットマップで読取り、転送するそうです。
そのため、ストレージで使用しているデータ量ではなく、ストレージそのもの割り当て容量分が転送されることになります。
先ほどのＱ３でDirect Connectのグラフを出しましたが、あの時は計90GBのストレージを持つサーバを移行しました。
90GBを25Mbpsで移送すれば、計算上は8時間ほどかかるはずなのですが、実際は2時間10分で同期が終わりました。どうやら4分の1ほどにデータ圧縮がかかった状態で転送していると思われます。
これで転送量（＝ストレージの4分の1くらい）とMGNのネットワーク帯域制限値から、どのくらいの時間で転送が完了するかはおおよそ予想がつけられそうですね。
※今後も数サーバをMGNで移行していく予定なので、「4分の1」という値の正当性は確認したいと思います。
Ｑ５．MGNエージェントインストールと同時にレプリケーションを開始させない方法は？
残念ながらありません。
どうしてもレプリケーション通信させたくないなら、移行元サーバのWindows FWまたはiptablesで1500番のOutboundを止めるか、レプリケーションサーバのセキュリティグループで1500番のInboundを止めるか、になります。
ですが、MGNで同期が動いている間、移行元サーバへの負荷はかなり軽微です。2vCPUでCPU使用率が10%増するくらいで、MEMはほぼ使わないです。
従って、あえてレプリケーションを止めたい、というユースケースが無いのではないかと思います。
Ｑ６．移行後サーバにはいつ統合CloudWatchエージェント等をインストールすべき？
AWSにサーバ移行するのであれば、統合CloudWatchエージェントやSSMエージェントをインストールしたくなりますよね。
MGNではテストサーバ、カットオーバサーバを何度も起動することができますが、その度に最新のEBSボリュームからEC2インスタンスが生成されます。
従ってテストサーバで各種エージェントをインストールしても、カットオーバサーバを起動するとエージェントはインストールされていない状態に戻ってしまいます。
なので、「finalize cutover」をして運用するサーバを確定させた後（Ｑ２のようにクロスアカウントにするならシステムアカウント側でAMIからサーバを復元した後）に各種エージェントをインストールするのが良いです。
まとめ
MGNハンズオンで基本的な使い方は分かったけど、いざ実環境でサーバ移行しようとしたときに疑問に思うであろう箇所について取り上げてみました。
MGNは準リアルタイムにデータ同期し続けてくれますが、実際に運用を切り替える際にはシステム停止時間はある程度必要です。特に今回取り上げたクロスアカウント構成や各種エージェントインストール等を含むと、AWS環境に運用を切り替えるまでの時間は数時間オーダーでかかるはずです。
なので実証実験（PoC）や移行テストを行うことになると思いますが、その前に今回挙げたような事項は目途を付けたうえで実施していただければ、より効率的に移行作業を進められるのではないかと思います。
にほんブログ村