AWS Application Migration Service (AWS MGN) は、 AWS へのリホスト移行のための推奨サービスとして位置付けられて以来、お客様のニーズに応えるべく、驚異的な速さで新機能のリリース、複数の機能強化、継続的なイノベーションが行われてきました。

AWS Application Migration Service (AWS MGN) は、高度に自動化されたリフト&シフト(リホスト)のためのソリューションであり、アプリケーションを AWS に移行する作業を簡略化、迅速化、そして削減します。これにより企業は、互換性の問題、パフォーマンスの低下、長いカットオーバーの期間なしに、多数の物理、仮想、またはクラウドのサーバーを移行できます。AWS MGN はソースサーバーを AWS アカウントにレプリケートします。移行の準備が整うと、サーバーを自動的に変換して AWS 上で起動するので、クラウドのコスト削減、生産性、耐障害性、俊敏性をすぐに活用できます。アプリケーションを AWS で起動できれば、その後は AWS のサービスと機能を活用してそれらのアプリケーションをリプラットフォームやリファクタリングすることができます。つまり、リホストはモダナイゼーションへの近道となります。AWS MGN は AWS のすべてのお客様とパートナーが利用できます。

ワークロードを AWS クラウドに正常に移行する際には、これらのワークロードがセキュリティとコンプライアンスのベストプラクティス/フレームワークを満たしていることを確認することも重要です。

そのため、組織にとって、脆弱性が顕在化する前に、アプリケーションの保守とパッチを予定どおりに実施することが重要です。

過去 2 年間に何らかのデータ侵害を経験した組織は 48% と推定されています。侵害の被害者の 60% は、パッチが適用されていない既知の脆弱性が原因で侵害されたと答えています。

企業はパッチ管理に関して大きな課題に直面しています。ITとセキュリティの専門家はパッチが複雑で時間がかかると感じています。ビジネスユニットのリーダーは、リリース後すぐにパッチを適用するとアプリケーションの機能が損なわれてしまうことを恐れることがよくあります。さらに、これらの脆弱性の修正は、移行または変革の過程にあるワークロードで行う必要があります。

この記事では、AWS MGN のウェーブと、起動後のアクションを使用して AWS への移行中にインスタンスへのパッチ適用を自動化することで、これらの課題にどのように対処できるかを見ていきます。

準備

このチュートリアルでは、次の前提条件を満たす必要があります。

・AWS アカウントをお持ちであること
・利用するサービスに対する十分な権限を持つIAMユーザーが利用できること
・「チュートリアル – 使用サービス」のセクションに記載されているサービスの操作経験(*)。

* AWSアカウントをご用意いただき、Migration Immersion Day ワークショップを実施いただくことがお勧めです。日本語の説明で、手順を順々に理解いただけるようになっています。

チュートリアル

AWS MGN と AWS Systems Manager を使用してクラウドジャーニーを始めましょう。

ソリューション概要

AWS MGNの機能であるウェーブを使い、ソースサーバーとアプリケーションをグループ化することでユーザーが移行を管理できるようにします。このウェーブを利用することで、移行ステータス、進捗状況、ウェーブに含めたアプリケーションを監視できますし、一括操作を実行することもできます。

また、AWS MGN の機能である起動後アクションを使い、任意の AWS Systems Manager ドキュメントを実行して、カスタムの最新化アクションを適用してアプリケーションを最適化することができます。起動後アクションを使うと、クロスリージョンDR構成や、CentOSの変換、SUSE Linuxのサブスクリプションの変換といった組み込みアクションを選択することもできます。

AWS Systems Manager パッチマネージャー は AWS Systems Manager の機能で、セキュリティ関連やその他種類のアップデートについて、管理対象ノードにパッチを適用するプロセスを自動化します。パッチマネージャーを使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用できます。

図 1 – ソリューションのアーキテクチャ図

1. AWS MGN の起動後アクションで AWS Systems Manager オートメーションを呼び出してインスタンスにパッチを適用

2. アプリケーションとインスタンスのパッチコンプライアンスを検証

3. カットオーバーを完了し、移行作業を完了する

1) AWS MGN の起動後アクションを作成する

起動後アクションの設定により、サーバーが AWS で起動された後に実行されるアクションを制御と自動化を行えます。これらのアクションは、起動後テンプレートに基づいて自動的に実行されます。このセクションでは、カスタムアクションを定義し、それを実行するように AWS MGN を設定します。独自の移行プロジェクトでは、必要に応じてさまざまなアクションを実行することができます。

起動後のアクションの設定には 2 つのオプションがあり、起動後テンプレートで新しいアクションを定義することも、サーバーレベルで起動後設定を構成することもできます。起動後テンプレートを設定すると、変更 (新しいアクションを含む) は変更後に追加されたサーバーにのみ適用され、既存のサーバーには適用されません。また、サーバーレベルで設定を行う場合は、ソースサーバーごとにアクションを手動で設定する必要があります。

サーバーにエージェントをインストールする前に、アカウントレベルの起動後テンプレートで新しいアクションを定義することをお勧めします。テンプレートを設定したら、ソースサーバーにエージェントをインストールしてレプリケーションを開始します。これにより、すべてのソースサーバーがアカウントレベルのテンプレートのデフォルト設定を継承します。

1.左側のナビゲーションメニューから[起動後テンプレート]を選択します。

2.[編集]をクリックします。

3.[Systems Manager エージェントをインストールし、起動したサーバーでのアクションの実行を許可する]のトグルボタンをオンにします。これにより、AWS MGN は移行ウェーブに属するサーバーに AWS Systems Manager エージェントを自動的にインストールできます。

