MGN（AWS Application Migration Service）は、オンプレミス環境からAWSへの移行に利用できるツールとして定評があります。そこで、実際にどの程度使えるのかを検証するために試してみました。
今回は、さくらのクラウド上にあるサーバーをAWSへ移行するケースで検証を行いました。サポートされているOSの一覧は以下のリンクに記載されていますが、今回はその中に含まれていない Rocky Linux 9.6 を対象に試してみました。
サポートされているOS一覧（AWS公式ドキュメント）
https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html
なお、この記事は、普段からAWSの基本的なサービス（VPC、Subnet、EC2などのIaaS）を利用している方を対象としています。
移行概要
移行元、移行先
- 移行元：さくらクラウド
- rocky Linux 9.6, 2 CPUコア、4GB メモリー、300GB ストレージ
- 移行先：AWS東京リージョンのEC2（スペックは移行時に設定）
必要なもの
- AWS側：MGNサービスの権限を持っているIAMユーザー
- さくら側：サーバー管理者（サーバーに入ってrootあるいはsudoでAWS Agentを起動させます）
手順
-
AWS MGNサービスの初期設定
MGN自体の設定は数分で完了します。ただし、移行先となるEC2サーバーの環境（VPCやSubnetなど）を事前に準備しておく必要があります。テスト目的であれば、普段利用しているテスト環境を使っても問題ありません。 -
さくらクラウド側の準備
移行元のサーバーには、AWS MGNサービスのエージェントをインストールする必要があります。インストール自体は数分で完了しますが、サーバーの構築にはそれなりの時間がかかります。すでに運用中のサーバーがある場合は、それをそのまま利用するのが効率的です。 -
AWS MGNサービスを利用した移行
移行にかかる時間は、サーバーのディスク容量や、さくらクラウドとAWS間のネットワーク状況によって左右されます。この記事では画面キャプチャを多めに掲載していますが、実際の操作は非常にシンプルです。使ってみた印象としては、「簡単でわかりやすいツール」という評価です。
1.AWS MGN初期設定
まず最初に移行先のAWS側の設定が必要になってきます。
1.1 AWSにMGN権限持っているIAMユーザーを作成、権限設定、アクセスきーのダウンロード,
＊ 今回の記事ではここらへんの詳細は省略してます。必要に応じて調べながら設定してください
いくつかポイントを
- MGNサービスの権限は AWSApplicationMigrationAgentPolicy です。
- (今回は AdministratorAccess持ったユーザーでやってみました）
- アクセスきーの作成、いくつか選択肢があるのですが今回はCLI用ので作成しました。
1.2 移行先の環境設定（VPC, Subnet, セキュリティーグループなど）
＊ ここも今回の記事ではここらへんの詳細は省略してます。必要に応じて調べながら設定してください
いくつかポイントを
- MGNサービスの権限は AWSApplicationMigrationAgentPolicy です。
- EC2サーバー環境設定
EC2サーバーの設置場所として、VPC、Subnet、セキュリティグループなどのネットワーク環境を事前に構築する必要があります。
今回は、インターネット経由で移行を行い、外部からもアクセス可能なサーバーを想定しているため、外部アクセス可能なSubnetとセキュリティグループを作成しました。
念のため、EC2を一台作成し、NGINXなどのWebサーバーを立てて、外部からアクセスできるかどうかを確認しておくと安心です。私は下の画面のようなVPCを作っていたのでこのVPCを使いました。サブネットはアベイラビリティーゾーンの1aのパブリックなものを使います。
1.3 AWS MGN サービスの起動手順
まず、MGNの権限を持ったIAMユーザーでAWSにログインし、サービスページにアクセスします。
サービス検索バーに「MGN」と入力してください。
次に表示される画面で、**「使用を開始」**をクリックします。
＊右上のリージョンが今回移行先となる”東京”になっていることを確認してください！
続いて、**「サービスをセットアップ」**をクリックします。
これで、MGNの初期セットアップは完了です！
2.さくらクラウド側の準備
2.1 サーバーの起動
今回は、Rocky Linux 9.6 のサーバーを作成し、DockerおよびDocker Composeをインストールした上で、WordPress を起動させました。
この記事では詳細な手順は省略しますが、以下のチュートリアルが参考になります：
- さくらのクラウド超入門チュートリアル
https://qiita.com/zembutsu/items/538aa0a0211f9200b6c5
※ 上記記事はCentOS向けの内容なので、Rocky Linuxの場合は一部手順が異なる点に注意してください。
サーバーを起動したら、WordPressのサイトが正常に表示されるかを一度確認しておくと安心です。
今回のWordPress環境には、ブログ記事が1件投稿された状態になっています。
また、サーバー構成についても簡単にメモを残しています。
2.2 AWS MGN エージェントのダウンロード、実行
AWS MGNサービスに移行元のサーバーを認識させるためには、エージェントソフトウェアのインストールが必要です。
以下の公式ドキュメントを参考にしてください：（英語）
今回はLinuxサーバー（Rocky Linux 9.6）を使用しているため、構築済みのサーバーにログインし、**東京リージョン（ap-northeast-1）**向けのエージェントを以下のコマンドでダウンロードしました：
sudo wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init
続いて、インストーラーを実行します：
sudo ./aws-replication-installer-init
実行すると、以下のようにいくつかの情報入力を求められます：(移行元のリージョン、アクセスキーID、シークレットキー)
The installation of the AWS Replication Agent has started.
AWS Region Name: ap-northeast-1
AWS Access Key ID: ASIA12342DIP3356TKO
AWS Secret Access Key: ****************************************
Identifying volumes for replication.
Choose the disks you want to replicate. Your disks are: /dev/vda
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:
移行先のリージョンは ap-northeast-1（東京） を指定しました。
最後に表示されるディスク選択では、今回はすべてのディスクを移行するため、Enterキーを押して全選択しました。
約5分ほどでエージェントのセットアップが完了し、以下のような画面が表示されました：
これで、移行元サーバーの準備は完了です！
3. AWS MGNサービスを利用して移行
ここからが今回の記事のメインとなる部分です。
3.1 AWS MGNサービスから移行元サーバーの存在を確認
MGNのサービスページにアクセスすると、先ほどエージェントをインストールした移行元サーバーが認識され、一覧に表示されているはずです。
まず、画面右上のリージョンが 移行先のリージョン（例：アジアパシフィック 東京） になっていることを確認してください。
「ソースサーバー名」に、今回の移行元サーバーが名前付きで表示されていることを確認し、その名前をクリックします。
「レプリケーションの準備中」と表示され、しばらく待つ必要があります。今回は約10分ほどで完了しました。
待機中にEC2の画面を確認すると、レプリケーション用のインスタンスが起動しているのがわかります。
MGNの画面に戻り、次は移行先サーバーの起動設定を行います。
3.2 AWS側サーバーの起動設定
移行後のサーバーが正常に起動するように、インスタンスタイプやストレージ、ネットワーク環境などを事前に設定しておきます。
まず、MGNの画面から「起動設定」をクリックし、「編集」を選択します。
MGNでは、デフォルトでインスタンスタイプを自動的に選択する設定になっていますが、今回はテンプレートで明示的に指定するため、自動選択のオプションをオフにします。
次に、テンプレートを編集します。移行先の環境を定義するため、「変更」をクリックします。
続いてもう一度「変更」をクリックします。
テンプレートには「mgn」という名前を付けました。移行先の環境ごとにテンプレートを作成することになると思います。
インスタンスタイプとネットワーク設定
- インスタンスタイプは、移行元サーバーと同等のスペックを選択しました。
- ネットワークは、事前に作成しておいたパブリックサブネットを指定。
- アベイラビリティゾーンは ap-northeast-1a を選択。
- セキュリティグループは、外部からのHTTPおよびSSHアクセスが可能なものを使用しました
- 高度なネットワーク設定
このサーバーは外部からアクセス可能にする必要があるため、「高度なネットワーク設定」をクリックし、パブリックIPの自動割り当てを有効にしました。
最後に「テンプレートのバージョンを作成」をクリックして完了です。
テンプレートの作成ができました。表示してみましょう。
作成日時などを確認し、該当するテンプレートを選択して「デフォルトテンプレートとして設定」してください。
（今回は一度作り直したため、バージョンが「2」になっています）
確認してデフォルトで設定
設定が反映されていることを確認します。インスタンスタイプなどが表示されていればOKです。
これで、起動設定は完了です！
3.3 テストサーバーの起動
まずは、テスト移行を行います。
迷った場合は、左側メニューの「ソースサーバー」をクリックすると、現在移行対象となっているサーバーが表示されます。その名前をクリックしてください。
次に、画面右側の「アクション」が「テストインスタンスの起動」になっていない場合は、まだ準備中です。しばらく待ちましょう。
「ライフサイクル」欄で現在の状態も確認できます。
準備が整ったら、右側メニューから「テストインスタンスを起動」をクリックします。
確認画面が表示されるので、「起動」をクリックしてください。
以下のような画面に切り替わり、テストサーバーの起動処理が始まります。しばらく待ちましょう。
テストサーバーが起動すると、次のアクションが「テストを完了し、『カットオーバーの準備完了』としてマーク」に変わっていることを確認します。
画面下部には、起動したEC2インスタンスの情報も表示されます。
待っている間に、EC2の画面を確認すると、サーバーが起動している様子が見られます。
無事に起動したら、作成されたEC2インスタンスをクリックして詳細を確認します。
今回はパブリックIPを自動割り当てしているため、パブリックIPが表示されているはずです。
そのIPアドレスをブラウザの別タブで開いてアクセスしてみましょう。
無事にテストサーバーが起動していることが確認できました。
最後に、MGNの画面に戻り、テスト完了の操作を行います。
右側メニューから「『カットオーバーの準備完了』としてマーク」をクリックします。
確認画面が表示されるので、「続行」をクリックしてください。
これでテスト移行は完了です。次は本番移行（カットオーバー）に進む準備が整いました
3.4 本番移行
いよいよ最後のステップ、本番環境への移行です。
もう一度MGNの画面に戻り、対象のサーバーを確認します。
「アクション」が 「カットオーバーインスタンスの起動」 になっており、レプリケーションステータスが 「正常」 になっていることを確認してください。
準備が整ったら、「カットオーバーインスタンスの起動」をクリックします。
確認画面が表示されるので、「起動」をクリックしてください。
テストサーバーのときと同様に、しばらく待ちます。
無事に起動すると、次のアクションが「アーカイブ済みとしてマーク」に変わっていることを確認できます。
EC2の画面でも、起動したインスタンスを確認できます。
インスタンスを選択し、詳細を表示して パブリックIP を確認してください。
そのIPアドレスをブラウザの別タブで開いてアクセスしてみましょう。
無事に移行されたWordPressサイトが表示されれば、本番移行は成功です！
これで、マイグレーションは無事完了しました！
3.5 サービス終了
最後に、移行作業の終了処理を行います。
MGNの画面で「カットオーバーを最終処理」をクリックします。
確認画面が表示されるので、「最終処理」をクリックしてください。
次のアクションが表示されるので、内容を確認し、必要に応じて実行します。
これで、移行作業はすべて完了です！
お疲れさまでした 🎉
最後に注意点
移行が完了すると、AWS上にサーバーが起動した状態になります。
テスト目的で使用している場合は、不要なEC2インスタンスやストレージを削除しないと、課金が発生する可能性がありますので注意してください。
