AWS Application Migration Servic(MGN　※旧CloudEndure Migration）とは

"AWS Application Migration Service（※CloudEndure Migration）" はAWSが提供するサービスで、いわゆる「イメージ転送」にて移行ができるものです。元々は有償サービスで、AWSを始めとした各種クラウドへの移行が行えるサービスでしたが、AWSが買収したことにより無償提供されAWSへの移行専用サービスとなりました。

AWSが提供するサーバーイメージ移行サービス(ツール)としては、VMImport や Server Migration Service がありますが、前述のサービスより手軽で幅広いシーンに対応できることから非常に使い勝手がよく、個人的には第一選択とすべきと考えています。

サービス名	特徴	データ同期
VMImport	VMwareからエクスポートしたサーバイメージをインポートしEC2に変換	無し
Server Migration Service	仮想化基盤（VMware、Hyper-V）からサーバイメージを抽出しEC2に変換	無し
AWS Application Migration Service	移行元サーバに導入したエージェントを介してディスクイメージを転送しEC2に変換	有り

特徴

制約

対応OSに縛りがある
https://docs.cloudendure.com/Content/Getting_Started_with_CloudEndure/Supported_Operating_Systems/Supported_Operating_Systems.htm
移行対象サーバー全てにエージェント導入が必要
制御系とデータ転送の2つの通信経路がある
前者の制御系はクラウド上にあるCloudEndureのサービス本体と通信する必要があり、インターネット通信が必須となる。
　- データ転送はインターネットと閉域網の双方が利用できる。閉域網の場合はDirectConnectやVPN接続を事前に張っておく必要がある。
- 無償利用できるがライセンス期間は90日である。

動作順序

Application Migration Serviceは移行元サーバー導入したエージェントを介してディスクイメージを転送する
データ転送制御のためクラウド上のMGNサービスと通信を行う
データ転送を開始するとディスクイメージを受け取るレプリケーションサーバーが立ち上がり、移行元サーバーと同数のEBSが作成されデータ転送される。
この際、移行元サーバーとレプリケーションサーバー間は継続的なデータ同期が行われている点に着目。
移行先サーバーの設定は BluePrint と呼ばれるパラメータにてインスタンスタイプや所属サブネットやセキュリティグループ等を指定して行う。
移行先環境にサーバーを立ち上げる(=カットオーバーという)際はBluePrintを元にAMIが作成されEC2が立ち上がる
レプリケーションサーバにアタッチされ転送されたディスクイメージはスナップショットが取られ、それを元に移行先サーバーに新たなEBSとしてアタッチされる

カットオーバーで同期は失われる

レプリケーションサーバーは移行元サーバーのディスクイメージを継続的に受け止め同期が行われるが、移行先サーバーのディスクはカットオーバーした時点のスナップショットを元に構築される点です。

つまり、カットオーバーした段階で移行元サーバーと移行先サーバーのデータの乖離が始まると言うことになります。

テストモードとカットオーバー

Appilication Migration Serviceで移行先サーバーを構築するのはカットオーバーだけでなく「テストモード」というものがあります。これは動作としてBluePrintどおりに移行先のEC2が立ち上がるかどうかを確認するもので、ほぼカットオーバーと同じです。Application Migration Service の設計思想としてはこのテストモードを利用して動作確認を行う位置づけとなります。

このテストモードで十分な動作確認が取れたのであれば本番用のカットオーバーとなりますが注意すべき点があります。テストモードで立ち上げたサーバーは削除されるという点です。

せっかく設定変更やチューニングを施しても、カットオーバーでレプリケーションサーバー上にある同期されたディスク情報で新たにサーバーが立ってしまうため、これらの作業は「無かったこと」となります。

手順を明確にし設定変更をスクリプト化する等の準備を行い、カットオーバーがスピーディに行われるよう準備する必要があります。

移行元環境への考慮

データ転送は複数サーバーを同時に実行することが可能です。これは非常に有用な機能なのですが、移行元環境に過度の負荷をかける可能性があり、計画を建てる上で重要なファクターとなります。

データ転送初期はディスク全体をスキャンするためCPU負荷が高くなる可能性があります。特にシングルコアのサーバーの場合はサービス影響が大きく出る可能性があります。
複数サーバーを一括で同期をとった際に移行元環境のネットワーク出口のトラフィック逼迫し既存サービスに影響が出る可能性があります。この場合は転送時間帯や帯域制御を考慮する必要があります。

移行計画の考慮事項

計画時に考慮に含める必要があるのは以下

移行期間

ライセンスの期間は90日ですがアカウントは再発行は可能なためそれほどシビアではありません。とはいえデータ転送の期間を考慮したライセンス取得を行う必要があります。

またデータ転送の時間や移行後の動作確認等も必要となるため十分な期間の考慮が必要となります。

通信経路

MGNはエージェントがインターネット通信が必要となるため、移行元サーバーの配置によっては通信経路の穴開けが必要となります。既存環境の変更が必要な場合、様々な調整や費用が発生するケースも考えられますので、十分な考慮をしておく必要があります。

データ転送経路についても考慮が必要です。インターネット経由でのデータ転送でも十分なケースもありますが、データ転送期間をなるべく短くしたいのであれば高品質な専用線が必要となってきます。この場合はデータ量(全サーバーのディスク容量の和)と回線品質を考慮し、専用線が必要かどうかを判断する必要があります。

また、インターネット経由でのデータ転送の場合、既存サービスの通信を圧迫しないかの考慮も必要となってきますので、併せて確認をする必要があります。

システム切り替え

Application Migration Serviceはサーバー移行を行うサービスであり、エンドポイントを切り替えは別途考慮する必要があります。主にDNS切替えが主となる戦略となると思いますが、閉域網の場合はルーティング等も考慮する必要がでてきます。

移行先

Application Migration Service は移行元サーバーのイメージをそのまま転送するため、アプリケーション設定やOSユーザーもそのまま引き継がれます。

そのためネットワーク設定をそのまま引き継いだ場合、そのまま動作すると考えられます。逆にネットワーク設定を変更したのであれば、各サーバーのアプリケーション設定を見直す必要があります。サーバー転送後の作業として設定変更と動作確認が必要となってきますので注意が必要です。

なお、移行先環境(VPC,サブネット等)はカットオーバーに先立ち構築しておく必要がありますので、計画の際には考慮が必要です。

人手がかかる作業の考慮

移行先サーバーのパラメターは MGN コンソールの Blue Print にて入力を行います。これはコンソールのGUIでの実施であるため一括入力・一括確認ができません。対象のサーバー台数が数～十数台程度であれば「気合でなんとかなる」レベルですが、数十台以上のオーダーとなるとそうもいきません。幸いなことに Application Migration Service には複数ユーザーを登録することが可能ですので複数人で分担して並列作業が可能となります。

移行対象台数を考慮し人員と十分な工期の確保が必要です。

カットオーバー後作業の考慮

「テストモードとカットオーバー」の項で述べたように、カットオーバー後の作業はなるべく自動化を行う必要があります。テストモード時にしっかりと確認することが必要で、このフェーズに十分な工数を掛けておく必要があります。

テストモードは何度も実行することが可能ですので、事後作業のスクリプト化や省力化の確認を何度も行うことが出来るため、カットオーバーの前の最終確認はここで担保することとなります。

なおこの期間も移行元サーバーとレプリケーションサーバー間は継続的なディスク同期が行われています。ライセンス期間も気をつけて十分な工期をとるよう考慮する必要があります。

マネージドサービスの考慮

せっかくクラウドに移行するのでロードバランサーやデータベースをマネージドサービスに変更したいといった要望があるかもしれません。 Application Migration Serviceはサーバー移行のみ担当するため、マネージドサービスは別途構築が必要となります。

例えばロードバランサーだと、Application Loadbalancer の構築とサーバー証明書設置およびEC2へのアタッチ作業が必要となります。マネージドDBのRDSを採用した場合ですと、既存DBからのデータ移行も考慮が必要となります。

動作確認

動作確認はエンドポイント切替え前に実施するものとなるため、その方式や経路について十分な考慮が必要となります。

データ同期

AWS環境にサーバーを立ち上げるカットオーバー後には、設定内容変更や動作確認が必要になるケースが多々有りえます。「カットオーバーをすると移行元サーバーとデータの乖離が生じる」ため、その期間が長ければ何らかのデータ同期を考慮する必要があります。

データ同期については静止点が取れ十分なダウンタイムが取れるのであればあまり考慮は必要有りません。

一方で無停止やそれに準じる必要がある場合、既存サーバーとのデータ同期を考慮する必要があります。Application Migration Service 単体で解決出来ないので何らかの方策を考える必要があります。

逆に言えばデータ同期戦略がはっきりしていれば、システム切替えについて慌てる必要がなくなるとも言えます。

データ同期参考：

データベース　
データベースのレプリケーション機能を使用する
AWS Database Migration Serviceを使用する
https://aws.amazon.com/jp/dms/
ファイルシステム
AWS DataSync を使用する
https://aws.amazon.com/jp/datasync/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc
rsync等、サーバにデータレプリケーションの設定をする