大規模なサーバーマイグレーションに役立つCloud Migration Factory on AWSのご紹介

Cloud Migration Factory on AWS のワークショップをやってみました。

渡部比佐志

2023.07.28

こんにちは。AWS事業本部マイグレーション部の渡部です。
Cloud Migration Factory on AWSというサーバー移行のためのソリューションについて、ワークショップを実施する機会がありましたので、ご紹介したいと思います。

Cloud Migration Factory on AWSとは

Cloud Migration Factory on AWS(以下、CMF)は、AWS Application Migration Service(以下、MGN)でサーバー移行を行う際の手作業が必要なプロセスを自動化するソリューションです。
MGNでは、移行元へのエージェントインストールやステータス確認などの作業を対象サーバー1台ずつに対して行う必要がありますが、CMFは、移行元となるソースサーバーを移行ウェーブ(Wave)という単位にまとめ、必要なアクションをJobとして実行することで、移行元や移行先サーバーに対しての一括操作を行います。
そのため、100台を超える様な大規模なサーバー移行には、CMFを利用することで移行作業をよりスムーズに行うことができます。

CMFはオープンソースで、Github上に公開されており、アクションをカスタマイズしたり、新たに作成することも可能です。

デフォルトで用意されているアクションは以下の通りです。

アクション名	内容
0-Check MGN Prerequisites	MGN利用の前提条件をチェック
1-Install MGN Agents	レプリケーションエージェントのインストール
1-Copy Post Launch Scripts	起動後スクリプトをソースサーバーにコピー
2-Add local user	ソースサーバーにユーザーを追加
2-Remove local user	ソースサーバーのユーザーを削除
2-Verify Replication Status	レプリケーションのステータス確認
3-Shutdown All Servers	ソースサーバーのシャットダウン
3-Verify Instance Status	ターゲットインスタンスのステータス確認
4-Get target Instance IP	ターゲットインスタンスのIPアドレスを取得
4-Verify Target Server Connection	ターゲットサーバの接続検証
5-Post Cutover Validation	カットオーバー後の検証

また、マルチアカウント / マルチリージョンへの移行にも対応しています。
最近、MGNにもマルチアカウントへの移行機能が追加されましたが、Organizations環境下にあることが前提となっています。（下記記事を参照）
CMFにはその制約が無いため、複雑なアカウント構成への移行作業にも利用可能です。

CMFのアーキテクチャ構成

https://aws.amazon.com/jp/solutions/implementations/cloud-migration-factory-on-aws/

CMFのアーキテクチャは上図の通りです。WebインターフェイスとAPI Gateway, AWS Lambda等のサーバレスで構成されており、RestAPIを介してユーザ認証やMGNへのアクションを実行する仕組みになっています。
環境構築のためのCloud Formationテンプレートが用意されており、本体リソースを作成するテンプレートと移行先アカウントへのアクセス許可用リソースを作成するテンプレートの２つを使用します。注意点として、画面左端のmigration automation serverはCloudFormationテンプレートに含まれておらず、別途手動でEC2などへの構築が必要です。
CMFの各操作は、migration automation serverを介して、Webインターフェイスから行います。
デプロイ方法は、別の機会にご紹介できればと思います。詳細は以下をご参照ください。

CMFのワークショップをやってみた

AWS の Cloud Migration Factory による大規模なリホスト

実施したワークショップは上記になります。詳細な操作手順はワークショップの説明に画面キャプチャ付きで記載されていますのでご確認ください。この記事では、利用の流れを中心にポイントを絞ってお伝えしたいと思います。

ワークショップの実施内容

ワークショップで実施した内容は、下図のWave-1のサーバー群をCMFでターゲットサブネットに移行するというシナリオです。

https://catalog.us-east-1.prod.workshops.aws/workshops/13469164-f225-41a8-8d2d-1080701889e4/ja-JP/1-getting-started/explore-your-environment

ワークショップの目次

はじめに
- タスク 1 - ワークショップ環境への接続
- タスク 2 - 踏み台ホストへの接続
- タスク 3 - 環境を調べる
移行ツールのセットアップ
- タスク 1 - AWS MGN を初期化する
- タスク 2 - CMF の設定
- タスク 3 - ユーザー認証情報の追加
- タスク 4 - 移行データのインポート
ステージ 1 - 移行を初期化
- タスク 1 - MGN エージェントのインストール
- タスク 2 - 起動後のスクリプトのコピー
- タスク 3 - 起動テンプレートの検証
ステージ 2 - 移行を実行する
- タスク 1 - 複製の検証
- タスク 2 - カットオーバーの準備完了
- タスク 3 - ソースをシャットダウン
- タスク 4 - カットオーバーの開始
ステージ 3 - 最終確認とテスト
- タスク 1 - EC2 インスタンスの検証
- タスク 2 - リホスト移行のテスト
- タスク 3 - アプリケーションのテスト

