はじめに
こんにちは、クラウド事業部の山路です。
AWSなどのクラウドサービスを活用して、アプリケーション開発のモダナイズをしたい、DXを実現したい、という要望は日々高まっています。一方で既存のシステムを自社インフラに抱えている場合、多くは既存システムをAWSに移行することから始めなければなりません。
AWSではオンプレや別クラウドプロバイダーからの移行をサポートするサービスを多数リリースしていますが、今回はその中からAWS Application Migration Service (以降MGNと表記)を取り上げます。
AWSの案内する移行パターン
MGNの紹介をする前に、AWSが想定する移行パターンについて触れておきます。
AWSでは以下の7パターンを想定しており、MGNはそのうちRehostパターンをサポートするサービスです。
※AWSブログより引用
Rehostとは、既存のサーバー内に稼働するアプリケーションや構成を変更せず、クラウドに移行するパターンを指します。Rehostパターンを採用すると、既存構成の大部分を踏襲することになるので、構成変更などを最小限に抑え、比較的移行をスムーズに実行することができます。Rehostには大きく2つの移行方法があり、「EC2を新規構築して移行する」か「移行元からデータをコピーしてEC2に移行」になります。AWS MGNは後者をサポートするサービスであり、特に大規模環境での移行に適しているとされています。
AWS MGNとは
AWS MGNは、オンプレやAWS以外のクラウド環境、AWSの別リージョンなどのサーバーからデータを取得し、Amazon EC2としてAWS上でサーバーを再構築することで、既存サーバー内のデータをそのままAWS上に再現することができます。移行元サーバーをAWS上でネイティブに実行できるよう自動で変換を行うなど、移行プロセスの多くの部分を自動で処理してくれるため、ヒューマンエラーの発生を最小限に抑えることが期待できます。
※AWSドキュメントより引用
AWS MGNにはRehostパターンの移行をサポートする特徴をいくつか備えています。
多くのOS・バージョンをサポート
AWS MGNでは、サポート期限切れのOSバージョンも含め、多くのOS・バージョンをサポートしています。対象のOSには、Windows Server 2003のようなEOLを迎えているOSも含まれています。これにより、既存環境で塩漬けになっていた古い環境をAWS上に移行することもしやすくなります。
※対象のOSバージョンの詳細は AWSドキュメントのこちら に記載されています。
無料利用期間がある
AWS MGNでは、移行元サーバーに専用のAgentをインストールする必要があります。AWS MGNの利用料金は、このAgentをインストールしてから90日以上経過した場合に発生します。つまりAgentインストールから90日間は無料期間となるので、この間にテストや移行を完了すれば、移行にかかるコストを抑えながらサーバーを移行することができます。
また、そもそもAWS MGNが自分たちのプロジェクトに適するか評価する場合も、Agentインストールからしばらくの間は（実際に起動するEC2インスタンスの利用料などはかかるものの）コストを抑えながらテストに使うこともできるため、事前に検証もしやすいのではないかと思います。
ただし、AWS MGNがデータの複製に利用するReplication Server、およびデータ移行後に起動するEC2インスタンスなどは、無料利用期間などは関係なく利用量に応じた金額が発生するため、ご注意ください。
※AWS MGNの料金は AWSドキュメントのこちら に記載されています。
他の移行サービスとの連携
AWSにはほかにもAWSへの移行をサポートするサービスが存在します。このうち AWS Migration Hub は移行前のチェックから移行の実施など、移行に関する様々な面をカバーしています。AWS Migration Hubの移行は別のAWSサービスで行われますが、その中にはAWS MGNも含まれています。そのため、AWS Migration Hubとの連携により、移行計画の考案から移行実施までをシームレスに実施することが可能になります。
またAWS MGNはAWSサービスの1つとして提供されているため、CloudWatch / CloudTrailなどのサービスと組み合わせて使うこともできます。
MGN利用の流れ
MGN利用の流れは AWSドキュメント にも記載されていますが、以下のような流れで利用します。
※AWSブログより引用
- 移行元サーバーにAWS Replication Agentをインストールする: 例外として、移行元サーバーがVMWare vCenter上にある場合、エージェントレスでの移行をサポートしています。
- インストール後のinitial syncが完了するのを確認する: 移行元サーバーからAWS EBSへデータが複製されます。データの複製にはReplication ServerというEC2インスタンスを使用します。initial sync完了後は移行元サーバーに変更が入るとそれを検知し、都度Syncが実行されます。
- テストインスタンスをAWS上に起動する: MGNは移行後の本番サーバを起動する前に、必ずテストインスタンスの起動と確認を必須としています。これを実行しなければ本番用インスタンスを起動することができません。
- テストインスタンスに対してユーザーが受け入れテストを実行する: テストインスタンスに対するテストはユーザーが実施します。問題がなければテストインスタンスを削除します。
- （必要に応じて）移行元サーバー上のサービスを停止する: 移行の実施に影響する場合はあらかじめ移行元のサービスを停止しておきます。
- 本番用インスタンスを起動する: テストインスタンス起動時と同じような手順で本番用のインスタンスを起動します。なおMGNでは本番用インスタンスをCutover Serverと表記します。
- 本番用インスタンスに問題がないことを確認する
- 移行元サーバーをアーカイブする: 移行を実施し、問題がなければ移行元のサーバーを停止して完了です。
MGNの検証
ここから実際にMGNを使ってみた様子を紹介します。
利用条件
MGNを利用するうえで、いくつか満たさなければならない条件があります。最も影響がありそうなところだと、移行元サーバーからAWS向けの通信許可、移行元サーバーのディレクトリの空き容量、Linuxの場合Pythonがインストールされているか、などが挙げられます。
- ネットワーク:
- 移行元サーバーからAWS向けに1500番ポートからデータを送信できること
- Replication ServerからAWS MGN API向けに443番ポートからデータを送信できる
- その他詳細: AWSドキュメントを確認
- 移行サーバー
- Rootディレクトリに2GB以上の空きがあること
- 300MB以上のRAMの空きがあること
- Linuxの場合、Pythonがインストールされていること (Python 2.4 or 3.0以上のバージョン
- その他詳細: AWSドキュメントを確認
利用方法（概要）
今回はAWSの us-east-1 リージョンから ap-northeast-1 リージョンにEC2インスタンスを移行する構成としました。まず移行元サーバーを作成後、MGNでの移行後の確認のため、いくつかファイルを作成しておきます。
# 移行元サーバーの情報 ubuntu@ip-172-31-8-250:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal ubuntu@ip-172-31-8-250:~$ uname -a Linux ip-172-31-8-250 5.15.0-1036-aws #40~20.04.1-Ubuntu SMP Mon Apr 24 00:21:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux ubuntu@ip-172-31-8-250:~$ curl -s http://169.254.169.254/latest/meta-data/placement/region us-east-1 ubuntu@ip-172-31-8-250:~$ python3 -V Python 3.8.10 # テスト用のファイル作成 ubuntu@ip-172-31-8-250:~$ dd if=/dev/zero of=testfile_10G bs=1G count=10 ubuntu@ip-172-31-8-250:~$ vi testfile.txt ubuntu@ip-172-31-8-250:~$ cat testfile.txt mgn test
AWS MGN Agentを用意するには、AWSマネジメントコンソールから操作し、インストール用のコマンドを用意します。ここではAWSにアクセスするためのアクセスキー・シークレットアクセスキーをあらかじめ用意することが必要です。
コマンドを用意したので移行元サーバー上で実行します。
ubuntu@ip-172-31-8-250:~$ wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init ubuntu@ip-172-31-8-250:~$ sudo chmod +x aws-replication-installer-init ubuntu@ip-172-31-8-250:~$ sudo ./aws-replication-installer-init --region ap-northeast-1 --aws-access-key-id XXXXXXXX --aws-secret-access-key xxxxxxxxxxxxxxxx --no-prompt The installation of the AWS Replication Agent has started. Identifying volumes for replication. Identified volume for replication: /dev/nvme0n1 of size 100 GiB All volumes for replication were successfully identified. Downloading the AWS Replication Agent onto the source server... Finished. Installing the AWS Replication Agent onto the source server... Finished. Syncing the source server with the Application Migration Service Console... Finished. The following is the source server ID: s-6e4a8a6e0ec4ed99b. You now have 1 active source server out of a total quota of 150. Learn more about increasing source servers limit at https://docs.aws.amazon.com/mgn/latest/ug/MGN-service-limits.html The AWS Replication Agent was successfully installed.
しばらくするとinitial syncを実行しているのがAWSマネジメントコンソールからも確認できます。
なおこの時移行元サーバー上でプロセスなどを見ると、以下のようにいくつかのプロセスが立ち上がっているのを確認できます。
ubuntu@ip-172-31-8-250:~$ ps auxw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.2 0.3 103812 12944 ? Ss 01:45 0:04 /sbin/init (一部抜粋) aws-rep+ 53506 10.2 4.2 2499548 169464 ? SNsl 02:12 0:45 /var/lib/aws-replication-agent/jre/bin/java -client -Xms88m -Xmx8 aws-rep+ 53507 0.0 0.0 2724 616 ? SNs 02:12 0:00 /var/lib/aws-replication-agent/run_linux_migration_scripts_period aws-rep+ 53508 0.0 0.0 2724 620 ? SNs 02:12 0:00 /var/lib/aws-replication-agent/tailer -a agent.config -f agent.lo aws-rep+ 53509 0.0 0.0 2724 612 ? SNs 02:12 0:00 /var/lib/aws-replication-agent/update_onprem_volumes -a agent.con aws-rep+ 53510 0.1 1.2 277756 48964 ? SNl 02:12 0:00 /var/lib/aws-replication-agent/tailer -a agent.config -f agent.lo aws-rep+ 53511 0.2 1.0 124476 40832 ? SN 02:12 0:01 /var/lib/aws-replication-agent/update_onprem_volumes -a agent.con aws-rep+ 53513 0.1 0.8 117048 32672 ? SN 02:12 0:00 /var/lib/aws-replication-agent/run_linux_migration_scripts_period aws-rep+ 53597 0.0 0.0 7280 520 ? SN 02:12 0:00 tail --lines=10 -F agent.log.0 # initial sync中の負荷の状況 ubuntu@ip-172-31-8-250:~$ top top - 02:18:38 up 33 min, 2 users, load average: 0.44, 0.52, 0.44 Tasks: 112 total, 1 running, 111 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.3 sy, 3.8 ni, 91.9 id, 1.6 wa, 0.0 hi, 0.0 si, 2.1 st MiB Mem : 3864.0 total, 564.7 free, 508.9 used, 2790.4 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 3067.7 avail Mem (一部抜粋) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 53506 aws-rep+ 23 3 2499548 169820 22476 S 10.3 4.3 0:36.58 java 32 root 20 0 0 0 0 S 0.3 0.0 0:00.09 kcompactd0 1 root 20 0 103812 12944 8548 S 0.0 0.3 0:04.84 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq # ネットワークの状況 ## Sync前 ubuntu@ip-172-31-8-250:~$ ip -s link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 31846 294 0 0 0 0 TX: bytes packets errors dropped carrier collsns 31846 294 0 0 0 0 2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:fd:d5:c9:61:5d brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 316293749 215190 0 0 0 0 TX: bytes packets errors dropped carrier collsns 2271416 22322 0 0 0 0 altname enp0s5 ## Sync中 ubuntu@ip-172-31-8-250:~$ ip -s link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 33270 310 0 0 0 0 TX: bytes packets errors dropped carrier collsns 33270 310 0 0 0 0 2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 02:fd:d5:c9:61:5d brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 317338205 227835 0 0 0 0 TX: bytes packets errors dropped carrier collsns 1140052847 777417 0 0 0 0 altname enp0s5 ubuntu@ip-172-31-8-250:~$
Syncの完了まではしばらくかかります。今回は90分ほどかかりました。
Syncが完了したら次にテストインスタンスの起動を行います。
このとき、事前にEC2の起動テンプレートを更新し、テンプレートのバージョンを更新する必要があります。起動テンプレートを更新しないと、サブネットIDなどのインスタンス起動に必要な情報が不足した状態で起動しようとし、起動に失敗します。
起動テンプレートを準備して再度実行し、しばらくするとテストインスタンスが立ち上がります。
インスタンスが立ち上がったので、Elastic IPなどを付与してSSHでログインしてみます。ログインすると、以下のように移行前に作成したファイルが存在することを確認できます。
ubuntu@ip-10-0-1-94:~$ ls -l total 10496812 -rwxrwxr-x 1 ubuntu ubuntu 10913016 Jul 17 06:19 aws-replication-installer-init -rw-r--r-- 1 root root 390444 Jul 23 02:12 aws_replication_agent_installer.log -rw-rw-r-- 1 ubuntu ubuntu 9 Jul 23 02:01 testfile.txt -rw-rw-r-- 1 ubuntu ubuntu 10737418240 Jul 23 01:54 testfile_10G ubuntu@ip-10-0-1-94:~$ cat testfile.txt mgn test
テストインスタンスの動作確認が取れたので、ここでは次のステップに進み、本番インスタンスの立ち上げを行います。本番インスタンスの立ち上げは、まず カットオーバーの準備完了 というステップに移行し、テストが完了した状態としてマークします。その後 カットオーバーインスタンスを起動 を選択することで本番用インスタンスを起動します。
テストインスタンスと同様、しばらくすると本番用インスタンスも起動します。
無事に立ち上がったら、移行作業の完了を進めます。カットオーバーの最終処理 を選択すると、複製したデータや複製に利用したEC2インスタンスなどが削除されます。
最後に アーカイブ済みとしてマーク を選択することで、移行は完了です。
なおアーカイブ後に移行元サーバーを確認すると、Sync中にあったプロセスのいくつかは停止し、新たに shutdown-agent.sh というプロセスが立ち上がっている様子などが確認できます。
ubuntu@ip-172-31-8-250:~$ ps auxw USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.3 103812 12944 ? Ss 01:45 0:04 /sbin/init (一部抜粋) aws-rep+ 53506 5.0 5.2 2502760 208756 ? SNsl 02:12 8:31 /var/lib/aws-replication-agent/jre/bin/java -client -Xms88m -Xmx8 aws-rep+ 54952 0.0 0.0 8624 3284 ? SNs 04:59 0:00 /bin/bash /var/lib/aws-replication-agent/shutdown-agent.sh aws-rep+ 54959 0.0 0.0 7272 516 ? SN 04:59 0:00 tail --pid=53506 -f /dev/null
参考リンク
- Serverworks Bolg - 【Application Migration Service(MGN)】概要と仕組みについて
- AWS Black Belt - AWS Application Migration Service (AWS MGN) 概要
最後に
弊社はAWSアドバンスドティアサービスパートナー認定を受けております。また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。
