AWS MGNを用いた大規模なリホスト移行におけるEC2起動テンプレートの管理

多くのお客様は、AWS Application Migration Service (MGN)を使用してAWSに環境をリホストしており、各移行のウェーブの中で移行するすべてのサーバーに対して将来（移行後）のコンフィグレーションを準備する必要があります。移行ウェーブに複数のサーバーが含まれる場合、お客様はAWSコンソールで複数のEC2起動テンプレートを手動で構成する必要があります。AWS MGNを使用して移行する各サーバーについて、2つのセクションでパラメーターを検証し、設定する必要があります：最初は一般的な起動設定、次にEC2起動テンプレートセクションです。次に、新しいインスタンスの起動時に変更を反映するために、EC2起動テンプレートの最新バージョンをデフォルトとしてマークする必要があります。

数台のサーバーを対象とする概念実証（PoC）プロジェクトであっても、これらの構成情報の管理は困難を引き起こすかもしれません。数台のサーバーから数十台のサーバーを移行対象としている移行プロジェクトでは、これは現実的な問題になります。100台以上のサーバーを対象とする大規模な移行では、Cloud Migration Factory on AWS（AWS CMF）のようなスケーラブルな移行オーケストレーションソリューションの導入も検討ください。AWS CMFでは、AWS コンソールでターゲットサーバーの設定を管理する必要はありません。大規模移行のベストプラクティスの詳細については、Strategy and best practices for AWS large migrations – AWS Prescriptive Guidanceをご参照ください。

このブログ記事では、AWSコンソールで直接管理する移行プロジェクトにおいて、その規模に関わらず、複数の将来（移行後）の状態の構成情報を管理するという課題の解決に焦点を当てます。一般的な起動設定とEC2起動テンプレートの設定の両方の管理を自動化するための3つの異なるオプションをご紹介します：

• オプション1：AWS MGNサービスの新機能である起動テンプレート（AWSの最新情報の投稿およびAWS MGNリリースノートに記載）を使用する方式です。アカウント/リージョンレベルでデフォルトの構成情報を設定し、移行用に追加されるすべての新しいソースサーバーに使用される共通のテンプレートとします。
• オプション2：ターゲットサーバーの設定をスクリプトで管理する方式です。サーバー間でテンプレートをコピーすることや、1つのテンプレートからいくつかのパラメーターを他のテンプレートにクローンすることができます（例：ターゲットのサブネットID、セキュリティグループID、インスタンスタイプの変更など）。
• オプション3：検出・評価フェーズで用意したデータを用いて、CSVファイルからスクリプトで対象サーバーの全構成情報をインポートする方式です。

これらのオプションは、移行シナリオに応じて、それぞれ単独で、または組み合わせて使用することができます。以下では、さまざまなユースケースにおけるこれらのオプションの使用方法について説明します。

ソリューションの概要

一般的な起動設定とEC2起動テンプレートは、インスタンスタイプ、ボリュームタイプ、セキュリティグループ、ターゲットを起動するサブネットなど、起動するサーバーの構成を決定します。AWS MGNの新しい起動テンプレート機能は、一般的な起動設定とEC2起動テンプレートの両方の設定にアカウント/リージョンレベルのデフォルト設定を使用することで、前述の問題を簡素化し、手動での誤設定を防止するのに役立ちます。

移行したすべてのサーバーに同じ値を設定するデフォルトの起動テンプレートに加え、サーバーごとの個別設定を自動化するための2つのスクリプトを提供します：

• 選択したサーバー群のサブセットまたは個々のサーバーに対してこれらのパラメーターをさらに微調整する管理スクリプト（「オプション2 – スクリプトによる一般設定とEC2起動テンプレートの管理」の項を参照）。
• 1つのCSVファイルからすべてのターゲットサーバーの構成情報を一度に設定するインポートスクリプト（「オプション3 – 一般設定とEC2起動テンプレートのパラメーターをCSVファイルからインポートする」の項を参照）。

オプション１ – AWS MGN デフォルト起動テンプレート

