AWS Application Migration Serviceによるサーバー移行とCloudEndureとの比較

はじめに

2021/5/18 に新しい移行用サービスである AWS Application Migration Service (AWS MGN) がリリースされました。東京リージョンでも利用可能です。

2019年に CloudEndure が AWS により買収され、CloudEndure Migration および CloudEndure Disaster Recovery が AWS サービスとして利用可能でしたが、専用のコンソールを介してアクセスする必要がありました。AWS MGN は CloudEndure Migration に基づいた後継サービスとなっており、AWS マネジメントコンソールに完全に統合されています。

どの移行サービスを使えばいい？

AWS GovCloud または China Region へ移行するケースを除いて、現在は AWS MGN の利用が推奨されています。

また CloudEndure Migration はすでに EOL がスケジュールされていますのでご注意ください。

・2022/6/30 新規ライセンスの割り当て停止
・2022/9/30 新規 Agent のインストール停止
・2022/12/30 既存ライセンスの期限切れ (サービス停止)

サポート OS

AWS MGN でサポートされる OS

・Microsoft Windows Server 2003 32 bit / 64bit
・Microsoft Windows Server 2003 R2 32 bit / 64bit
・Microsoft Windows Server 2008 32 bit / 64 bit
・Microsoft Windows Server 2008 R2 64 bit (patched)
・Microsoft Windows Server 2012 64 bit
・Microsoft Windows Server 2012 R2 64 bit
・Microsoft Windows Server 2016 64 bit
・Microsoft Windows Server 2019 64 bit
・Microsoft Windows Server 2022 64 bit
・Microsoft Windows 10 64 bit
・SUSE Linux (SLES) 12 and higher
・Debian Linux 9 and higher
・Ubuntu 12.04 and higher
・Red Hat Enterprise Linux (RHEL) 6.0 and higher
・Oracle Linux 6.0 and higher
・CentOS 6.0 and higher
・CentOS 5.0 - Only supported for agentless replication from vCenter

AWS MGN でサポートされない OS

CloudEndure Migration ではサポートされていた一部の古い OS は、AWS MGN ではサポートされていません。

・Microsoft Windows XP / 7 / 8 / vista
・SUSE Linux 11
・Debian Linux 8
・Kali Linux (すべてのバージョン)
・Red Hat Enterprise Linux (RHEL) 5.X

ネットワーク要件

以下は Service architecture and network architecture overview より引用したアーキテクチャ図です。CloudEndure User Consle への通信が AWS MGN のエンドポイントへに置き換わってはいますが、それ以外のネットワーク要件は CloudEndure Migration と同じであることがわかります。

・TCP 1500 Data Transfer

AWS Replication Agent がインストールされているソースサーバーがステージングエリアサブネット内のレプリケーションサーバーに対しデータを複製する際には、TCP Port 1500を介して通信します。Direct Connect や VPN による接続も可能です。

・TCP 443 Control Protocols

