Amazon Web Services ブログ

AWS MGN の起動後アクションを活用してブルー/グリーンデプロイを促進する

本記事は 2024年1月4日に公開された ”Accelerating Blue/Green Deployments with AWS MGN Post-Launch Actions” を翻訳したものです。

多くのお客様においてクラウド適用への方向転換が進んでおり、AWS に移行することによるメリットの認識が高まっています。IDC が発表したホワイトペーパーには、AWS に移行したお客様は、運用コストを 51% 削減し、IT スタッフの生産性を 62% 向上させ、ダウンタイムを 94% 削減できるという数字がでています。このような状況の中、AWS は 2008 年以来、様々な組織におけるワークロードのクラウド移行を支援してきました。これは他のどのクラウドプロバイダーよりも長い実績であり、その中で多くのことを学びました。トレーニングや認定などの組織的な側面から、開発者が新しいサービスの使用方法を学ぶなどの技術的なハードルまで、AWS は移行における様々な障壁を軽減するために大きな進歩を続けています。

このブログでは、ブルー/グリーンデプロイの実装にフォーカスを当てた、合理的かつ効率的なサーバー移行プロセスに触れていきます。特にオンプレミス環境からクラウドへのサーバーの移行は複雑で時間がかかり、エラーが発生しやすい場合があります。従来の移行アプローチでは、多くの場合、古い環境と新しい環境をシームレスに切り替える柔軟性が欠けています。そこで、AWS Application Migration Service (AWS MGN) と、それに関連する AWS サービスを中心に、ブルー/グリーンデプロイの原則を取り入れながら、移行プロセスをシンプルに、そして迅速化することを狙います。自動化とカスタマイズされた移行後アクションを活用することで、オペレーション負担が軽減され、ダウンタイムが最小限に抑えられ、AWS へのシームレスな移行が可能になります。これにより、企業はインフラストラクチャをモダナイズし、ブルー/グリーンデプロイを採用できるようになり、アプリケーションやサービスを安全で効率的に更新することができるようになります。

ソリューションの概要

このブログでは、主に Application Migration Service (AWS MGN) で作業し、サーバー移行のライフサイクルと MGN の起動後アクション機能に焦点を当てます。このソリューションでは、2 つのサーバーをブルー (移行元) バージョンとグリーン (移行先) バージョンとします。そして、2 つのリージョンで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してブルーからグリーンに移行する方法を示します。データセンターの既存のサーバーや別クラウドをソースインスタンスとして使用することもできます。

グリーン (移行先) バージョンのテストサーバーに AWS Systems Manager (SSM) エージェントが自動的にインストールされるよう MGN コンソールで起動後アクション機能を有効化します。次に、ブルー (移行元) バージョンのインスタンスに MGN レプリケーションエージェントをインストールし、初期同期が完了したら、Amazon Elastic Compute Cloud (Amazon EC2) を使用してグリーン (移行先) バージョンの MGN テストインスタンスを起動します。テストフェーズでは、AWS のサービスや機能をグリーン (移行先) バージョンのインスタンスにアタッチし、AWS 上に構築することの利点を確かめます。テスト完了後は、MGN を用いてカットオーバーのプロセスにシームレスに進めたり、必要に応じて1つ前のプロセスに戻したりすることができます。

当シリーズのパート 2 では、このブログの内容を基に、カスタマイズした起動後アクションを作成したり、AWS の Generative AI サービスの 1 つである Amazon CodeWhisperer を利用したboto3 Python スクリプトの作成について記載します。これらを活用すれば、反復可能な移行プロセスの実現に向けて、ニーズに合わせたカスタマイズが可能となります。

ターゲットアーキテクチャ

次の図は、当ソリューションのアーキテクチャを示しています。

図 1: 提案する MGN ブルー/グリーンテストソリューションのアーキテクチャ

  1. MGN 起動後アクションのセットアップ
  2. MGN 起動後アクションの選択と設定
  3. MGN 起動後アクション設定の完了
  4. ブルー (移行元) バージョンのインスタンスの状態確認
  5. ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール
  6. 移行状態の確認
  7. Amazon Route 53 で DNS ルーティングを更新

詳しい説明

1. MGN 起動後アクションのセットアップ

最初のパートでは、MGN で起動後アクションを使用可能にするために必要となる初期設定について説明します。

図 2: MGN 起動後テンプレート

AWS コンソールを開き、グリーン (移行先) バージョンのインスタンスを起動するリージョンを選択します。MGN を検索してサービスを開き、左側のタスクバーの [設定] で [起動後アクション] を選択します。[編集] を選択し、Systems Manager エージェントのインストールをトグルで有効化し、希望するデプロイオプションを選択します。

2. MGN 起動後アクションの選択と設定

次に起動後アクションの選択と設定を行います。

