re:Invent 2025: Amazon ECSの安全で回復力のあるデプロイメントパイプライン構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Build safe and resilient deployment pipelines for Amazon ECS (CNS353)
この動画では、AWS ソリューションアーキテクトの Islam Mahgoub 氏が、Amazon ECS における安全で回復力のあるデプロイメント戦略について解説しています。ローリングアップデート戦略では、minimum healthy percent と maximum percent のパラメータを用いて、古いタスクを新しいタスクで段階的に置き換える方法を実演しています。Blue-Green デプロイメント戦略では、2つの並列環境を維持することで迅速なロールバックを実現し、test listener と production listener を分離してトラフィックを制御する仕組みを説明しています。さらに、ライフサイクルフックを使用した手動承認ワークフローの実装例も紹介され、post-test traffic shift ステージで Lambda 関数を呼び出してデプロイメントを一時停止する方法が示されています。各戦略のトレードオフとして、ローリングアップデートは容量効率が良い一方でロールバックに時間がかかり、Blue-Green は容量を多く使用するが迅速なロールバックが可能であることが強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Amazon ECS における安全で回復力のあるデプロイメント戦略の概要
こんにちは。このセッションにご参加いただきありがとうございます。多くの組織が Amazon を使ってコンテナベースのアプリケーションをホストしています。彼らの主要な要件の一つは、安全で回復力のある方法で新しいバージョンをロールアウトできることです。つまり、ダウンタイムなしでこれらのバージョンをデプロイしたいということですし、また問題が発見された場合には古いバージョンにロールバックできるようにしたいということです。このセッションでは、Amazon ECS で安全で回復力のある デプロイメントパイプラインを実装するために使用できるさまざまなデプロイメント戦略についてお話しします。そして、これらのさまざまな戦略と、それらを使ってこれらの回復力の要件に対処する方法を見ていきます。
私の名前は Islam Mahgoub です。AWS でソリューションアーキテクトとして働いており、またコンテナの主題専門家でもあります。 これが本日のアジェンダです。まずデプロイメントの簡単な概要から始めます。その後、ローリングアップデートデプロイメント戦略についてお話しします。次に blue-green デプロイメント戦略についてお話しし、最後にいくつかの重要なポイントでセッションを終了します。
では、まずデプロイメントの簡単な概要です。 サービスは task definition とサービス設定の組み合わせで定義されます。task definition は、実行したいコンテナイメージの詳細情報をキャプチャします。例えば、コンテナイメージの URL、ネットワーク設定、環境変数などです。初めてサービスを作成するとき、task definition とサービス設定が組み合わされて Service Revision 1 が作成されます。その後、新しいバージョンをデプロイしたい場合は、新しい task definition を作成します。この新しい task definition はサービス設定と組み合わされて Service Revision 2 になります。
Service Revision 1 から Service Revision 2 へと進むプロセスは、service deployment と呼ばれるオブジェクトに保持され、追跡されます。このオブジェクトには、デプロイメントの進捗、ソースリビジョン情報、ターゲットサービスリビジョン情報などの情報が含まれています。では、ローリングアップデートデプロイメント戦略について詳しく見てみましょう。 ダウンタイムなしで新しいバージョンをデプロイしたい場合、使用できるアプローチの一つは、古いバージョンを実行している既存のタスクを、新しいバージョンを実行している新しいタスクで段階的に置き換えることです。これが、私たちが rolling update デプロイメント戦略と呼ぶものです。
これが正しく機能するために設定する必要がある 2 つの重要なパラメータがあります。 これらは minimum healthy percent と maximum percent です。minimum healthy percent は、このデプロイメント中に持つことができるタスク数の下限を表します。これはサービスの可用性にとって本当に重要です。なぜなら、顧客にサービスを提供するために必要な数よりも少ないタスク数で実行したくないからです。maximum percent はサービスの下で持つことができるタスク数の上限を表します。これら 2 つのパラメータにより、デプロイメント中の可用性、デプロイメントの速度、コストの間で適切なバランスを取ることができます。
ローリングアップデートデプロイメント戦略の実装とデモンストレーション
仕組みとしては 最初に全てのタスクが古いバージョンで動いていて、その後徐々に新しいバージョンで動く新しいタスクを追加していき 古いバージョンで動いている古いタスクを終了していって、最終的にサービスの下で動いている全てのタスクが新しいバージョンで動いている状態になるまで進めていきます 。では実際にこれがどのように動作するのか見てみましょう。このアプリケーションを使います。これはサンプルの小売アプリケーションです 。これは1つの UI サービスで構成されていて、全てサービス上で動いており、4つのバックエンドサービスがあります。order、checkout、cart、catalog です。これらは全てマイクロサービスで、データベース用とマネージドキューイング用のマネージドサービスによってサポートされています。
では今このシナリオを見てみましょう。UI サービスの新しいバージョンをデプロイしたいです。これがダウンタイムなしで行われることを確認したいです。そのため rolling update デプロイメント戦略を使います。まず UI サービスを確認しましょう 。クラスターに行きます。クラスターの下には多くのサービスがあります。それについては後で説明します。サービスに行きます。ここでこのサービスがロードバランサーを通して公開されていて、全てのタスクが1つのターゲットグループの下に登録されているのが見えます。ここにターゲットグループの名前が見えます 。デプロイメントセクションに行くと、rolling update デプロイメント戦略が使われていることに気付きます。
では変更をプッシュしましょう。背景を変更するつもりです 。プッシュしてパイプラインを通してどのように進むのか見てみましょう。まずソースコードがチェックアウトされ 、コンテナイメージがビルドされてプッシュされ、その後デプロイメントステージに進みます。ここで新しいタスク定義を作成してサービスをこの新しいタスク定義を指すように更新します 。コンソールにジャンプして ECS でこれがどのように進行しているのか見てみましょう。タスクのデプロイメント状態が進行中で、新しいタスク定義を参照する新しいタスクが追加されているのが見えます 。さらに多くのタスクが追加されていて、右側ではブラウザがサービスのリスナーに接続されていて、新しい背景を表示し始めます 。これはトラフィックが新しいタスクに向かっているということです。しばらくすると、古いタスクが登録解除されて終了されるのに気付きます。これが rolling update デプロイメント戦略の仕組みで、ダウンタイムなしで完了したのが見えます 。
Blue-Green デプロイメント戦略による迅速なロールバックの実現
ここで注意すべき点は、前のバージョンにロールバックしたい場合、古いバージョンを実行するタスクを再プロビジョニングする必要があるため、少し時間がかかる可能性があるということです。素早くロールバックしたい場合は、実装したいかもしれない戦略の1つが blue-green デプロイメント戦略です。これは2つの並列環境を持つことを伴います。blue 環境と green 環境です。blue は古いバージョンで、green は新しいバージョンです。その後 blue から green に切り替えて、blue はまだ生きたままにしておきます。もし期待通りに動作していない場合は、再び blue 環境にロールバックできます。
では これがどのように動作するのか見てみましょう。最初のステージは古いバージョンで動いている元のタスクセットで始まります。その後スケーリングステージに進みます。スケーリングステージでは、新しいバージョンで動くタスクで green 環境をプロビジョニングしています。それでも、トラフィックは完全に古い、または元のタスクセット、つまり blue のものによってサービスされています 。その後テストトラフィックシフトステージに進みます。blue-green では、本番トラフィックをテストトラフィックから分離する能力があります。Application Load Balancer を使って公開されているサービスについて話している場合、できることは追加のリスナーを定義することです。追加のリスナーを作成してそれがテストリスナーになり、これは新しいバージョンをテストするため、または実際のトラフィックをシフトする前に、または本番リスナーをこの新しいバージョンを指すように変更する前に使用できます。
test traffic shift のステージでは、deployment controller の内部で何が起こるかというと、test listener が新しいバージョン、つまり green environment にトラフィックをルーティングするように変更されます。 その次の production traffic shift のステージでは、production listener がこの新しい green environment、つまり新しい tasks を指すように変更されます。 そして bake time ステージに到達します。このステージでは、2つの環境が保持されます。トラフィックは green、つまり新しい環境によって処理されますが、blue environment はまだそこにあります。もし何か問題が発見された場合は、ここにロールバックするか、トラフィックを blue environment に戻すことができます。このステージがどのくらい続くかを定義する能力があります。 bake time が経過すると、cleanup ステージに入り、このステージでは blue environment が終了され、green だけが残ります。green は次のデプロイの時に新しい blue になります。
これがどのように機能するかを見てみましょう。ここで取り上げるシナリオは、サービスの変更をデプロイすることです。今回は、もし物事がうまくいかなかった場合に素早くロールバックできるようにしたいです。最初に、サービスを blue-green deployment strategy を使用するように変更する必要があります。サービスに移動して update service をクリックします。その後、deployment options セクションに移動して blue-green strategy を選択します。 bake time を設定する必要があります。これはロールバックしたい場合に備えて blue environment を保持したい期間です。
その後、load balancing セクションで、 role を提供します。deployment controller が blue と green の間でトラフィックをシフトする方法は、listener rules を変更することなので、IAM パーミッションを持つ必要があります。必要なパーミッションを持つ IAM role を与えています。その後、production listener を選択し、 production listener rule を選択して、test listener と test listener rule についても同じことを行います。
blue-green deployment では、これら2つの環境、blue と green を保持しているので、1つだけではなく、それぞれに対して2つの target groups が必要です。 ここで追加の target group の詳細を提供する必要があります。その後、サービスを更新します。これはデプロイをトリガーし、このデプロイが完了すると、blue-green deployment strategy が有効になります。
blue-green strategy でこれがどのように機能するかを見るために、別の変更をプッシュします。 ステップは非常に似ていますが、デプロイメント ステージに到達すると、右側に2つのブラウザ ウィンドウがあります。1つは上部の production listener に接続されており、もう1つは下部の test listener に接続されています。
では、ここから異なるステージを進んでいきます。この時点では、スケールアップステージにいて、グリーン環境を作成し、新しいバージョンを実行する新しいタスクを作成しています。 ご覧の通り、タスク数が倍になっています。これは2つの環境があるためです。その後、テストトラフィックシフトステージに入ります。
ここでテストリスナーのルールを変更して、新しいタスクにトラフィックをルーティングしています。右下のウィンドウに新しい黒い背景が表示されているのが見えます。これはテストリスナーに接続されています。 その後、本番トラフィックシフトステージに入ります。ここで本番リスナーが変更され、トラフィックが新しいタスクにルーティングされます。その後、ベイクタイムステージに入ります。ここで2つの環境が保持されます。すべてのトラフィックは新しい環境、つまりグリーンに向かっていますが、ブルーはまだそこにあります。 これにより、必要に応じて迅速にロールバックできます。
このバージョンに何らかの理由で満足できず、ロールバックしたいとしましょう。ブルー環境がまだそこにあるため、これは迅速に行えるはずです。 ロールバックをクリックすると、デプロイメントステータスがロールバックがリクエストされたことを反映します。 その後、再び本番トラフィックシフトステージに進み、本番リスナーを変更してトラフィックをブルー環境、つまり古いタスクに戻します。 黄色っぽい背景が再び表示されます。テストリスナーでも同じことが起こります。つまり、古い環境に戻します。その後、クリーンアップステージに入ります。ここでこのデプロイメントの一部として作成された新しいタスクを削除します。 3つのタスクに戻り、新しい環境は完全に削除されます。
ライフサイクルフックを活用した手動承認ワークフローとまとめ
では、このデプロイメントワークフローをカスタマイズしたいとしましょう。 実際に本番トラフィックをシフトする前に、自動テストを実行したいとします。または、手動承認ステップや手動検証ステップを追加したいとします。テストトラフィックシフト後にデプロイメントを保留にして、このテストを実行してから進めたいとします。これを実現するために使用できるものの1つは、ライフサイクルフックです。
ライフサイクルフックは、デプロイメントワークフローの異なるポイントで呼び出すことができるLambda関数です。これらのライフサイクルフックは、進行中、成功、または失敗のいずれかを返すことが期待されています。 進行中を返す場合、デプロイメントはこのステージで保留され、設定された秒数後に再度呼び出し続けます。成功または失敗のいずれかを返すまで、呼び出し続けます。成功を返す場合、デプロイメントは次のステージに進みます。失敗する場合、ロールバックがリクエストされます。
では、先ほど触れたシナリオの1つを見てみましょう。手動承認ワークフローの実装です。これがライフサイクルフックでどのように実装できるかを見てみます。post-test traffic shift ステージのフックとして設定された Lambda 関数を作成します。 この Lambda 関数は、最初にデプロイメントの状態を pending として設定し、この状態を S3 バケットに保存します。その後、post-test traffic shift ステージで呼び出されるため、SNS を通じてレビュアーに通知が送信されます。新しいバージョンは既にテストリスナーの下で利用可能になっており、誰かが検証できるようになっています。
レビュアーがそれを確認して、検証して、満足したら、この状態に移動して、pending から approved に変更することができます。次回ライフサイクルフックが呼び出されるとき、ステータスを確認して、approved であることを見つけ、成功を返します。これがライフサイクルフックの1つのユースケースです。これが実際にどのように機能するかを見てみましょう。この場合、サービスに変更を加えますが、今回は post-test traffic shift で デプロイメントプロセスを停止して、手動検証を行いたいとします。
では、まずライフサイクルフックを追加します。再度サービスに移動して、ここでサービスを更新します。ライフサイクルフックセクションで、先ほど説明したロジックで作成した Lambda 関数を選択します。Lambda 関数を選択した後、デプロイメントコントローラーがこの Lambda 関数を呼び出すことができる IAM ロールを提供する必要があります。 ここでこのロールを選択します。そして、このフックを呼び出す必要があるライフサイクルステージを選択する必要があります。この場合、post-test traffic shift ステージになります。
これが完了したら、UI サービスの変更をプッシュして、これがどのように機能するかを見てみましょう。 では、背景をもう一度変更します。先ほど見た同じ CI/CD パイプラインを通過し、デプロイメントステージに進みます。ECS コンソールにジャンプします。 先ほど説明した異なるステージを通じて進行します。同じブラウザウィンドウのセットアップです。上部は本番環境に接続され、下部はテストリスナーに接続されています。scale up ステージにいるので、新しいバージョンがプロビジョニングされています。
そして、test traffic shift ステージに到達しました。テストリスナーが新しいバージョンにルーティングするように変更され、下部の背景が変わったのが見えます。その後、post-test traffic shift ステージに到達します。ここで、ライフサイクルフックが呼び出され、Lambda 関数に含まれるロジックに基づいて通知が送信されます。
ユーザーまたはレビュアーが、このテスト リスナーで新しいバージョンをテストします。この検証の結果に基づいて、承認または却下のいずれかを選択できます。この場合は、承認することにします。
これにより、S3 パケット内のデプロイメント状態または承認状態が承認済みに設定されます。そしてフックが呼び出されると、成功が返され、これによってワークフローが本番トラフィック シフト ステージに進みます。
ご覧のように、新しいバックグラウンドが本番リスナーの下に表示されるようになりました。
ベイク タイム ステージに到達します。ロールバックはしません。ただ経過するのを待つだけで、その後クリーンアップ ステージに到達します。古いバージョンを削除すると、デプロイメントが成功します。
では、いくつかの重要なポイントについてお話ししたいと思います。その1つ目は、利用可能なさまざまなデプロイメント戦略があるということです。
その1つは、もちろん私たちが説明したローリング アップデート、そして同じく説明した Blue-Green もあります。さらに Linear や Canary といった Blue-Green 戦略のバリエーションである追加の戦略もあります。
Blue-Green デプロイメント戦略で得られる主な利点は、リスク軽減です。デプロイメント中に2つの環境を維持することで、問題が発見された場合にロールバックできます。ローリング アップデートと Blue-Green の間にはいくつかのトレードオフがあります。
ローリング アップデートでは、デプロイメント中に使用される総容量は低くなる可能性がありますが、その欠点はロールバックが少し遅くなる可能性があるということです。しかし、Blue-Green デプロイメント戦略では、Blue と Green という2つの並列環境があるため、より多くの容量を使用していますが、迅速なロールバックが得られます。
では、皆さんへの呼びかけです。これらは Blue-Green に関する追加リソースです。後でこれらのリソースを自由に探索してください。スライドをしばらく表示しておきますので、写真を撮ってください。
では、本日は Blue-Green に関する2つのセッションが開催されます。1つ目は、ここ Mandalay Bay でのブレークアウト セッションです。午後1時30分に開始されます。Blue-Green についてもっと知りたい場合は、このセッションにぜひご参加ください。
もう1つはワークショップです。午後4時に MGM で開催され、このワークショップでは、私たちがお見せしたデモを実際に構築し、さらに説明した内容に機能を追加することもできます。
では、以上が私がお伝えしたかったすべてです。お時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion