こんばんは、小寺です。
今日はAWSへ移行する際によく使われるAWS Application Migration Service(AWS MGN)について解説します。

移行方式って何使う？

7Rって聞いたことがありますか。AWS移行するときの方式についての考え方です。
7つあるので、7Rと呼ばれていて工数がかかるものから順番にあげてみました。

1) リファクタリング

クラウドネイティブ機能を最大限に活用してアプリケーションを移行し、アーキテクチャを変更します。俊敏性、パフォーマンス、およびスケーラビリティを向上させます。 通常、オペレーティング システムとデータベースの移行が含まれます。
例としては、オンプレミスの Oracle データベースを Amazon Aurora PostgreSQL 互換エディションに移行します。

2) リプラットフォーム

アプリケーションをクラウドに移行し、クラウドの機能を活用するためにある程度の最適化を導入します。
例としては、オンプレミスの Oracle データベースを AWS クラウドの Amazon Relational Database Service (Amazon RDS) for Oracle に移行します。

3) リパーチェス

アプリケーションの買い替えるイメージです。通常はライセンスからSaaSモデルに移行します。
例: 顧客関係管理 (CRM) システムを Salesforce等のサードパーティー製品に切り替えます。

4) リホスト（リフト アンド シフト）

変更を加えずにアプリケーションをクラウドに移行し、クラウドの機能を活用します。 素早く、低コスト・低工数で、最小限の変更で移行する移行戦略です。
また移行パターンの中で一番多く用いられるようです。
例: オンプレミスの Oracle データベースを AWS クラウドの EC2 インスタンス上の Oracle に移行します。

5) リロケート

新しいハードウェアを購入したり、アプリケーションを書き換えたり、既存の運用を変更したりすることなく、インフラストラクチャをクラウドに移行します。
移行シナリオは VMware Cloud on AWS に固有であり、オンプレミス環境と AWS 間の仮想マシン (VM) の互換性とワークロードの移植性をサポートします。

6) リテイン

アプリケーションを元の環境のまま運用します。やらないことを決める＝移行しないことを決めるといったイメージが近いかもしれないですね。
大規模なリファクタリングが必要でその作業を後回しにしたいアプリケーションや、移行するビジネス上の正当な理由がないことが多いです。

7) リタイア

移行元環境で不要になったアプリケーションを廃止または削除します。

ここまでが移行方式について、紹介しました！後半ではアプリケーションサーバを例に移行方法を具体的に検討してみたいと思います。

アプリケーションサーバの移行を考える

オンプレミスからシステム構成を大きく変更せずにリホスト (リフト＆シフト) する場合 を想定します。よくお客様からご相談いただくのは、ハードウェアの保守切れやOS やミドルウェアのEOLにより、新規にパッケージ等含めてアップデートされたいケースです。 こんな時は、手動での移行を想定し、AWS上に新規にEC2を起動して、アプリケーションをデプロイした後に動作検証を行うパターンを想定します。

OSやミドルウェアを最新化せずに、今のバージョンで移行を行いたい要望があれば、自動的に移行する方法を検討することになり、 AWS Application Migration Service(AWS MGN) の利用を想定します。

MGNの特徴

AWSへのリホストに特化したサーバー移⾏サービスです。
継続的なレプリケーションによりダウンタイムを最小化することができます。

・Agent版とAgentless版の2つを提供しています
・様々な移行元OSをサポート
・Windows Server 2003/2008/2012/2016/2019/2022
・indows 10
・entOS、RHEL、Oracle Linux、SUSE、Ubuntu、Debian
・1台につき、90日間無料で利用ができる。つまり移行には3カ月の猶予つき。
・30⽇以降はサーバーごとに$0.042/時間 が発生
MGNの利用料は上記の通りですが、AWSの利用として他に起動したサービスは公式のPricingページと同様の料金が発生します。

Agent版は物理マシンでも仮想マシンでも両方利用することができます。 Agentless版は、 エージェントをインストールできない仮想環境に対応 しています。VMware vCenterにAWS MGN vCenter Clientをインストールし、スナップショット単位の継続差分レプリケーションを行うことができます。

また、 MGNで移行先サーバーを構築するのは本番移行のカットオーバーだけでなく「テストモード」があります。 これは動作としてBluePrintどおりに移行先のEC2が起動できるかを確認するもので、ほぼカットオーバーと同じと思ってよいでしょう。MGNを利用する場合、このテストモードを利用して動作確認を行う位置づけとなります。

ここまで、MGNの特徴について解説しました。 古いOSであったとしても、新しく運用やサポートを引き継いだ立場の方からすると、「現行の環境をそのままAWS上に再現」できることが重要になってきますよね。「詳細が把握できないサーバーに関しても、そのまま移行してAWS上で稼働できる」という点では非常に魅力的だと思います。

またOSをそのまま使い続けたいと思う方はやはり少ないかと思います。もうすぐリタイア予定のシステムである等、期間限定であればAWSでMGNで移行後にOSやミドルウェアをアップデートしないという選択も取れますよね。ハードウェアやデータセンターのレンタル期限などで、とりあえず移行するという場合にもMGNが用いられるケースが多いです。

他サービスと比較したときには？

AWSが提供するサーバーイメージ移行サービス(ツール)としては、VMImport や Server Migration Service がありますが、MGNの方が大規模かつ手軽に移行ができます。 オンプレからのサーバ移行にはServer Migration Service（SMS）がよく使われていましたが、2022年3月31日にサービスが廃止されています。

アプリケーションサーバ移行後にやっておきたい

アプリケーションサーバのリホストを想定してMGNについてご説明しました。もちろんサーバのイメージそのまま移行するのですが、オンプレミスからクラウドに移行時にやっておきたい！一度MGNで移行した後は、カットオーバー後と同様の環境で、 移行後のシステムのパフォーマンスをテストして、応答時間や処理スピードをチェックしましょう。

AWS　MGNまとめ

サーバー移⾏を簡素化、迅速化、自動化してくれるサービスです。
・Agent版は物理環境、仮想環境のどちらにも対応
・Agentlessは仮想環境からの移⾏に対応
・API操作による⼤規模移⾏も可能
・継続的なレプリケーションによりダウンタイムの最⼩化
・1台につき90 ⽇間無料で利⽤可能です