はじめに

このワークショップでは、CMFの各リソースや踏み台ホストが予めデプロイされた状態になっています。
最初の「はじめに」のセクションでは、用意されたワークショップ環境に接続し、踏み台ホストから移行元サーバーを確認します。

タスク 2 - 踏み台ホストへの接続
踏み台ホストへのリモートデスクトップ接続には、AWS Systems Manager Fleet Manager（フリートマネージャー）で接続すると簡単です。フリートマネージャーを利用すると、RDPクライアントが必要なく、マネージメントコンソール（ブラウザ）上から踏み台ホストのEC2へ接続できます。

移行ツールのセットアップ

次の「移行ツールのセットアップ」のセクションでは、MGNの初期化、CMFの初期設定、移行元サーバーの情報のインポートを行います。

タスク 1 - AWS MGN を初期化する
MGNの初期化手順は、CMFを利用せずにMGNだけを利用する場合と同じ内容です。MGNのコンソール上からレプリケーションテンプレートを編集し、レプリケーションサーバーのインスタンスタイプや移行先のサブネット、セキュリティグループなどを指定します。
なお、移行先のアカウント/リージョンが複数ある場合は、それぞれのアカウント/リージョンでMGNを初期化する必要があります。
タスク 2 - CMF の設定
踏み台ホスト上のブラウザからCMFコンソールにログインし、初期設定を行います。
移行先が複数アカウントになる場合は、Administration → Attributes からターゲットのAWSアカウントIDを複数指定します。
タスク 3 - ユーザー認証情報の追加
移行元サーバーに接続するための認証情報を設定します。同一の移行ウェーブに設定できる認証情報はLinux/Windowsで一種類ずつです。つまり、同一移行ウェーブのLinux/Windowsサーバーは同一の認証情報を使用してログインできる必要があります。

タスク 4 - 移行データのインポート
移行情報をCMFにインポートします。CSV形式のインプット情報ファイルのテンプレートがCMFの画面上からダウンロードできますので、移行元サーバーの情報と移行先の情報についてテンプレートを埋める形で用意します。インプット情報ファイルの項目は以下の通りです。

項目名	内容	記入例
wave_name	移行ウェーブ名	Wave1
app_name	アプリ名	app01-hr
aws_region	移行先AWSリージョン	us-east-1
aws_accountid	移行先AWSアカウント	111122223333
server_name	移行元サーバー名	Server1
server_os_family	移行元サーバーOS	windows
server_os_version	移行元OSバージョン	windows server 2012 R2
server_fqdn	移行元サーバーFQDN	server1.mydomain.local
server_tier	移行元サーバーティア	web
server_environment	移行元サーバー環境	dev
r_type	移行タイプ	Rehost
subnet_IDs	本番インスタンスのサブネットID	subnet-1111
securitygroup_IDs	本番インスタンスのセキュリティグループID	sg-1111;sg-2222
subnet_IDs_test	テストインスタンスのサブネットID	subnet-1111
securitygroup_IDs_test	テストインスタンスのセキュリティグループID	sg-3333
instanceType	インスタンスタイプ	m4.large
tenancy	テナント	Shared
tags	タグ	CostCenter=123;BU=IT;Location=US

インプット情報ファイルをインポートすると、サーバー情報がCMFダッシュボードに反映されます。
　　　　

ステージ 1 - 移行を初期化

ここからが移行の実作業になります。

タスク 1 - MGN エージェントのインストール
- 前提条件の確認
  ワークショップの手順には含まれませんが、0-Check MGN Prerequisitesアクションを実行すると、各サーバーにMGNのレプリケーションエージェントのインストールが可能かチェックすることができます。このアクションは、移行元サーバーに接続し、TCP ポート1500、TCP ポート443の疎通、ルートボリュームの空き領域、.Net Frameworkのバージョンなど、MGN利用に必要な前提条件を満たしているかを確認します。
- レプリケーションエージェントのインストール
  CMFコンソールのAutomation →　Jobsを選択し、Actionsより、Run Automationを選択します。
  Jobの作成画面で1-Install MGN Agentsアクションを指定して実行すると、指定したウェーブに属する各サーバーにMGNレプリケーションエージェントがインストールされます。
  エージェントインストールが正常に完了すると、CMFコンソールのサーバー一覧に移行元サーバーが表示されます。
