APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

AWS Application Migration Serviceの紹介

はじめに

こんにちは、クラウド事業部の山路です。

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ブログより引用

  1. 移行元サーバーにAWS Replication Agentをインストールする: 例外として、移行元サーバーがVMWare vCenter上にある場合、エージェントレスでの移行をサポートしています。
  2. インストール後のinitial syncが完了するのを確認する: 移行元サーバーからAWS EBSへデータが複製されます。データの複製にはReplication ServerというEC2インスタンスを使用します。initial sync完了後は移行元サーバーに変更が入るとそれを検知し、都度Syncが実行されます。
  3. テストインスタンスをAWS上に起動する: MGNは移行後の本番サーバを起動する前に、必ずテストインスタンスの起動と確認を必須としています。これを実行しなければ本番用インスタンスを起動することができません。
  4. テストインスタンスに対してユーザーが受け入れテストを実行する: テストインスタンスに対するテストはユーザーが実施します。問題がなければテストインスタンスを削除します。
  5. (必要に応じて)移行元サーバー上のサービスを停止する: 移行の実施に影響する場合はあらかじめ移行元のサービスを停止しておきます。
  6. 本番用インスタンスを起動する: テストインスタンス起動時と同じような手順で本番用のインスタンスを起動します。なおMGNでは本番用インスタンスをCutover Serverと表記します。
  7. 本番用インスタンスに問題がないことを確認する
  8. 移行元サーバーをアーカイブする: 移行を実施し、問題がなければ移行元のサーバーを停止して完了です。

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

参考リンク

最後に

弊社はAWSセレクトティアサービスパートナー認定を受けております。また以下のようにAWSの活用を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。

www.ap-com.co.jp