図 2 – 起動後テンプレートの設定

4. 起動させるインスタンスで実行したいアクションを追加します。

これを実現するために、Systems Manager オートメーション ランブックを使用して新しいアクションを作成します。このアクションにより、該当するパッチベースラインが適用されます。処理途中で障害が発生した場合は、ルートボリュームは自動的にソースサーバーの状態にロールバックされます。

アクションに名前を付け、オートメーション ランブック AWS-PatchInstanceWithRollback を選択します。このアクションを有効化するには、チェックボックスをチェックをしてください。[順序]フィールドに数値を入力して、その他の一緒に実行するカスタムアクションや定義済みアクションとの順序を設定します。

図 3 – 起動させるインスタンスで実行するアクションの追加

2) サーバーのグループを定義し、それらをアプリケーションに関連付ける

起動したインスタンスで実行されるアクションを定義したので、次は、同時に起動させるインスタンスのグループを定義します。

AWS MGN では、ソースサーバーをアプリケーションにグループ化し、アプリケーションをウェーブにグループ化する機能があります。

アプリケーションとは、ビジネスニーズを満たすために連携して機能するサーバーのグループです。サーバーは連携して動作し、ネットワークを共有し、機能を正しく動作させるために必要であるため、サーバー間には依存関係があります。たとえば、データベース、いくつかの Web サーバー、そして計算を実行するバックエンドサーバーがある大規模なアプリケーションです。アプリケーションを本番環境で完全に機能させるには、これらのサーバーをすべてまとめて移行する必要があります。

ウェーブは、指定された期間内にまとめて移行できるように設計されたアプリケーションのグループです。これは移行プロジェクト計画の一環として決定されます。移行中のさまざまなアプリケーション間に必ずしも依存関係があるわけではありません。グループ分けはお客様の移行ニーズに基づいて行われます。移行プロセスから学び、改善するために、優先度の低いアプリケーションをすべてグループ化し、優先度の高いアプリケーションを別のウェーブにまとめても構いません。あるいは、特定のビジネスユニット (マーケティングなど) のすべてのアプリケーションを 1 つのウェーブにグループ化してから、営業アプリケーションなどの次のウェーブに移るといったこともできます。ビジネスニーズに基づいて、移行ウェーブを計画し、アプリケーションをウェーブに割り当てる方法を選択できます。

AWS MGN では、アプリケーションとウェーブのどちらについても、移行プロセスを集約してモニタリングできるほか、アプリケーションやウェーブに含まれるすべてのリソースに対して一括アクションを実行できます。

1.左側のナビゲーションメニューから [アプリケーション] を選択します。

2.アプリケーションにサーバーを追加します。

図 4 – アプリケーションへのサーバーの追加

3) アプリケーションをウェーブに追加する

図 5 – ウェーブへのアプリケーションの追加

ウェーブを作成してすべてのアプリケーションを追加したら、テストインスタンスを起動する準備が整いました。カットオーバーを開始する前に、ソースサーバーの AWS への移行をテストすることが重要です。

4) 移行インスタンスを起動し、移行ジョブを監視する

テストインスタンスを起動をクリックし、テストインスタンスを起動したら、移行ダッシュボードをモニタリングします。最も重要な点は、ステップ 1 で設定した起動後のアクションが正常にトリガーされたことを確認することです。

図 6 – 起動後アクションの実行の確認

上記の例では、起動後アクションが開始され、Wave1 を構成するすべてのインスタンスにパッチを適用する AWS Systems Manager オートメーションが正常に終了しました。これで、アプリケーションの機能を検証し、すべてが期待どおりに動作していることを確認する準備ができました。

5) インスタンスのコンプライアンス状態の検証

1. AWS Systems Manager>パッチマネージャーに移動します。
2. コンプライアンスレポートのタブで、ウェーブに追加したサーバーが準拠状態になっていることを確認できるはずです。

図 7 – サーバーのコンプライアンス状態の確認

コンプライアンスは AWS Systems Managerの機能であり、パッチマネージャーでパッチ適用状況に関するデータを収集して報告します。パッチコンプライアンスの詳細については、設定コンプライアンスの使用を参照してください。

パッチベースラインにより、パッチマネージャーを使用する際に、ご使用の環境でどのパッチが承認または却下されるかをより細かく制御できます。これらの定義済みベースラインは、現在設定されているとおりに使用することも、独自のパッチベースラインを設定することもできます。詳細については、事前定義されたパッチベースラインおよびカスタムパッチベースラインについてを参照してください。

6) カットオーバーインスタンスを起動して移行を完了する

すべてのソースサーバーとアプリケーションのテストが完了したら、①カットオーバーインスタンスの起動と、②カットオーバーの完了を行う準備が整います。カットオーバーは、設定した日時に実行する必要があります。カットオーバーにより、ソースサーバーは、パッチがすでにインストールされていてインスタンスが準拠状態にある AWS 上のカットオーバーインスタンスに移行されます。

図 8 – カットオーバーインスタンスの起動と完了

まとめ

多くの企業にて、アプリケーションのセキュリティとコンプライアンスを強化する方法を模索されている中、パッチ管理は複雑で時間がかかり、複数の利害関係者の事前検証と事後の検証が必要とします。移行を完了すると同時にコンプライアンスを確保するためのメンテナンス期間が限られているため、これらの課題はさらに大きくなります。

この記事では、AWS MGN の起動後アクションと AWS Systems Manager パッチマネージャー/オートメーションを利用することで、移行の期間を活用したパッチの適用を自動化し、ワークロードを順守し続ける方法について記載しました。

翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文はこちらです。