re:Invent 2025: Amazon ECSの高度なデプロイメント戦略とCodeDeployからの移行
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Accelerate software delivery with Amazon ECS (CNS315)
この動画では、Kevin GibbsとMike RizzoがAmazon ECSの高度なデプロイメント戦略について解説しています。ECSサービスの基本からrolling、blue-green、canary、linearの各デプロイメント戦略の違い、トラフィックシフトの仕組み、lifecycle hooksを活用したカスタムテストの実装方法まで詳しく説明されています。架空の企業Unicorn Watchの事例を通じて、Application Load Balancer、Service Connect、headless service、Network Load Balancerという4つの異なるサービス公開パターンでadvanced deploymentsを活用する具体的な方法が示されます。CodeDeployからECSデプロイメントコントローラーへの移行手順や、各戦略の選択基準、CloudWatch alarmsやcircuit breakerを使った自動ロールバックの設定についても触れられており、実践的な知見が豊富に含まれています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
ソフトウェアデプロイメントの価値とECSサービスの基本構造
こんにちは。私はソフトウェアデプロイメントが大好きです。ソフトウェアデプロイメントが大好きな理由は、それが私のお客様である皆さんに価値を提供する方法だからです。そして今日ここにいらっしゃる皆さんも、おそらくお客様に価値を提供するためにソフトウェアをデプロイすることが好きなのだと思います。私の名前はKevin Gibbsです。同僚のMike Rizzoと一緒に、Amazon ECSのデプロイメントと、今年私たちが提供した高度なデプロイメント戦略についてお話しします。
本日お話しする内容の概要です。まず、ECSサービスとデプロイメントの入門編についてお話しします。 次にMikeが、高度なデプロイメント技術、設定、そして私たちが高度なデプロイメントと言うときに正確に何を意味するのかについて詳しく説明します。最後に、異なるデプロイメント戦略の選択と移行、またはローリングから高度なデプロイメントへの移行について説明します。また、重要なポイントと、学習プロセスを完了し継続するための他の方法についても取り上げます。
それでは、ECSサービスについてお話しするとき、実際には2つの異なる設定パラメータ、またはパラメータのセットについて話しています。1つ目はタスク定義です。タスク定義は作業単位、つまりサービス内の単一のタスクを定義します。そしてサービス設定とそれらのパラメータは、何らかの機能を実行するためにそれらのタスクを1つ以上どのようにデプロイしたいかを示します。この2つを組み合わせたものが、実際にはサービスリビジョンとなり、これがAmazon ECSで私たちが呼んでいるものです。そのため、リビジョン履歴を見ることで、サービスが時間とともにどのように変化したかを実際に確認できます。
ECSデプロイメントコントローラーと4つの戦略：ローリングとアドバンストデプロイメントの違い
何もない状態から最初のサービスリビジョンへ、またはあるサービスリビジョンから次のサービスリビジョンへ移行するプロセスがECSデプロイメントです。そのプロセスが何をするのか、どのように機能するのか、そしてその設定について、本日説明していきます。デプロイメントの設定について詳しく見ていくと、最初に見るのはデプロイメントコントローラーです。 本日は、私たちが管理するネイティブコントローラーであるECSデプロイメントコントローラーに焦点を当てます。他に2つのオプションがあります。1つはCodeDeployを使用することで、これもblue-green、linear、canaryをサポートしています。そしてexternalもあります。externalが意味するのは、本当に皆さん次第ということです。デプロイメントを所有し、好きなように行うことができますが、その責任を負うことになります。これも別のオプションです。繰り返しになりますが、今後はECSに焦点を当てていきます。
次に決める必要があるのは、どの戦略にするかです。コントローラーをECSに決めたので、4つの戦略があります。デフォルトの戦略であるローリングがあります。これは、古いリビジョンと並行して新しいサービスをデプロイし、タスクの作成と削除を通じて移行するものです。それとは対照的に、3つの新しい高度なデプロイメントコントロール、失礼、デプロイメント戦略もあります。これらはトラフィックの移行方法が異なりますが、すべて新しいタスクセットと古いタスクセットを一緒に配置することで、バージョン間でより迅速かつシームレスにロールバックやロールフォワードを行うことができます。
標準的なローリングデプロイメントとアドバンストデプロイメントの違いとして気づかれる点の一つは、タスクキャパシティがどのように見えるかということです。標準的なローリングデプロイメントでは、実際に新しいタスクを作成し、古いタスクを破棄して削除または停止するため、キャパシティはある程度一定に保たれます。一方、アドバンストデプロイメントでは、デプロイメントのライフタイム全体を通して、実際にタスクの数が2倍になります。色の例えを使うなら、ブルータスクとグリーンタスクの両方を持つことになります。つまり、その期間中は2倍のキャパシティを持ち、デプロイメントが終了すると通常に戻ります。
もう一つの重要な違いは、トラフィックがどのようにシフトまたは移行されるかという点です。ローリングデプロイメントでは、繰り返しになりますが、ブルータスクとグリーンタスク、つまり古いものと新しいものが並んで実行されており、どちらかに向かうトータルトラフィックは基本的に、起動していて正常なタスクの数に依存します。アドバンストデプロイメントでは、トラフィックのシフト方法に追加の機能があります。Blue-Greenでは、実際に行われるのは、ブルーからグリーンへ100%を一度にシフトすることです。一度だけ実行します。Canaryは2段階のプロセスのようなもので、初期のパーセンテージを選択できます。この例では、初期の移行として10%を示しており、トラフィックの10%を移行します。その後、メトリクスを確認し、すべてが良好であることを確認してから、100%に移行します。Linearはn段階バージョンで、増分があります。3%という小さな値から始めることができ、その場合デプロイメントは約33段階になりますが、時間をかけてトラフィックシフトを行います。
ライフサイクルフックとベイクタイム：各デプロイメント戦略固有の設定パラメータ
これを行いたい理由としては、新しいバージョンのパフォーマンスが心配で、実際に徐々にトラフィックをシフトして、どのようにパフォーマンスしているかを確認したい場合などがあります。 すべてのECSストラテジーに共通する設定の一つは、ライフサイクルフックです。これは今年追加した新しい機能で、デプロイメントプロセスに関与できる機能です。「新しいタスクをスケールアップした後に、何かをしたい、何かをチェックしたい」といったLambdaを定義できます。ライフサイクルフック経由で独自のトラフィックシフトパラダイムを実装することもできます。そして、ベイクタイムという考え方もあります。アラームベースのロールバックを使用している場合、これはしばらく前からある機能ですが、新しいバージョンがトラフィックを処理している状態で1時間または1日ベイクしたい場合、ベイクタイムでそのオプションがあります。
最後に、 異なるストラテジーに固有の設定がいくつかあります。最初はローリングで、これらの増分が時間とともにどのように成長しシフトするか、つまりローリングにおける最大キャパシティの合計と、最小キャパシティです。実際に、新しいタスクを開始する前にいくつかのタスクをスケールダウンしたり、古いタスクをスケールダウンする前に新しいタスクを開始したりすることができ、これら2つを使って設定します。Blue/Greenには、実際には固有のものはありません。ライフサイクルフックを設定したり、ベイクタイムを設定したりできますが、基本的には単一のシフトなので、固有のものはありません。Canaryでは、初期のシフトを制御でき、0.1%から99.9%まで設定して、全員を移行する前に新しいバージョンにどれだけのトラフィックを流すかを制御できます。そしてLinearも同様に、各ステージは3%から99.9%まで設定できます。そして最後の2つについては、各シフトの間にミニベイクタイムのような待機時間を設けて制御できます。
Unicorn Watchの事例紹介：高可用性を維持しながらデリバリーベロシティを向上させる課題
それでは、Mikeに引き継ぎます。彼が異なるアドバンストデプロイメントストラテジーについて詳しく説明します。Kevinさん、アドバンストデプロイメントの素晴らしいイントロをありがとうございました。私の名前はMikeです。そして申し上げたように、アドバンストデプロイメントのような新機能から実際の利益を得られるよう、お客様と協力できることを本当に楽しみにしています。これから30分ほどかけて、アドバンストデプロイメントがどのように機能するかをもう少し深く掘り下げ、また様々な シナリオでどのように使用できるかの具体例を見ていきます。でもまず、少し寄り道をさせてください。私のもう一つの情熱、ユニコーンについてお話ししたいと思います。 AWSではユニコーンが大好きなんです。ちょっとした秘密をお教えしましょう。私たちの中には、夜に出かけてこの素晴らしい生き物を見つけようとする者もいます。これは先週、私の同僚が撮影したものです。これを話題にしている理由は、私のお気に入りのお客様の一社が最近アドバンストデプロイメントで経験した旅をご紹介したいからです。
Adaさんをご紹介します。Unicorn WatchのCTOです。Unicorn Watchは、ユニコーン目撃情報データの世界有数のリポジトリであり、ユニコーン研究のための頼りになる場所です。また、世界最大のユニコーン目撃ビデオのアーカイブでもあります。そしてAdaさんは、advanced deploymentsがローンチされたと聞いて、私たちのところに来て、advanced deploymentsを使ってデリバリーベロシティを高速化できるようなメリットがあるかどうか尋ねてきました。これが彼らが持っていたアーキテクチャです、advanced deploymentsが登場する前のものです。彼らはALBでフロントエンドされたUIを持っていて、このUIを通じて、ユーザーはビデオのカタログにアクセスしたり、アカウントにアクセスしたり、購入したりすることができました。購入を行うと、オーダーフルフィルメントフローの作成がトリガーされ、そのフローは別のALBを通じて、ordersサービス上のインターフェースをポーリングすることで監視できました。フロントエンドとバックエンド間のすべてのやり取りは、Service Connectを通じて行われていました。
そして、下部にはNetwork Load Balancerでフロントエンドされたストリーミングサービスがあり、メディアアセットバケットからビデオを取得していました。そしてこの仕組みは、ordersがセキュリティ目的で一意の識別子でウォーターマークされたビデオを作成するというものでした。これはすべてうまく機能していました。
そして彼らは全体的にECS rolling deploymentsを使用していましたが、一つだけ例外がありました。 UIの場合、彼らはblue-greenを使いたかったんです。そうすれば、本番環境に切り替える前に、安全なgreen環境で新しいデプロイメントを手動でチェックできるからです。そのために、彼らはCodeDeployを使用していました。
さて、このようなサービスは高額な価格設定のプレミアムサービスであり、また、ユニコーンの写真家たちもロイヤリティを得たいと思っていることは想像できるでしょう。ですから、このプラットフォームが高いレベルの可用性と信頼性を維持することは本当に重要なんです。同時に、より多くの新機能への需要が高まっており、またAdaさんはカタログサービスをサードパーティのウェブサイトに公開して、彼らもカタログからビデオを再販できるようにしたいと考えていました。そこで彼らが直面した課題は、高い可用性と信頼性を維持しながら、同時にデリバリーベロシティを高速化したいということでした。そこでadvanced deploymentsが登場したとき、彼らはそれが自分たちに何をもたらしてくれるのか、本当に理解したいと思ったんです。
アドバンストデプロイメントのライフサイクル：Blue-Green、Canary、Linearの動作メカニズム
この話には後で戻ってきますが、まず、advanced deploymentのライフサイクルについて、もう少し詳しく説明したいと思います。 初期状態では、本番環境で実行されているサービスがあります。これをBlue Environmentと呼びます。すべてのトラフィックがそこに向かっていて、新しいデプロイメントを開始すると、実行する必要があるタスクの新しいspecがあり、例えば新しいコンテナイメージなどが含まれます。そして、デプロイメントステートマシンの最初のステージに入ります。これはPre Scale Upとして知られています。つまり、green環境をスケールアップする前の段階です。
さて、ここで側面に小さなフックアイコンが表示されているのがわかると思います。これは、このステージがフック可能なステージであることを示しており、つまりライフサイクルフックをアタッチできるということです。ライフサイクルフックを使うと、Lambda関数で独自のカスタムロジックを実行できます。そしてそれを使って、テストやチェックを実行することができ、そのステージを成功させて次のステージに進めるか、それともロールバックを強制するかを判断するために使用できます。この例では、green環境をスケールアップする前に、例えば何らかのアドミッションコントロールチェックを実行したいかもしれません。例えば、このコンテナイメージは信頼できるリポジトリから来ているか、といったチェックです。
フックが正常に返されると、次のステージに進みます。ここでスケールアップを行います。ここでgreen環境をスケールアップします。画面の向こう側に、green環境がスケールアップしているのが見えますね。そして完全にスケールアップが完了すると、Post Scale Upステージに入ります。この時点では、すべてのプロダクショントラフィックはまだblue環境に向かっています。green環境にはトラフィックは流れていません。
green環境が整ったら、次のステップはテストトラフィックをそこに流し始めることです。ここでTest Traffic Shiftステージに入り、ルーティングを設定して、何らかの方法で識別される必要があるテストトラフィック、これについては後ほど戻りますが、そのテストトラフィックがgreen環境に流れ始めるようにします。そのルーティングが設定されると、Post Test Traffic Shiftステージに入ります。この時点で、green環境はテストトラフィックを受け取り始めることができるようになります。
ここは、green環境で自動テストを実行したい場合や、green環境で実行されている何かに対して手動チェックや手動承認を行いたい場合に、フックを配置するのに非常に便利な場所です。ここでフックを通じてそれを行うことができます。これについては、Unicorn Watchでいくつかの例を見て、彼らがどのように使用しているかを確認する予定です。さて、現在の状況は、blue環境がすべてのプロダクショントラフィックを受け取っており、すべてのテストトラフィックがgreenに向かっているという状態です。
Post Test Traffic Shiftを正常に抜けると、つまりすべてのライフサイクルフックが成功すると、プロダクショントラフィックをgreen環境にシフトし始めます。さて、使用している戦略によって、これはいくつかの異なる方法で行われます。最もシンプルなのはblue-greenで、これは一度にすべて行われます。つまり、すべてのトラフィックを一度のステップでblueからgreenにシフトします。しかし、canaryを使うこともでき、その場合は2段階で行われます。または、linearで行うこともでき、これは複数ステップになる可能性があります。これについてはすぐに戻ります。プロダクショントラフィックをシフトして、100%がgreenに向かうようになったら、Post Production Traffic Shiftステージに入ります。
さて、この時点では、 blue環境にはもうproductionトラフィックは流れていません。すべてgreen環境に流れていますが、blue環境はまだ稼働しています。古いサービスリビジョンがblue環境で稼働し続けているわけです。これが便利なのは、もしgreen環境で何か問題が起きた場合、非常に素早くロールバックしてblue環境に切り戻すことができるからです。
そして、このblue環境を定義されたbake timeの間、稼働させ続けます。つまり、blue-greenデプロイメントの設定の一部として、bake timeを指定することができ、そのbake timeの全期間にわたって、blue環境は存在し続けることになります。 bake timeが終了すると、最終ステップはクリーンアップです。この時点で、blueをゼロにスケールダウンし、greenがproduction環境となり、次のデプロイメントのためのblue環境になるという状況になります。
これらの各ステージは最大24時間かけることができるので、例えば長時間のテストを実行する必要がある場合など、かなり長い期間をかけてこれを行うことができます。また、私がroutingとtraffic shiftingが実際にどのように行われているかについて、あまり詳しく話さないように注意していたことにお気づきかと思いますが、それは意図的なものです。なぜなら、それはサービスがどのように公開されているかに依存するからです。例えば、サービスがload balancerの背後にある場合、listener rulesのweightを操作することで実現されます。しかし、サービスがService Connectに公開されている場合は、Service Connect proxyのrouting rulesを変更することでroutingが実現されます。
canaryデプロイメントの場合、これまで見てきたライフサイクルと全く同じです。唯一の違いは、production traffic shiftステージが2回あるということです。つまり、基本的に、production traffic shiftに紐づけられたhookがある場合、そのhookが2回呼び出されることになります。1回目は最初のcanary shiftのためで、最初のステップでは、パーセンテージを取ります。この場合は10%ですが、これは設定可能です。そして、canary bake timeを指定します。そのcanary bake timeの期間中、そのパーセンテージのproductionトラフィックがgreen環境に流れることになります。
canary bake timeが終了すると、production traffic shiftに再び入るので、hookがあれば再度呼び出されます。そして、残りのtraffic shiftをproductionに完了させます。linearの場合は似ていますが、複数のステップがあります。 つまり、canaryとlinearを使って異なる目的を達成することができます。canaryの場合、実際のproductionトラフィックで新しいサービスリビジョンのテストを行いたい状況があれば、canaryでそれを行うことができ、blast radiusを制限することで、もし問題が起きても、大きな影響を受けないようにすることができます。
linearの場合、新しいサービスリビジョンをより段階的にロールアウトすることができ、その間にパフォーマンスと機能が正しく維持されているかを監視することが可能です。さて、非常に重要なのは、高度なデプロイメントを使用する際に、新しいリビジョンの失敗やパフォーマンス低下がどのような状態を指すのか、そしてそれがデプロイメントを停止してロールバックする必要があるのかを考えることです。そしてECSはこれをサポートするために3つの広範なメカニズムを提供しています。
デプロイメント失敗の検知とロールバック：Circuit Breaker、CloudWatch Alarms、カスタムテストの活用
まず、最もシンプルなのはcircuit breakerです。circuit breakerでは、新しいタスクが指定された期間内に実際に健全で安定した状態を達成するかどうかを単純にチェックします。次に、CloudWatch alarmsがあります。ここでは、ユースケースに適したメトリクスを選択し、それらのメトリクスにアラームを設定することができます。そしてそれらのアラームがトリガーされると、デプロイメントの失敗とロールバックを強制することができます。
ここで使用できるメトリクスは、例えば、ALBフロントエンドのサービスがある場合、400または500エラーのカウントのメトリクスを見ることになるでしょう。以前のリビジョンのパフォーマンスをベンチマークしていて、新しいリビジョンのパフォーマンスが以前のものと一致していることを確認したい場合は、CPU utilizationやmemory utilizationのようなものを見たいと思うかもしれません。非常に重要なのは、canaryやlinearを使用している場合、greenとblueが一緒に混在して実行されていることを考慮に入れることです。したがって、これはアラームのしきい値で考慮する必要があることです。
また、タスクがキューからメッセージをプルしている状況についても考えることができます。つまり、タスクに実際にルーティングされるトラフィックはなく、代わりにタスクがキューからメッセージをプルしているのです。その場合、アラームのメトリクスとしてキューの長さを監視したいと思うかもしれません。
そして最後に、custom testsとtraffic monitoringがあります。これは先ほど述べたlifecycle hooksが登場するところです。ここでは、Lambdaで独自のテストを実装し、デプロイメントライフサイクルの適切な場所にそれらを挿入することができます。そして、Unicorn Watchでこれについてのさらなる例を見ていくことになります。
Unicorn WatchのアーキテクチャとALB・Service Connect・Headlessサービスでの実装例
それでは、Unicorn Watchのアーキテクチャに戻りましょう。おさらいですが、これが彼らがadvanced deploymentsを導入する前に持っていたアーキテクチャです。 これから、このアーキテクチャのいくつかの側面を順番に見ていき、どのような変更を加え、それによって何を達成できたのかを確認していきます。
まず、UIとcatalog serviceについてお話しします。彼らはここでいくつかのことを実現したいと考えていました。 catalogにcanary deploymentsを使用することで、本番環境で新しいcatalogの機能を限定的な影響範囲で試せるようにしたかったのです。また、catalogをpublic APIとして公開し、サードパーティのウェブサイトからもアクセスできるようにしたいと考えていました。
しかし、CodeDeployを使い続けることではこれを実現できませんでした。まず、CodeDeployはService Connectをサポートしていないため、catalogでcanariesを使用することができませんでした。さらに、catalogをpublic APIとして公開するためにやりたかったことは、同じロードバランサーの同じポートで公開することでした。そのためには、ロードバランサーの高度なリクエストルーティング機能を使用して、パスベースルーティングを使う必要がありました。
CodeDeployではパスベースルーティングができないため、 ECS Blue-Greenに移行することで、彼らは目的を達成できたわけです。つまり、ここで見ていただけるように、パスベースルーティングを使用してALBの同じポート経由で2つの異なるサービスにアクセスできるようになり、また、catalog serviceでcanariesに切り替えることができました。
では、これをもう少し詳しく見ていきましょう。 ロードバランサーから始めます。この図を使って、これからのトークの中で何度か戻ってきます。ECS上でサービスを公開するさまざまな方法をいくつか紹介し、それぞれの方法でadvanced deploymentsがどのように機能するかをお見せします。
それでは、ここからロードバランサーについて始めます。ALBを使った高度なデプロイメントを行う場合、最低限、本番用のリスナールールを提供する必要があります。そして、オプションでテスト用のリスナールールも提供できます。仕組みとしては、基本的にこれらのリスナールートの重みをデプロイメントコントローラーが操作することで、先ほどお話ししたトラフィックシフトの効果を実現しています。
ALBはリスナールールレベルで動作するため、Application Load Balancerの高度なリクエストルーティング機能をフルに活用することが可能です。つまり、パスベースのルーティング、ヘッダーベースのルーティング、クエリ文字列ベースのルーティングなど、ALBで期待されるすべての機能が引き続きサポートされます。また、同じサービスを複数のリスナーで利用可能にすることもでき、それも高度なデプロイメントで動作します。
これを設定するには、サービス設定のロードバランサーブロックに、この高度な設定ブロックを追加します。ここで2つ目のターゲットグループを指定します。つまり、高度なデプロイメントを機能させるには2つ目のターゲットグループが必要になります。そして、本番用リスナールールのARNを指定し、オプションでテスト用リスナールールのARN、そして重要なのがIAMロールも指定します。このIAMロールは、ECSがこれらのリスナールールの重みを操作する権限を与えるために必要です。
リスナーARNへの参照がないことに注意してください。これは、同じポート上にあるかどうかに関わらず、好きなリスナールールを自由に選択できることを意味します。ECSの観点からは、何の違いもありません。つまり、ECSはそれらのリスナールールが実際にどのポートに接続されているかについては関知しないということです。
では、Unicorn Watch UIの例を使って、これがどのように機能するか見ていきましょう。彼らはブルーグリーンデプロイメントを行いたいと考えており、本番環境に移行する前に新しいバージョンに対して手動承認を行いたいと考えています。開始状態では、既存のサービスがブルー環境で実行されており、すべてのトラフィックがそこに向かっています。最初のステップはスケールアップです。グリーンサービスのリビジョンを作成し、プレスケールアップ、スケールアップ、ポストスケールアップの各ステージを経ていきます。
次に、トラフィックのシフトを開始します。トラフィックをシフトするには、テストリスナーの重みを入れ替える必要があります。これで、トラフィックの100%がグリーン環境に流れるようになります。この時点で、トラフィックシフトが完了すると、ポストテストトラフィックシフトに入ります。このケースでは、Unicorn Watchがフックをアタッチしています。このフックが行うのは、承認パラメータの監視です。この承認パラメータがacceptまたはdeclineに設定されるまで、どこかの何かがそのパラメータを設定する必要があり、それがライフサイクルフックによって検知されて、デプロイメントを続行すべきかどうかが判断されます。
なお、ECS自体は手動承認などを行うためのUIを提供していません。その実装は、組織内でのデプロイメントに関する広範な運用をどのように orchestrate するかという、実装者次第となります。この例では、Parameter Storeに保存された承認パラメータを使用しており、承認者がそのパラメータを設定するために使用できる別のUIがあります。ここでのポストテストトラフィックシフトフックの動作方法は、その承認パラメータの現在の状態をチェックします。まだpending状態の場合、フックはin-progressステータスインジケーターを返し、ECSは成功または失敗が返されるまで、フックを複数回再呼び出しします。
そして、承認が得られたと仮定します。チェックボックスにチェックが入ったので、フックは成功することができ、ポストテストトラフィックシフトステージを超えてデプロイメントを進めることができるようになります。では、プロダクショントラフィックシフトに移ります。ここでプロダクションルールの重みを入れ替え、ベイクタイムのクロックを開始します。この間、トラフィックはグリーン環境に流れていますが、ロールバックが必要になった場合に備えて、ブルーはまだ待機しています。そして最後に、ロールバックせずにベイクタイムが完了したと仮定すると、最後のステージは、先ほど申し上げたように、クリーンアップです。つまり、古いブルーをスケールダウンし、グリーンが新しいブルーになります。
これが、Unicorn WatchがUIサービスの前にALBを使用し、ECS blue-greenを使用した方法です。実際のリクエストルーティングについてはまだ話していません。トラフィックシフトについて話しました。さて、彼らは同じALBポートでカタログも公開したいと言っていたことを覚えていますか。では、これをどのように実現したいのでしょうか？パスベースルーティングでこれを実現したいと考えています。ここで設定したのは、ご覧のように、catalog slash catalog starをカタログサービスにルーティングするパスベースルート、frontend starをUIサービスにルーティングするものです。
また、テストトラフィックを示す方法も必要でした。これらのサービスのいずれかに対してテストトラフィックがある場合、これがテストトラフィックであることをどのように示すのでしょうか？そのために、彼らはヘッダーベースルーティングを使用することを選択しました。X-BG-Testヘッダーがある場合、それはトラフィックがテストトラフィックであることを示します。これができるのは、advanced deploymentsでadvanced request routingを使用できるためです。ここでは、プロダクション用の2つのルール、catalogプロダクションリスナールールとUIプロダクションリスナールールが確認できます。Application Load Balancerは、catalogとfrontendにマッチするパスパターンで設定されており、それぞれのルールにルーティングされます。そして、その向こう側では、デプロイメントコントローラーがこれらのルールを直接操作するように設定されています。catalogの場合はcanaryデプロイメントを使用し、UIの場合はblue-greenを使用しています。
テストトラフィックをルーティングするために、さらに2つのリスナールールがあります。そして、これらのルールにもHTTPヘッダールールチェックを追加して、それらのルールにマッチするようにしています。
望ましい効果を得るためには、ルールを正しい順序で並べることが重要です。
では、Service Connectについてはどうでしょうか?ALBについては見てきました。カタログは内部的にもService Connect経由で公開されており、このカナリアをService Connectでも機能させたいと考えています。では、これはどのように動作するのでしょうか?Service Connectでは、リスナールールも、操作するリスナールールのウェイトもありません。代わりに、アプリケーションのタスク内で、アプリケーションコンテナと並んでService Connectプロキシが配置されており、これが適切な場所にトラフィックをルーティングする必要があります。仕組みとしては、グリーンリビジョンを作成すると、ブルーとグリーンの両方のリビジョンがCloud Mapに登録され、グリーンの方はテストインスタンスとしてラベル付けされます。Service Connect名前空間内のすべてのクライアントは、ブルーとグリーンの両方のリビジョンを見ることができますが、テストルールにマッチするリクエストのみがグリーンリビジョンにルーティングされます。
Service Connectに馴染みがない方のために簡単に説明すると、仕組みとしては、タスク内でアプリケーションコンテナと並んでプロキシコンテナが実行されており、これが基本的にすべてのネットワークトラフィックをルーティングするように設定されています。すべてのネットワークトラフィックはこのプロキシコンテナを通過し、必要なバージョンにアウトバウンドトラフィックをルーティングするように設定できます。デフォルトでの設定方法は、X-Amazon-ECS-blue-green-testというヘッダーを設定すると、Service Connectプロキシがそれをグリーンリビジョンに自動的にルーティングします。これを独自のヘッダールーティングルールに置き換えることができます。任意のヘッダーを使用できます。ヘッダーの存在、ヘッダー値のマッチング、またはヘッダーパターンマッチングを使用できます。つまり、ユースケースに応じて、エージェント文字列やAPIリビジョン番号などを使用できるということです。
では、Unicornはこれをどのように使用したのでしょうか?カタログチームはパフォーマンスについて非常に懸念しており、サービスの新しいリビジョンを本番環境に投入する前に、必ずパフォーマンステストを実施したいと考えていました。基本的に、彼らは2つのものを使ってこれを実装しました。Service Connect名前空間内にトラフィックジェネレーターを配置し、このトラフィックジェネレーターが負荷を生成します。すべてのリクエストは自動的にこのテストヘッダーでマークされます。そして、post-test traffic shiftステージにフックを実装しました。このステージで行うことは、ロードジェネレーターをトリガーしてテストトラフィックの送信を開始させます。負荷がかかった状態でのサービスのパフォーマンスを測定し、そのテストの最後に、合格したかどうかを判定します。合格した場合、フックは正常に返され、デプロイメントが続行されます。そうでない場合は、失敗してロールバックがトリガーされます。
ここで注意すべき重要な点は、Service Connectでテストを行う場合、クライアントがService Connectの名前空間の一部である必要があるということです。外部からテストすることはできません。Service Connect内から行う必要があります。このケースでは、このトラフィックジェネレーターをService Connectの名前空間にデプロイすることで、それを実現しました。これにより、本番トラフィックの切り替えに移行する前に、グリーン環境でパフォーマンステストを行うことができました。
しかし、本番トラフィックの切り替えに移行する際にも、新しい環境への本番トラフィックの完全な切り替えを許可する前に、canaryを使用して追加のテストを行いたいと考えていました。ここで、覚えていらっしゃるかと思いますが、先ほどcanaryでは、production traffic shift hookが2回呼び出されると述べました。そこで彼らがここで行ったのは、最初の呼び出し時にテストを開始することです。この時点で、canaryのパーセンテージの本番トラフィックがグリーン環境に送られており、canaryのパフォーマンスを監視するためにこのテストを開始します。これはcanary bake timeの期間中続きます。
canary bake timeの終了時に、production traffic shift hookが2回目に呼び出され、この時点で監視結果が収集され、分析されて、canaryが正常に実行されたかどうかが判断されます。再度申し上げますが、canaryが正常に実行された場合は、return successを許可し、このproduction traffic shiftを100%完了させます。しかし、そうでない場合は、hookを失敗させることで強制的にロールバックすることができます。これにより、前のスライドで見たようなグリーン環境のテストと、canary production traffic shiftメカニズムを通じた実際の本番環境での一部のトラフィックのテストを組み合わせることができることがわかります。
通知サービスとビデオストリーミング：Headlessサービスとネットワークロードバランサーでのblue-greenデプロイメント
さて、これまでUIとカタログを見てきました。次に彼らが見たのは、進行中の注文のステータスをapplication load balancerを通じてポーリングするこのメカニズムです。さて、これはあまりスケールしませんよね?基本的に、ステータスの更新をポーリングしなければならず、明らかに、処理する注文が増えるほど、これは非効率になります。しかし、通知メカニズムの観点からも、これはかなり制限的でした。彼らがやりたかったのは、さまざまな通知メカニズムをサポートすることでした。例えば、メールを受け取りたい人や、携帯電話でSMSを受け取りたい人など、どんな通知メカニズムでも、幅広くサポートしたかったのですが、このアーキテクチャではそれができませんでした。
彼らがやりたかったのは、より非同期的なアプローチに切り替えることでした。注文がキューにイベントを投稿し、そのキューを通知サービスが監視して、キューからイベントを取り出し、各ユーザーに設定された様々なメカニズムを使用して通知を送信するというものです。問題は、これを簡単に行うことができなかったことです。なぜなら、もしそれを行うとすれば、あるバージョンから別のバージョンに一度に切り替えるために、blue-greenデプロイメントが必要になるからです。そして、CodeDeployではそれができませんでした。なぜなら、このサービスがキューからメッセージを取り出す場合、その前にロードバランサーがないからです。
これが彼らがやりたかったことです。notification serviceの前にはロードバランサーがありません。これはいわゆるheadless serviceと呼ばれるものですね。notification serviceに実際にリクエストが送られることはありません。むしろ、notification serviceがキューからメッセージをプルしているんです。そしてECS blue-greenでは、このパターンをサポートできます。つまり、service connectもロードバランサーもなく、ただタスクやサービスがキューからメッセージをプルするheadless serviceをサポートできるわけです。これが次に見ていくパターン、headless serviceです。
さて、headless serviceでは、 サービスにリクエストが送られないため、シフトするトラフィックがありません。そこで疑問に思うかもしれません、シフトするトラフィックがないのに、どうしてadvanced deploymentsで意味があるのか、と。これが意味を持つのは、blueとgreenの環境をしばらく並行して実行することで、greenがうまく動作せず素早くロールバックする必要がある場合に、blue環境に非常に素早くロールバックできるというメリットがまだあるからです。しかし、リクエストトラフィックがないため、これらのサービスのアクティベーションをどう管理するかについて、少し違った考え方をする必要があります。
つまり、基本的には、どのバージョンのサービスがキューからメッセージを取得しているかを判断するために、少し追加の作業が必要になります。そして、実際にキューからメッセージをプルするサービスをオンまたはオフにする何らかの方法が必要です。では、Unicorn Watchでどのように機能するか見てみましょう。
初期状態では、既存のblue revisionがキューからメッセージをプルして、それらのメッセージを処理しています。そして今、新しいバージョンをデプロイします。 新しいバージョンをデプロイする際、非アクティブ状態でデプロイします。つまり、タスクは作成されますが、例えばparameter storeなどに何らかのパラメータがあって、これがキューから物をプルすべきかどうかを制御しているんです。なので、非アクティブ状態で開始され、キューからメッセージをプルしないように指示されます。
これがスケールアップされたら、通常のtest traffic shiftはスキップして、そのまま進んで、production traffic shiftに直接進むことができます。 そしてこの時点で、このステージに入ったときに、フックを使ってblue revisionを無効にし、green revisionを有効にすることができます。つまりこの時点で、キューからメッセージを取得して処理しているのはgreen revisionになるわけです。
この時点で、greenリビジョンの動作とパフォーマンスの監視を開始し、正しく機能していること、そしてメッセージを正しく処理していることを確認します。そこでこの場合はCloudWatchを使用してキューを監視します。監視が成功すれば、成功となり、ベイクタイムの後にblueリビジョンを削除することができます。一方、失敗した場合は、greenを無効化し、blueを復元して、blueを再度有効化することで以前の状態に戻します。これが彼らが注文のステータス更新について顧客に通知する能力を改善した方法です。
最後の部分はビデオストリーミングサービス自体についてで、ここでは彼らは独自のストリーミングプロトコルの新しいバージョンを、多くの新しいセキュリティ機能とともにデプロイする能力を求めていました。そして、あるバージョンから別のバージョンへ完全に切り替える方法でそれを行う必要がありました。なぜなら、新しいバージョンと古いバージョンの間の互換性を保証できなかったからです。そこで彼らはビデオストリーミングサービスにblue-greenを求めました。そしてこれを実現するために、彼らはNetwork Load Balancerでadvanced deploymentsを使用しました。Network Load Balancerでは、多くの点でApplication Load Balancerで見たものと非常に似ていますが、注意すべきいくつかの違いがあります。
まず、Network Load Balancerでは現時点ではblue-greenのみが可能で、canaryやlinearはできません。次に、レイヤー7のリクエストルーティングの利点がないため、レイヤー4で動作しているので、パスベースのルーティングができません。つまり、本番環境とテスト環境で異なるポートを使用する必要があり、本番用とテスト用に別々のポートが必要になります。また、Network Load Balancerの場合、テストリスナーはオプションではありません。テストリスナーを持つ必要があります。もう一つ注意すべき点は、いくつかのステージでは10分の追加の遅延が加わることです。これはNetwork Load Balancer内部のタイミングの問題に関連しており、ルーティングが正しく機能することを確認するためです。しかしそれ以外は、Application Load Balancerと非常に似ています。
では、まとめますと、ここではUnicorn Watchがいくつかの異なる領域でadvanced deploymentsを使用できた方法を見てきました。そして私たちが本質的にカバーしたのは、4つの異なるサービス公開方法です。Application Load Balancer、Service Connect、headlessサービス、そしてNetwork Load Balancerを見てきました。そしてadvanced deploymentsの素晴らしい点は、これらすべてのサービス公開パターンでadvanced deploymentsを使用できることです。それでは、Kevinに戻します。彼がマイグレーションに関する実践的な内容と、デプロイメント戦略の選び方について説明します。
デプロイメント戦略の選択と移行：CodeDeployからECSへの移行とまとめ
さて、Mike、ありがとう。かなりエキサイティングでしたね。それで私は自分自身でちょっとしたblue-greenデプロイメントを実行しました。そしてMike、あなたにサプライズがあります。Unicorn Watchの方々と協力して、彼らのストリーミングに関する新しいアップデートを入手しました。では、それがどのように動作するか見てみましょう。私のマシンでは動作したんですが、ここで何が起こっているのかよくわかりませんね。でも幸いなことに、私たちはblue-greenデプロイメントを使用しているので、すぐにロールバックできます。おっ、良くなったようですね。よし。
それでは、戦略の選択と戦略間の移行についていくつか見ていきましょう。まず戦略の変更は本当に簡単です。Mikeが話したように、デプロイメント設定で戦略を変更するだけです。重要なのは、ロードバランサーを使用している場合は、その高度な設定を追加することです。高度な設定を追加すれば、blue-greenからrollingへ、canaryへ、linearへと自由に行き来できます。非常に流動的です。重要なのは、一度高度なデプロイメントに移行したら、使用し続ける限り、その高度な設定をそのまま残しておくようお願いしているということです。なぜなら、どちらかのターゲットグループを使用している可能性があるため、rollingを実行する場合、どちらがトラフィックを処理しているかを判断するために両方が必要になるからです。ですので、繰り返しになりますが、高度な設定を追加すれば、自由に行き来できます。
また、CodeDeployからECSデプロイメント戦略に移行したい場合、2つの異なる方法があります。1つはupdate serviceを実行する方法、つまりインプレースで更新する方法です。
そして、デプロイメントコントローラーとデプロイメント設定の両方を、希望するものに変更します。繰り返しになりますが、高度な設定ブロックとロードバランサーをすべて一緒に追加する必要があります。なぜなら、CodeDeployを使用している場合、ロードバランサーの設定は実際にはCodeDeploy側にあるからです。もう1つのオプションは、基本的に置き換えサービスを作成し、より制御された方法で移行を行うことです。フックをテストしたい場合や、プロセスを少しテストしたい場合は、2つ目のサービスを作成してから移行することができます。
考慮事項についてです。冒頭でタスクがスケールアップ・ダウンする方法と、操作の速度について話しました。高度な設定とデフォルトのrollingの最大のトレードオフは、ロールバックの速度です。常にblueバージョンが完全にスケールされ、準備ができた状態にあるため、何らかの理由でデプロイメントの途中でサービスをスケールアップする必要がある場合、両方がその容量までスケールアップし、常にそこにあります。このシナリオでは、ロールバックの速度がはるかに高くなります。
高度なデプロイメントタイプの選択は、本当に何を達成しようとしているかによります。一度に1つのサービスリビジョンのみがトラフィックを処理するようにしたい場合は、blue-greenが最適です。すべてのトラフィックがblueまたはgreenで処理されることを保証します。これは、例えば、非常におしゃべりなクライアント、Webアプリなど、何度も呼び出しを行うような場合に、常に一貫したエクスペリエンスを得られるようにしたい場合に、blue-greenを使用することになります。
Canaryについては、先ほど少しお話ししましたね。これは、本番環境でテストできない場合、例えば規制された業界であったり、その他の理由で本番環境でテストできない場合に使えます。Canaryは、全員に導入する前に、顧客ベースの小さなセクションに導入する素晴らしい方法です。そして最後に、linearは、時間の経過とともに負荷の増加に対してどのようにスケールするかを確認したい場合や、その他の懸念事項がある場合に、再び素晴らしいオプションとなります。
繰り返しになりますが、advanced deploymentsで実行できる素晴らしいことの一つが、このテストトラフィックです。本番環境で実際に動作しているコードを、顧客に導入する前にテストする手段があり、それによって障害を未然に防ぐことができる可能性があります。先ほどお話ししたように、すべてのadvanced deployments間、またはadvanced deploymentsとrolling間で流動的に移行することができます。繰り返しになりますが、CodeDeployからadvanced deploymentsに移行することができ、そうしたい理由の一つは、以前は使えなかったAmazon ECSで使用できる高度な機能セットの一部を活用するためです。
Mikeがいくつかお話ししましたが、multi-target groupsや、複数のALBに接続しようとしている場合、そしてService Connectやその他の機能を使用する場合などです。最後に、皆さんの旅を続けていただくために、ここに多くの関連リンクと、今日私たちが説明した実際のデッキを含むランディングページがあります。また、本日午後4時にMGMでAmazon ECSを使ったデプロイメントパイプラインに関する関連セッションがあります。ですので、そちらに立ち寄っていただければ素晴らしいです。
この時点で、お越しいただき誠にありがとうございましたと申し上げたいと思います。そして、後ほど何か質問がございましたら、私はMikeとここにおりますので、お声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion