顧客フロントSEのIT勉強ブログ

2022 Japan AWS Top Engineer / 2022-23 Japan AWS Certifications Engineer。AWS認定12冠、情報処理試験全冠。顧客フロントSEがなるべく手を動かしながらIT技術を学んでいくブログです。

トップ > AWS勉強-ハンズオン > AWS Application Migration Service（MGN）ハンズオンを試してみた

AWS Application Migration Service（MGN）ハンズオンを試してみた

AWS勉強-ハンズオン AWS勉強

f:id:se_o_chan:20220130002825p:plain

オンプレからのサーバ移行サービス「Application Migration Service（MGN）」ハンズオンを試します。

サーバ移行ではこのサービスを使うようAWS自身も推奨しているにもかかわらず、2021年5月にGAしたばかりということもあり、情報が多くないのが現状です。

このハンズオンを通じて基本的な使い方や設定内容の理解を深めていきます。

AWS Application Migration Service（MGN）とは

AWS Application Migration Serviceとは、オンプレで運用しているシステムをアーキテクチャに変更を加えることなくAWSへ移行できるサービスです。

略称はAMSになりそうなものですが、既にAWS Managed Serviceがその略称を使っているため、こちらは「MGN」と略されます。

これまでオンプレからのサーバ移行にはServer Migration Service（SMS）がよく使われていましたが、2022年3月31日にサービス廃止することが確定し、2022年1月からは新たな移行ジョブをSMSで作れなくなっています。

その後継サービスに当たるのが、このMGNです。

MGNワークショップの構成

MGNハンズオンは下記で提供されています。

ありがたいことに日本語で提供されていますが、普通に「MGN ハンズオン」などでググってもヒットしないので、URL自体を共有されてないとたどり着けないかもしれません。

本来はオンプレからAWSへのサーバ移行で使われるサービスですが、ハンズオンでは疑似的にオハイオリージョンからバージニア北部への移行を行います。

事前準備として移行元であるオハイオリージョンにWindows、Linuxサーバを構築し、その後MGNを使ってバージニア北部リージョンに両サーバを移行していきます。

f:id:se_o_chan:20220126220036p:plain

（出典）MGNハンズオン

ステップ１．MGNのセットアップ

MGNの初期設定

移行先のバージニア北部リージョンでMGNコンソールを開き、MGNセットアップを行います。ハンズオンでは全てデフォルトで「Create template」ボタンをクリックし終了しちゃいますが、各値が何を選択しているのか理解しておきます。

f:id:se_o_chan:20220126221713p:plain

Staging area subnet

レプリケーションサーバを構築するサブネットを選択します。

Replication Server Instance type

レプリケーションサーバのインスタンスタイプを選択します。

EBS volume type

レプリケーションサーバのEBSタイプを選択します。

EBS encryption

EBSを暗号化する暗号化キーを選択します。
Customを選ぶとCMK（カスタマーマネージドキー）を選択できます。

Security Group

Always use Application Migration
Service securty group

Staging area subnetに事前用意されたセキュリティグループを利用するか選択します。
原則これはONにするのが推奨です。

Additional security groups

個別に追加セキュリティグループを設定したければ選択します。

Data routing and throttling

Use private IP for data replication
(VPN, Direct Connect, VPC peering)

Direct Connect やVPC経由でレプリケーションを行う場合はチェックを入れます。

Throttle network bandwidth
(per server - in Mbps)

移行サーバ毎のレプリケーションに使用するネットワーク帯域幅を制御します。

IAMユーザーの作成/アクセスキーの発行

MGN Agentが利用するアクセスキーを発行します。

アクセスキーを発行するIAMユーザに「AWSApplicationMigrationAgentPolicy」のアタッチが必要です。

f:id:se_o_chan:20220126224559p:plain

ステップ２．オハイオ環境(移行元)の構築

CloudFormationでVPC, EC2を作成

オハイオリージョンでCloudFormationを開き、こちらのテンプレートからVPC、EC2を作成します。

ただし私がハンズオンを実施した2022年1月26日時点で、テンプレートで指定しているWindows ServerのAMI（ami-086850e3dda52e84a）が存在しなくなっていたので、良きAMIに変更してください。
私はami-0f540030bb04d884aを利用することにしました。

f:id:se_o_chan:20220126231118p:plain

スタックのステータスが「CREATE_COMPLETE」になった後に、EC2コンソールに移動してみるとEC2インスタンスが2台作成されていることが確認できます。