図 3: MGN 起動後アクションの選択と設定

選択できる事前定義済みの起動後アクションは多数あります。まず、リストから希望のアクションを選択し、カードビューの横にある [編集] を選択します。これにより、選択したアクションを設定してアクティブ化できます。このデモでは、「Create AMI from Instance」を使用し、グリーン (移行先) バージョンのインスタンスから AMI を作成する処理を自動化します。

図 4: Systems Manager 向けの IAM ロールを選択

必要に応じて Systems Manager 向けに新しい IAM ロールを作成して、AWS アカウント内のアクセスと権限を制御します。Systems Manager 向けのロールを作成する方法の詳細については、AWS Systems Manager のドキュメントを参照してください。

3. 起動後アクション設定の完了

機能が正常に設定され有効化されたことを確認して、起動後アクションの設定を完了します。定義済みのアクションの編集プロセスが完了したら、[アクションを保存] を選択します。カードビューで新しいアクションを見つけ結果を確認することで、このプロセスが正常に終了したことを確認できます。なお、グリーン (移行先) バージョンのテストインスタンス起動後に取得された AMI を見つけることで正常に処理されたことを再確認できます。

4. ブルー (移行元) バージョンのインスタンスの状態確認

次に、ブルー (移行元) バージョンのインスタンスの状態を確認します。

図 5: AWS コンソールでブルー (移行元) バージョンの Amazon EC2 インスタンスを確認する

EC2 のマネージメントコンソールのダッシュボードで、ブルー (移行元) バージョンの Amazon EC2 インスタンスの情報を確認できます。このブログの設定では Amazon EC2 インスタンスには、Apache Web Server、PHP、および MariaDB がインストールされています。

データベースエンドポイントは事前設定済みで、WordPress 経由のサンプル Web ページが作成されており、後工程にて、ブルー (移行元) バージョン側の変更をグリーン（移行先）バージョンに反映させる流れを検証します。
　

図 6: SSH 経由でブルー (移行元) バージョンのインスタンスに接続 — 接続方法を EC2 のマネージメントコンソールにて確認

SSH 経由でインスタンスに接続し、必要な依存関係がインストールされていることを確認します。ブルー (移行元) バージョンのインスタンスで実行されている WordPress サイトにアクセスし、現状の表示内容を確認します。

EC2 のパブリック IPv4 アドレスにアクセスすると、WordPressサイトのブルー (移行元) バージョンが表示されます。

図 7: 移行の対象となるサンプル Web アプリケーションのブルー (移行元) バージョン

5. ブルー (移行元) バージョンのインスタンスへの MGN エージェントのインストール

次に MGN エージェントをインストールし、移行を開始します。

図 8: MGN コンソール内の MGN レプリケーションエージェントのインストール手順

AWS コンソールで MGN サービスを開き、[ソースサーバーへの移動] → [サーバーの追加] → 表示されるプロンプトの入力を完了すると、インストーラーのダウンロードとインストールのためのコマンドが生成されるため、コピー＆ペーストしてソースサーバー (ブルーバージョン) に MGN レプリケーションエージェントをインストールします。

図 9: MGN レプリケーションエージェントのインストールの成功メッセージ

図 10: MGN コンソール、移行元サーバーの状態を表す移行メトリクス

MGN のダッシュボードには、サーバー移行に関連するメトリクスが表示されます。

図 11: MGN のデータレプリケーションの状態

MGN レプリケーションの詳細な動作状況については、MGN コンソールの [ソースサーバー] でソースサーバー名を選択し、[イベントとメトリクス] → [AWS CloudTrail イベント履歴を表示] までスクロールすることで見れます。

図 12: MGN サーバー移行のライフサイクルはテストの準備完了を示している

ネットワーク帯域幅の計算ツールを使えば、初回のレプリケーションが完了するまでの待ち時間を見積もることができます。レプリケーションが完了すると、グリーン (移行先) バージョンとなるテストインスタンスを起動できます。

では、MGN コンソールからテストインスタンスを起動しましょう。

図 13: [テストおよびカットオーバー]のドロップダウンからのテストインスタンスを起動

[テストインスタンスを起動] を選択します。MGN ライフサイクルプロセスが「テストの準備完了」から「テストが進行中」に移行します。

図 14: MGN により Amazon EC2 の変換サーバーが自動的にプロビジョニングされる

MGN により自動的にプロビジョニングされた変換サーバーが Amazon EC2 のコンソールに表示されます。これにより、グリーン (移行先) バージョンのテストインスタンスが生成されます。

しばらくすると、ローンチの準備が整います。MGN のライフサイクルプロセスで、起動後アクションのステータスが「進行中」であることを確認する必要があります。もしそうでない場合は、ソースサーバー内の[起動後設定]タブを選択して、アクションが設定されていることを確認してください。Amazon EC2 コンソールに戻り、新しく起動したグリーン (移行先) バージョンのテストインスタンスを確認します。