re:Invent 2022でAWSは、AWSアカウント/リージョンレベルでターゲットサーバーのデフォルトパラメータを構成できる起動テンプレート機能の提供を発表しました。以下の例では、同じアプリケーションの一部である2つのサーバーをレプリケートしています。これらのサーバーはCPU/RAMパラメーターが異なっていたり、異なるインスタンスタイプを必要とするかもしれませんが、ターゲットサブネットID、セキュリティグループID、EBSボリュームタイプ、ライセンスタイプ、およびライトサイジング推奨事項などの他のパラメーターは、通常複数のサーバー間で同じままであり、移行開始前にデフォルト値に設定される必要があります。AWS MGNコンソールに追加された新しいソースサーバーは、まずアカウント/リージョンレベルのデフォルトテンプレートから設定を継承し、その後、サーバーごとに個別に調整することができます。

新しいデフォルトの “起動テンプレート” セクションにアクセスするには、AWS MGN コンソールにアクセスし、左側のナビゲーションメニューから “起動テンプレート” を選択します（アカウント/リージョンに AWS MGN が設定されていない場合は、最初に “使用を開始” ボタンを押してください）。AWS MGNサービスの初期化および設定方法の詳細については、以下のブログ記事のいずれかを参照してください：

• Accelerate your Migration with AWS Application Migration Service
• How to Use the New AWS Application Migration Service for Lift-and-Shift Migrations

起動テンプレート画面（図1参照）の「編集」をクリックします。

図 1. AWS MGNデフォルト設定 – 起動テンプレート

ここでは、デフォルトのパラメータを設定することができるいくつかのセクションを見ることができます：

• 一般的な起動設定（図2参照）
• デフォルトのEC2起動テンプレート（図3参照）
• MAPプログラムのタグ付け（図4参照）

図 2. AWS MGNのデフォルト設定 – 一般的な起動設定

図 3. AWS MGNのデフォルト設定 – デフォルトのEC2起動テンプレート

図4. AWS MGN デフォルト設定 – MAPプログラムのタグ付け

なお、AWS MGNでこのページの「EC2起動テンプレート」セクションで指定したデフォルトインスタンスタイプを使用するためには、「一般的な起動設定」セクションの「インスタンスタイプの適切なサイズ設定を起動」（図2のように）のチェックも外しておく必要があります。

テンプレートを保存すると、AWS MGNサービスに追加された新しいサーバーは、先ほど設定したテンプレートのデフォルト値を使用することになります。AWS MGNサービスは、このアップデートを行う前にソースサーバーのリストに既に追加されていたサーバーについては、これらのパラメーターを変更しません。これは、一定のベースラインを提供し、同じパラメーターを利用する類似のワークロードをひとつの移行ウェーブにグループ化し、次のような反復的なアプローチを可能にします：

1. 類似のターゲット構成を持つサーバー群の移行ウェーブを定義します。
2. その移行ウェーブのためのデフォルトの起動テンプレート設定を作成します。
3. 移行します（ソースサーバーをAWS MGNコンソールに追加し、移行ライフサイクルを実行する）。
4. 次のサーバー群に移動してこれを繰り返します。

しかし、個々のサーバーの設定を変更する必要がある場合は、AWS MGN コンソールの 「ソースサーバー」 メニューに移動し、設定を変更するサーバー名を選択し、以下の図 5 に示すように 「起動設定」 タブを開いて変更することができます。ここで行われた変更は、この特定のソースサーバーと、テストまたはカットオーバーインスタンスの起動時に使用される将来（移行後）の状態の構成にのみ影響します。

図 5. AWS MGN 個別ソースサーバー 起動設定

オプション2 – スクリプトによる一般的な起動設定とEC2起動テンプレートの管理

デフォルトの起動テンプレートを使用することで、すべての新規サーバーに標準テンプレートを設定することができますが、個々のサーバーの起動テンプレートをさらにカスタマイズする必要がある場合も多くあります。このような場合、次のようなシナリオが考えられます。