ソースサーバーが TCP Port 443 (HTTPS) を介して AWS MGN のエンドポイント (https://mgn..amazonaws.com) と通信する必要があります。主にソースサーバーのステータスやメトリクスがサービス側に送信されます。この通信はプロキシサーバー経由とすることもできます。

・TCP 443

ステージングエリアサブネット内のレプリケーションサーバーが TCP Port 443 を介して AWS MGN, EC2, S3 のエンドポイントと通信する必要があります。AWS MGN は Private Link をサポートしているため、ステージングエリアサブネットをプライベートサブネットとするとして構成することもできます。

料金

CloudEndure Migration ではライセンス発行後 90 日間は無料で利用することができました。90 日を超過した場合はレプリケーションが停止されます。

AWS MGN でも引き続き 90 日間は無料で利用できます。90 日を超えた場合はレプリケーションは停止されずに、レプリケーションを続行している期間、1 サーバーあたり、1 時間ごとに 0.042 USD が課金されます。 (全リージョン同一料金)

やってみる

※記事内のスクリーンショットは 2021/5/23 時点のものです。

オンプレミス環境を想定した任意の VPC のパブリックサブネットにソースサーバーとなる EC2 を起動します。ここではレプリケーション動作を確認するために WordPress をセットアップした EC2 を準備しました。

AWS MGN のセットアップ

AWS MGN のコンソールから Get Started をクリックすると、AWS MGN のセットアップ画面に遷移します。最初にこのセットアップで Replication Settings template を作成する必要があります。

ソースサーバーから AWS へのレプリケーションを行なう各種設定を Replication Settings template によって管理します。テンプレートの設定はデフォルト値として動作しますが、個々のソースサーバーに対して後から個別に設定を変更することができます。

Replication Servers

レプリケーションサーバーの設定として以下を指定します。レプリケーションサーバーは、ソースサーバーから AWS へデータをレプリケートするために使用される EC2 インスタンスです。

・Staging area subnet (レプリケーションサーバーを起動するサブネット)
・Replication Server のインスタンスタイプ
・EBS のボリュームタイプ
・EBS の暗号化設定
・セキュリティグループ

EBS のボリュームタイプの設定は、同期するディスクのサイズが 500 GiB 以上の場合にのみ影響する設定です。500 GiB 未満の場合は常にスループット最適化 HDD (st1) が使用されます。また プロビジョンド IOPS SSD は Replication Settings template では指定できません。

セキュリティグループの設定で常に Application Migration Service のセキュリティグループを使用するようチェックすると、テータをレプリケーションするために必要な TCP port 1500 がオープンされたセキュリティグループが自動で作成され、アタッチされます。このセキュリティグループを手動で編集した場合は AWS MGN によって自動的に修正されます。

作成されるセキュリティグループ (AWS Application Migration Service default Replication Server Security Group) のインバウンドルールおよびアウトバウンドルールは以下のとおりです。

ここでは Staging are subnet に検証用に作成したパブリックサブネットを指定し、その他はデフォルトのままとしました。

Data routing and throttling

プライベート IP を使用するかどうか、レプリケーション時の帯域制限を設定することができます。デフォルトではインターネット経由でデータがレプリケーションされますが、VPN, DirectConnect, VPC Peering 経由としたい場合はプライベート IP を使用することができます。

ここではデフォルト (パブリック IP 使用、帯域制限なし) として、テンプレートの作成を完了します。

AWS Replication Agent のインストール

ソースサーバーに AWS Replication Agent をインストールするには CloudEndure と同様、適切な権限をもった IAM ユーザーのクレデンシャルが必要です。AWS 管理ポリシーの AWSApplicationMigrationAgentPolicy をアタッチした IAM ユーザーを作成し、アクセスキー/シークレットアクセスキーを控えておきます。

ソースサーバー内でインストーラーをダウンロードし、実行します。リージョン、アクセスキー、シークレットアクセスキー、レプリケーションを行なうディスクを指定すると、AWS Replication Agent がインストールされます。

$ 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

The installation of the AWS Replication Agent has started.

AWS Region Name: ap-northeast-1

AWS Access Key ID: AKIAZXXXXXXXXXXXXXXX

AWS Secret Access Key:

Identifying volumes for replication.

Choose the disks you want to replicate. Your disks are: /dev/xvda

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:

Identified volume for replication: /dev/xvda of size 8 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-xxxxxxxxxxxxxxxxx.

The AWS Replication Agent was successfully installed.

これらのパラメーターは対話的な入力だけではなく、インストーラー実行時の引数として渡すこともできます。

参考: プライベート IP で同期を行う場合の設定

事前準備として 3点あります。

・レプリケーション設定で プライベート IP の使用を有効にする
・MGN の Interface 型 VPC エンドポイントを作成する
・S3 の Interface 型 VPC エンドポイントを作成する (ゲートウェイ型では無いことに注意)

インストーラーは MGN および S3 のエンドポイントにアクセスするため、インターフェース型 VPC エンドポイントが必要です。インストーラー実行時のパラメーターで --endpoint および --s3-endpoint を指定します。

$ sudo python3 aws-replication-installer-init.py \

  --region ap-northeast-1 \

  --aws-access-key-id AKIAIOSFODNN7EXAMPLE \

  --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \

  --endpoint https://vpce-xxxxxxxxxxxxxxxxx-yyyyyyyy.mgn.ap-northeast-1.vpce.amazonaws.com \

  --s3-endpoint https://vpce-zzzzzzzzzzzzzzzzz-yyyyyyyy.s3.ap-northeast-1.vpce.amazonaws.com

レプリケーション

エージェントのインストールが完了すると、初回の同期プロセスが自動的に実行されます。コンソールを確認すると移行元の対象サーバーが表示されます。

EC2 コンソール確認すると、Replication Settings template の設定に従って、Replicatoin Sever が起動していることがわかります。

前述のとおり、ソースサーバーごとに Replication Settings から個別にレプリケーション設定を変更することができます。

また、個々のソースサーバー内の Disk settings からレプリケーションするディスクごとに EBS のボリュームタイプをカスタマイズすることが可能です。

この設定では st1/gp2 以外のボリュームタイプも選択できます。
2022/2/28 の アップデートで gp3 も選択できるようになりました。

初回の同期プロセスが完了して EBS スナップショットが作成されると、ソースサーバーのライフサイクルが Ready for testing に遷移します。

ソースサーバーの Launch settings からテストインスタンス、カットオーバーインスタンス起動時の一般的な起動設定および、EC2 の起動テンプレートを編集できます。起動テンプレートは AWS MGN によりソースサーバーごとに自動的に作成されます。今回の環境ではインスタンスタイプが c4.large, EBS のボリュームタイプが io1 が指定されており、オーバースペックなため、編集していきます。

Launch settings の変更

一般的な起動設定では Instance type right sizing がデフォルトで有効化されています。これはソースサーバーのハードウェア構成から適切なインスタンスタイプを自動で選択する機能です。この機能により起動テンプレートのインスタンスタイプで c4.large が選択されています。Basic (On) → None (Off) に変更して機能を無効化します。

続いて起動テンプレートの Modify をクリックすると、ポップアップで警告ができます。AWS MGN は起動テンプレートの "Default" version を常に参照するため、起動テンプレートの新しいバージョンを作成したら、Default の向き先バージョンを変えるように警告がでます。

ここでは以下の 6 点を変更しました。Instance type right sizing が有効である場合、インスタンスタイプを変更しても AWS MGN によって強制的に推奨のインスタンスタイプ (今回の場合は c4.large)で上書きされてしまうため、ご注意ください。

・インスタンスタイプを t3.micro に変更
・EBS のボリュームタイプを gp2 に変更
・IAM インスタンスプロファイルを設定
・サブネット (Migrated Resources Subnet) を設定
・セキュリティグループを設定
・パブリック IP を有効化

起動テンプレートのデフォルトバージョンを更新後のバージョンに変更します。

テストインスタンスの起動

Test and Cutover から Launch test instances を実行し、テストインスタンスを起動できます。移行したサーバーが AWS 環境上で正常に動作することを確認するためにカットオーバー前にテストインスタンスを起動し、検証を行なうことが推奨されています。

ライフサイクルが Test in progress に遷移します。

AWS Application Migration Service Conversion Server が起動して、スナップショットを変換し、テストインスタンスが作成されます。

テストインスタンスが起動したら WordPress にアクセスし、インスタンスが正常に移行されていることを確認します。

テストが完了したら、Test and Cutover から Mark as "Ready for cutover" をクリックします。もしテストに問題が発生した場合は Revert to "Ready to testing" からライフサイクルを一つ前に戻すこともできます。

確認メッセージで Continue を選択します。テストインスタンスを削除するチェックボックスがデフォルトで有効になっているため、同時に削除されます。

ライフサイクルが Ready for cutover に遷移します。

カットオーバーインスタンスの起動

テストが完了したらいよいよ移行環境にカットオーバーを行います。Test and Cutover から Launch cutover instances をクリックします。

再度 Conversion Server が起動してスナップショットを変換し、カットオーバーインスタンスが作成されます。ステータスは Cutover in progress　に遷移します。

カットオーバーインスタンスが起動したら再度 WordPress にアクセスし、正しく移行されていることを確認します。

移行の確認が完了したら、Test and Cutover から Finalize cutover を選択し、カットオーバーを確定することができます。カットオーバーに問題が発生した場合は Revert to "Ready for cutover" からライフサイクルを一つ前に戻すこともできます。

カットオーバーを確定すると、ライフサイクルは Cutover complete に遷移します。これによりソースサーバーからのデータレプリケーションは自動で停止されます。

最後のステップはソースサーバーのアーカイブです。Actions から Mark as archived を選択します。これにより移行が完了したサーバーはソースサーバーの一覧から表示されなくなります。

Preferences (歯車アイコン) から Show only archived servers を ON にすることで、アーカイブしたサーバーのみを表示させることもできます。

参考: AWS Migration Hub との連携

CloudEndure 同様、AWS MGN も Migration Hub と連携してサービスやアプリケーション単位、複数リージョンの移行状況を管理することができます。

AWS MGN によるサーバー移行を一通り試してみましたが、CloudEndure を使用したことがある方であれば、すんなり触ることができるかと思います。起動テンプレートの管理など若干クセはありますが、マネージドコンソールに統合され、移行ステータスを管理できるのは想像以上に使いやすかったです。API も公開されているため、SDK や CLI による自動化等も検討できそうです。

参考

余談

なんで略称が MGN なんでしょうか。MiGratioN? 単純に考えれば AMS になるのですが、実は AMS という略称はすでに別のサービスで使用されています。AWS Managed Services (AMS) です。

以上です。参考になれば幸いです。

※掲載内容は個人の見解です。
※会社名、製品名、サービス名等は、各社の登録商標または商標です。