タスク 2 - 起動後のスクリプトのコピー
1-Copy Post Launch Scriptsアクションを使用して、起動後のスクリプトファイルを移行元サーバーの指定フォルダーにコピーすることができます。移行元の各サーバーにスクリプトをコピーしておくことで、MGNでのインスタンス起動時に自動的に処理が実行されます。
このワークショップでは、移行後の新しいIPアドレスでDNSサーバーを更新するための起動スクリプトを設定します。

ステージ 2 - 移行を実行する

移行を実行するセクションになります。

タスク 1 - 複製の検証
2-Verify Replication Statusアクションで、指定ウェーブに属するサーバーのレプリケーション状態を確認します。初回レプリケーションが完了していなかったり、レプリケーションが正常に実行されていない場合はエラーとなります。レプリケーション状態が正常でアクションが完了すると、CMFコンソールのMigration Management → Serverの画面でReplication StatusがHealthyになります。
タスク 2 - カットオーバーの準備完了
カットオーバーを実行するために、移行ライフサイクルをカットオーバーの準備完了に設定する必要があります。 CMFコンソールから一括でMGNに指示することが可能です。MGNへの操作指示は、CMFコンソールで、Migration Management → Waveを表示し、対象とするWaveを選択、Actions → Rehost → MGNの順に選択します。

MGNのアクションを選択する画面が表示されるので、Mark as Ready for Cutoverアクションを選択して実行します。
このワークショップでは、テストインスタンスの起動手順は省略されています。本来はカットオーバー前にテストインスタンスの起動とテストを行います。
タスク 3 - ソースをシャットダウン
カットオーバーを行う前に移行元サーバーのシャットダウンを行います。3-Shutdown All Serversアクションで、指定したウェーブに属するサーバーをまとめてシャットダウンすることができます。
下画面は、アクションの実行後にMGNコンソールでソースサーバーの状態を表示したものです。各サーバーが停止中の状態になっています。
タスク 4 - カットオーバーの開始
カットオーバーを開始します。CMFコンソールから、Migration Management → Waveを表示し、対象とするWaveを選択、Actions → Rehost →　MGNの順に選択します。
MGNのアクションを選択する画面が表示されるので、Launch Cutover Instancesアクションを選択して実行します。

実行するとMGNコンソールのソースサーバーの移行ライフサイクルがカットオーバーが進行中になります。

ステージ 3 - 最終確認とテスト

カットオーバー後の確認を行います。

タスク 1 - EC2 インスタンスの検証
移行後のサーバーのインスタンスステータスチェックを行います。
3-Verify Instance Statusアクションで、カットオーバーインスタンスのEC2が正常に起動しているかどうか確認することができます。
チェックが正常にが完了すると、Migration Management → ServerのMigration Statusに2/2status checks:Passedと表示されます。

ここまでで、移行後のサーバー起動が完了しているはずです。
PINGコマンドで移行先サーバーへの疎通を確認したり、移行したアプリケーションの動作確認を行います。
そして、動作に問題がなければ最後に終了処理を行います。

ファイナライズ

ワークショップには記載がありませんが、MGNのファイナライズを行うことで移行完了となります。この作業もCMFコンソールから一括で行うことができます。
CMFコンソールから、Migration Management → Waveを表示し、対象とするWaveを選択、Actions → Rehost →　MGNの順に選択します。 MGNのアクションを選択する画面が表示されるので、Finalize Cutoverアクションを選択して実行します。

まとめ

Cloud Migration Factory on AWS(CMF)の利用方法をご紹介しました。
改めて、CMFの利用の流れをまとめると、以下の通りです。

CloudFormationテンプレートを用いてCMFをデプロイする
インプット情報ファイルによって移行元サーバー、移行先環境を定義する
MGNのレプリケーションエージェントを移行ウェーブ単位に一括インストールする
MGNの移行手順に沿って作業を実施、各作業は移行ウェーブ単位にCMFコンソールから一括で操作する

MGNは、基本的に個々のサーバー単位で移行作業を実施するのに対して、CMFは移行ウェーブ単位での作業となり、大規模なサーバー移行に有効なソリューションです。 MGNでの繰り返しの作業が辛い、という場合は、ぜひCMFを利用して頂ければと思います。

以上、この記事がどなたかの参考になれば幸いです。

大規模なサーバーマイグレーションに役立つCloud Migration Factory on AWSのご紹介

Cloud Migration Factory on AWSとは

CMFのアーキテクチャ構成