1. テスト起動の完了後にターゲットサブネットやセキュリティグループを変更し、カットオーバー起動時には異なる設定を使用します。
2. 同じ移行ウェーブ内のサーバーのサブセットに対して、サブネットまたはセキュリティグループを変更します。これには、アプリケーションサーバーをパブリックサブネットに移行し、データベースサーバーをプライベートサブネットに移行する必要がある場合、または同じアプリケーションの異なるコンポーネントごとに異なるプライベートサブネットを使用する必要がある場合などがあります。また、データベースサーバーなどに特定のインスタンスタイプを割り当てる必要がある場合にも使用できます。

そのような場合、2つの選択肢があります：

• AWS MGNのソースサーバーに既に追加されたものを使用し、AWS MGNコンソール内でこの個々のソースサーバーの起動設定（「一般的な起動設定」と「EC2起動テンプレート」の両方）を構成します。
• EC2コンソールで、新しいEC2起動テンプレートをゼロから作成し、将来移行するサーバーの「テンプレート」として使用します。これにより、新しいサーバーをAWS MGNコンソールに追加した後、以下のCLIスクリプトを使って、特定のパラメーターを新しいソースサーバーのEC2起動テンプレートにコピーできます。

このCLIのpythonスクリプト（こちらから入手可能）では、パラメーターのコピー元の「ソース」としてこの2つのオプションのどちらかを指定することで、AWS MGNでレプリケートするサーバー群に適用することができます。 以下、2つの例で説明します。

例１ – 既存のソースサーバーのテンプレートからコピーする場合

この例では、3台のアプリケーションサーバーと3台のデータベースサーバーがAWS MGNでレプリケーションされています。アプリサーバーs-App1とデータベースサーバーs-DB1に対してEC2起動テンプレートを定義しています。サーバーs-App1は、サブネット「public-subnet-1」、セキュリティグループ「public-SG-1」を使用します。同様に、サーバーs-DB1は、サブネット「private-subnet-1」とセキュリティグループ「DB-SG-1」を使用します。

そこで、サーバーs-App1のEC2起動テンプレートを、他の2つのアプリサーバーs-App2、s-App3にコピーします。また、2台のDBサーバーであるs-DB2とs-DB3については、サーバーs-DB1からEC2起動テンプレートをコピーすることにします。これは、以下のCLIコマンドを実行することで実現できます。

python target-templates-update –target s-App2,s-App3 –source-server s-App1

python target-templates-update –target s-DB2,s-DB3 –source-server s-DB1

注：上記の例では、異なるサーバーを区別するためにs-App1、s-DB1を使っています。AWS MGNにおける実際のサーバーIDは、s-0123456789abcdfaの形式です。

ここでは、私たちのアカウントで、3つ目のサーバーをベースに2つのサーバーのテンプレートを更新したサンプル実行を紹介します。

図6. 1台のソースサーバーから2台のターゲットサーバーに設定を複製する「target-templates-update」スクリプトの一例

例2 – 既存のEC2起動テンプレートからコピーする場合

この例では、アプリケーションサーバーの設定を定義するEC2起動テンプレートlt-a1b2c3097ecb147e2を構成してあります。以下のコマンドを実行すると、このソーステンプレートに基づいて3台のアプリケーションサーバーすべてのターゲットサーバー設定を更新することができます：

python target-templates-update –target s-App1,s-App2,s-App3 –template-id lt-a1b2c3097ecb147e2

上記の例と同様に、起動テンプレートlt-a1b2c3097ecb147e2から「サブネットID」と「インスタンスタイプ」のみを更新し、これらの変更をサーバーs-App1、s-App2、およびs-App3に適用する必要があるかもしれません。これは、以下のコマンドを実行することで実現できます：

python target-templates-update –target s-App1,s-App2,s-App3 –template-id lt-a1b2c3097ecb147e2 –parameters SubnetId,InstanceType

上記のコマンドで指定できる他のパラメータは、AssociatePublicIpAddress、DeleteOnTermination、Groups、Tenancy、IamInstanceProfileです。これらはすべて、--parameter引数に「カンマ区切り」で渡されます。--parameter引数が指定されない場合、上記のすべてのパラメーターがコピーされます。