f:id:se_o_chan:20220126232116p:plain

移行元サーバーの構築（Linux）

SSMセッションマネージャーからLinuxサーバーに接続し、MGN Agentをインストールします。
<ACCESS_KEY_ID>と<SECRET_ACCESS_KEY>は予めIAMから発行したアクセスキーとシークレートアクセスキーのペアです。

sudo 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
sudo python3 aws-replication-installer-init.py --region us-east-1 --aws-access-key-id <ACCESS_KEY_ID> --aws-secret-access-key <SECRET_ACCESS_KEY> --no-prompt

f:id:se_o_chan:20220126233329p:plain

Webサーバーを想定してLinuxサーバー上にNginxを起動しておきます。

sudo amazon-linux-extras install nginx1 -y
sudo systemctl start nginx
sudo chkconfig nginx on

移行元サーバーの構築（Windows）

同じくSSMセッションマネージャーからWindowsサーバーに接続します（Windowsサーバー上のPowerShellコンソールが開きます）。

Cドライブ直下にtmpフォルダを作成し、そのフォルダ上でコマンドプロントから下記コマンドでMGN Agentをインストールします。

curl -O https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe
AwsReplicationWindowsInstaller.exe --region us-east-1 --aws-access-key-id <ACCESS_KEY_ID> --aws-secret-access-key <SECRET_ACCESS_KEY> --no-prompt

f:id:se_o_chan:20220126233922p:plain

Webサーバーを想定してPowerShellからWindowsサーバー上にIISを起動しておきます。

Install-WindowsFeature Web-Server

ステップ３．バージニア北部環境(移行先)の設定

レプリケーションの動作確認

MGN Agentは指定したIAMユーザとリージョンから通信先のMGNレプリケーションサーバを特定し、インストールと同時にレプリケーション（TCP1500）通信を開始します。

なので既にバージニア北部のMGNコンソールを開くとオハイオのサーバー2台がソースサーバーとして表示されているはずです。

f:id:se_o_chan:20220126234454p:plain

バージニア北部のEC2コンソールを見ると、レプリケーションサーバも自動起動されていますね。

f:id:se_o_chan:20220129221522p:plain

移行先サーバーの設定

ソースサーバからLinuxサーバー（ip-10-1-10-xxx.us-east-2.compute.Internal）を選択し、起動設定を編集します。
ここではInstance type right sizingを[None]に変更しておきます。

f:id:se_o_chan:20220126234852p:plain

Instance type right sizing テスト or カットオーバーインスタンスとして起動するインスタンスタイプを選択します。
BasicだとMGNが自動でインスタンスタイプを選択します。
Nonedだと手動設定したEC2起動テンプレートに従います。
Start instance upon launch テスト or カットオーバーインスタンスを起動時に自動的に開始するか、
停止状態で起動するかを選択します。
Copy private IP ソースサーバーのIPアドレスと同じIPをコピーするか選択します。
Transfer server tags ソースサーバーのサーバータグを転送するか選択します。
Operating system licensing サーバOSのライセンスをBYOLで持ち込むか選択します。

EC2起動テンプレートを変更します。
ここではテンプレートバージョンの説明を[mgn]、インスタンスタイプを[t2.medium]、ストレージのボリュームタイプを[汎用SSD(GP3)]、ネットワークインターフェースのパブリックIPの自動割当を[有効化]に変更しておきます。

f:id:se_o_chan:20220127001001p:plain

項目数が多いので主要な設定値のみ取り上げておきます。

インスタンスタイプ テスト or カットオーバーインスタンスのインスタンスタイプを選択します。
Instance type right sizingがBasicだとここで手動指定しても無視してMGNが自動選択します。
サブネット テスト or カットオーバーインスタンスを起動するサブネットを指定します。
ストレージ テスト or カットオーバーインスタンスにアタッチする
EBSボリュームのストレージタイプを選択します。

起動テンプレートの変更を保存すると新しいバージョンのテンプレートが作成されます。
デフォルトバージョンに指定されているテンプレートが採用されるため、アクションから「デフォルトバージョンを設定」を選び、最新バージョン（下記だと3）をデフォルトバージョンとして設定します。

f:id:se_o_chan:20220127002000p:plain

これで起動テンプレートの設定は完了ですが、Windowsサーバのほうも同様に自動作成された内容から更新しておいてください。