図 15: 起動後アクションが実行され MGN テストインスタンスとして起動されたグリーン (移行先) バージョンのインスタンス

図 16: グリーン (移行先) バージョンのテストインスタンスのパブリック IP を開く

６. 移行状態の確認

MGN エージェントにより移行が正常に行われていることを確認した上で、MGN の継続的なレプリケーション機能も見ていきます。

グリーン (移行先) バージョンのテストインスタンスが起動したため、いくつかのテストを実行します。インスタンスへのトラフィックのルーティング、同時アクセス、加重ルーティングの実行、自動スケーリンググループによるスケールアップまたはスケールダウンの試行、そして、さまざまなサービスや機能のアタッチなどが考えられます。これは例えば、Elastic IP、ターゲットグループ、ロードバランサーを追加し、セキュリティグループを更新してインスタンスに安全にアクセスできるようにしてみるといった内容です。

次に、ブルー (移行元) バージョンを更新して、MGN がデータを継続的にレプリケーションしていることを確認してみます。ブルー (移行元) バージョンのウェブアプリにログインし、テキストを「Blue」から「Green」に変更してみます。

図 17: ブルー (移行元) バージョンのインスタンスのウェブアプリ UI の変更

MGN の継続的なレプリケーション機能によるレプリケーションが完了した後にグリーン (移行先) バージョンのインスタンスを起動することで、ブルー (移行元) バージョンへの変更がグリーン (移行先) バージョンに自動的に反映されていることが確認できます。

図 18: グリーン (移行先) バージョンのインスタンスのパブリック IP を開く、ブルー (移行元) バージョンへの変更は、MGNの継続的なレプリケーション機能によって行われる

これでパート 1 は終わりです。パート 2 では、カスタマイズした起動後アクションや Amazon CodeWhisperer によるスクリプト作成など、テストと移行をより詳細に制御できるように新機能や複雑さを追加していきます。

図 19: 「カットオーバーの準備完了」に進める、または「テストの準備完了」に戻す

7. Amazon Route 53 で DNS ルーティングを更新

ブルー/グリーンデプロイメントにおいては、レコード更新による DNS ルーティングが一般的なアプローチとなります。ロールバック時に、必要に応じて DNS がブルー環境とグリーン環境の間でトラフィックを切り替える必要があります。DNS ホストゾーンを Amazon Route 53 で管理していると、エイリアスレコードを更新し、トラフィックをブルー環境からグリーン環境に誘導できます。

以下の図は、Amazon Route 53 が DNS ホストゾーンを管理する方法を示しています。エイリアスレコードを更新することで、トラフィックをブルー環境からグリーン環境に誘導できます。

図 20: 一般的な移行 — ブルー/グリーンデプロイでの Amazon Route 53 の DNS 管理

あるいは、加重ルーティングを使用することもできます。Amazon Route 53 では、この方法により、グリーン環境に向けられたトラフィックの割合を定義できます。また、グリーン環境が本番トラフィックの負荷全体を処理するまで、重みを徐々に調整できる柔軟性も備えています。このアプローチにより、カナリアデプロイが容易になり、本番トラフィックのごく一部を新しい環境に導入してテストとエラー監視を行うことができます。問題が発生した場合に影響範囲を制限することができます。デプロイメントで問題が発生した場合は、DNS レコードを更新してトラフィックをブルー環境に戻すことでロールバックを実行できます。正式なカットオーバーが実行されるまで、トラフィックはブルー環境に戻されます。

図 21: 段階的な移行 — DNS 加重ルーティングを活用したデプロイの制御

クリーンアップ

このブログに関連する追加料金が発生しないように、次のようなリソースを必ずクリーンアップしてください。

  • EC2 インスタンス
  • すべての MGN ソースサーバーの切断
  • テストに関連するすべてのブロックストレージ、データベース、その他のストレージ

まとめ

このブログでは、AWS Application Migration Service を活用して ブルー/グリーンデプロイを実行する方法について説明しました。これには、Systems Manager を用いた事前定義済みの起動後アクションの利用も含まれます。また、異なるリージョンにある Amazon EC2 インスタンスを介して AWS への移行をシミュレートし、MGN の継続的なレプリケーション機能を検証しました。これをさらに一歩進め、実際のオンプレミスサーバーを用いてテスト移行を行うことは、このブログの内容の理解を深めるための優れた方法です。パート 2 では、カスタマイズした起動後アクションを使用する方法と、Amazon Generative AI 機能の 1 つである Amazon CodeWhisperer を活用して boto3 Python で移行スクリプトを記述する方法を説明します。

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