また、--copy-launch-settingsを指定すると、ソースサーバーが指定されている場合、一般的な起動設定もコピーされます。また、--launch-settings-file launch_configuration.json（”launch_configuration.json “は入力ファイル）を使用して、一般的な起動設定のjsonファイルを渡すこともできます。

オプション3 – CSVファイルから一般的な起動設定とEC2起動テンプレートのパラメーターをインポート

どのような移行（中規模または大規模）でも、移行ジャーニーの3つのフェーズ（アセス、モビライズ、マイグレート＆モダナイズ）を通り抜けます。移行ジャーニーのフェーズについて詳しくは、こちらの規範的ガイダンスのドキュメントをお読みください。アセスフェーズでは、移行のためのビジネスケースを構築し、移行の対象範囲内のポートフォリオとサーバーインベントリーを分析します。お客様は多くの場合、既存の構成管理データベース（CMDB）またはディスカバリー＆アセスメントツールを使用して、移行の対象範囲となるITランドスケープのインベントリを構築します。CMDBやディスカバリー＆アセスメントツールからのこれらの出力は、多くの場合、CSVファイルで提供されます。

以下のソリューションは、AWS MGNを用いてサーバーをリホストするために、CSVファイルから取得するこのインベントリデータを使用することに焦点を当てています。CSVファイルを特定の形式の標準のフラットファイル（sample_template.csv）に変換する必要があるかもしれません。これを使用して各ソースマシンの一般的な起動設定とEC2起動テンプレートを自動化します。sample_template.csvは、以下のようなファイルです。

図7. 特定のインポート形式でのフラットCSVファイルの例

このフラットなCSVファイルを更新する際には、いくつかのルールに従う必要があります。例えば、ターゲットサーバーに複数のネットワークインターフェイスを追加し、それぞれに適したサブネットとセキュリティグループを選択する場合、以下のようにネットワークデバイスのインデックスと対応するサブネットまたはセキュリティグループをCSVファイルに指定する必要があります：

• Subnet_ID列：0:subnet-xxxxxxxx,1:subnet-yyyyyyyy
• Security_Groups列：0:sg-xxxxxxxx,1:sg-yyyyyyy

注：上記の’0’と’1’は、ネットワークインターフェイスのネットワークデバイス・インデックスを示します。

csvファイルの更新方法とスクリプトの実行方法については、こちらのコードの「Readme」セクションをお読みください。

sample_template.csvファイルの更新が完了すると、スクリプト”target-templates-import.py“を実行する準備の完了です。このスクリプトは、CSVファイルを読み込み、下図のように各ソースマシンのAWS MGN の一般的起動設定とEC2起動テンプレートのパラメーターを更新してくれます。

図8.target-templates-importスクリプトで3台のターゲットサーバーの設定を更新した例

まとめ

本ブログでは、AWS MGNによるリホスト移行時にターゲットインスタンスの大規模な構成を管理するというお客様が直面する極めて一般的な課題に対する3つの選択肢を紹介しました。

ご紹介した3つのソリューションにより以下のようなスケーラブルなアプローチが可能となりました。

• AWS MGNデフォルト起動テンプレート機能を使用して、移行ウェーブごとにデフォルト値を設定します。
• テストやカットオーバーフェーズにおいて、将来（移行後）のサーバー構成を管理し、微調整を行います。
• アセスメントツールの出力をもとに、CSVファイルから同一移行ウェーブ内の全サーバーのターゲット構成情報を一括設定します。

以上のアプローチにより、お客様はAWS MGNを利用したリホスト移行時の手作業や設定ミスの可能性を大幅に削減し、結果的にAWSへのリホスト移行を加速させることが可能となります。

著者について

Mike Kuznetsov

Habeeb Al Aidroos

Habeeb Al Aidroosは、エンタープライズの移行を専門とするソリューションアーキテクトです。エンタープライズのお客様と密接に連携し、お客様ごとの移行課題を理解し、移行目標の達成を支援しています。お客様と仕事をしていないときは、家族と過ごすのが好きです。