ステップ４．テストサーバーの起動

テストサーバーの起動

MGNコンソールからLinuxサーバのホスト名をクリックし、レプリケーションが完了している（Replication progressがInitial replication finishedになっている）ことを確認します。

f:id:se_o_chan:20220129224253p:plain

画面右上の「Test and cutover」からLaunch test instancesを選択しテストサーバを起動します。前ステップでEC2起動テンプレートと、レプリケーションサーバが作成したEBSスナップショットからEC2インスタンスを起動してくれます。

MGNでLaunch statusがLaunchedになったら起動完了です。大体5～10分くらいかかりました。

この時、バージニア北部のEC2インスタンスを見てみるとコンバージョンサーバが起動されていました。このサーバがEBSスナップショットからAMIを作ってくれているんですね。AMI作成が終わると自動で停止します。

f:id:se_o_chan:20220129225118p:plain

テストサーバーの確認

動作確認として、nginxでWEBサーバが起動しているかを見てみたいのですが、起動テンプレートでEC2インスタンスにアタッチしたセキュリティグループで、InboundのHTTP通信が空いていないので開けておきます。

その上で、テストサーバのパブリックIPに対してHTTPアクセスしてみると無事nginxの初期画面が表示されました。

f:id:se_o_chan:20220129225542p:plain

一旦ここでは移行前の動作検証完了ということで、MGNコンソールでMark as “Ready for cutover” を選択します。これでテストサーバが一旦削除されます。

ここでは割愛しますが、同様にWindowsサーバでもテストサーバの起動・動作検証を行います。

ステップ５．本番移行

本番サーバーの起動

MGNコンソールでNext actionsが「Launch cutover instance」で、Data replication statusが「Healthy」になっていれば本番サーバー起動の準備が整っています。

Launch cutover intancesを選択し本番サーバを起動します。

Launch statusがLaunchedになったら起動完了です。この時も裏ではコンバージョンサーバが起動され、その時の最新EBSスナップショットからAMI作成してくれています。

f:id:se_o_chan:20220129231314p:plain

本番サーバーの確認

テストサーバーの時と同様、本番サーバーのパブリックIPに対してHTTP接続してみるとnginx画面を表示できました。

f:id:se_o_chan:20220129231423p:plain

割愛しますが、Windowsサーバーも同様に本番サーバーを起動し、IISのWebサーバにHTTPアクセスできることを確認します。

レプリケーションの停止

これでサーバーはAWSに移行できたわけですが、まだオハイオの移行元サーバからMGNへのレプリケーションは続いています。

そこでMGNコンソールからFinalize cutoverを選択しレプリケーションを終わらせます。

f:id:se_o_chan:20220129231747p:plain

最後にMark as archivedを選択し、明示的に移行完了したことを指定します。これでMGNのサーバ移行は終了です。

f:id:se_o_chan:20220129231944p:plain

まとめ

ハンズオンを実施してみることで、MGNのイメージをつかむことができました。
ただイメージがつかめたことで次のような疑問も湧いてきました。

  • エージェントインストールと同時にレプリケーション開始させない方法は？
  • 移行元からMGNやレプリケーションサーバへの通信を閉域網（Direct Connect、Site-to-Site VPN）経由にするには？
  • MGNやレプリケーションサーバを起動するVPCと、移行先VPCでAWSアカウントを分けたい場合は？
  • レプリケーション中はMGNによるEBSスナップショットはどう差分反映している？（数分おきにスナップショット削除・作成を繰り返し？）
  • AWS環境で新たに導入したいミドルウェア（統合CloudWatchエージェントなど）はどのタイミングでインストールすべき？
  • 移行完了後にEBSスナップショットやEBSボリュームは手動削除が必要？（ハンズオン後EBSコンソール見ると多数のボリューム/スナップショットが残存・・）

この辺は引き続き調査が必要かなと思いましたが、今後オンプレからAWSへの移行時には避けて通れないMGNを、今後は嫌悪感無く扱うことができそうです。

 

｛2022年3月27日　更新）

実際に運用中のシステムに対してMGNを使ってみて分かった、上記含むいくつかの疑問への回答を記事にまとめました！こちらもご参照ください。

frontse.hatenablog.jp

PVアクセスランキング にほんブログ村ブログランキング・にほんブログ村へにほんブログ村

#AWS #MGN #ハンズオン

se_o_chan 読者になる

広告を非表示にする
読者になる
コメントを書く