Amazon Web Services ブログ
AutoScaling を適用した Amazon ECS Service に対する効果的な Amazon ECS built-in Blue/Green の活用方法について
トラフィックの変動に対して自動的にキャパシティを調整する Auto Scalingと、安全なデプロイメントを実現する Blue/Green デプロイ戦略の組み合わせは、可用性と運用効率を両立する構成です。今回のテーマである Amazon ECS を利用する際に採用しているユーザーも多いのではないでしょうか。
しかし一方、Auto Scaling と Blue/Green デプロイ戦略を併用する場合、両機能が同時に作用するタイミングで複雑な相互作用が発生します。そのため、「Blue/Green デプロイメント中は Auto Scaling を停止している」といった声や「リスクが少ない夜間に更新を行う判断をしている」という声を複数聞きます。もちろん、組織の状況や運用するシステムの特性にもよるため、必ずしも悪い運用ではありませんが、もしかしたら相互作用の機序を明らかにすることで、労力を削減する余地があるかもしれません。
本記事ではまず、本テーマで扱う課題について詳しくない方に向けて Auto Scaling と Blue/Green デプロイを併用する際の相互作用について解説します。次に、2025年7月に発表された ECS built-in Blue/Green デプロイの技術的特徴にフォーカスし、 Auto Scaling との併用に焦点をあて安全かつ効率的に併用する実装方法の例を示します。
※本記事では最新の ECS built-in Blue/Green デプロイ戦略にフォーカスしますが、記事の大部分については CodeDeploy を利用したデプロイ戦略やカスタムデプロイ戦略を採用する場合にも当てはまります。また、厳密には ECS の新しいデプロイ戦略は ECS Blue/Green デプロイや ECS native Blue/Green デプロイといった表記をされることがありますが、本記事では ECS built-in Blue Green デプロイという表記で統一します。
Auto Scaling と Blue/Green デプロイの相互作用を理解する
ECS Service をベースに Auto Scaling と Blue/Green デプロイを併用している際の複雑さについて解説します。
まず、複雑になるタイミングについて、Auto Scaling は常に対象のサービスのメトリクスを読み取りスケールを判断しています。一方、Blue/Green デプロイメントは、アプリケーションの更新時のデプロイ戦略の一つであるため、デプロイタイミングで一時的にデプロイ中という状態が発生します。
従って、ユーザー視点では Blue/Green デプロイが行われるアプリケーションの更新時に、ECS Service の状態が複雑になります。
上記タイミングで発生する相互作用の複雑さの原因は、大別すると 2 つに分けられます。1 つ目は Blue/Green デプロイの環境のリソース数です。Auto Scaling は環境の情報を元にスケールアウト、スケールインを判断しますが、Blue/Green デプロイ時はユーザーのリクエストはそのままに、環境に含まれるリソースの数は一時的に 2 倍となります。そのため、環境全体ではユーザーリクエストに対して一時的に 2 倍のリソースが存在することとなり、Auto Scaling からは過剰にリソースをプロビジョンしているように見えてしまう場合があります。
2 つ目はリソースの内部状態です。Green 環境のリソースはデプロイ後十分に初期化処理が終了するまでは不安定な状態にあります。Green 環境には最初トラフィックが流れないため、リソースの使用量が少ないことが想定されますが、初期化処理によってはリソースが激しく消費され、追加のリソースが必要、と判断されてしまう可能性があります。
なお、2 つの複雑さを説明しましたが、多くの場合 1 つ目の複雑さ、つまり Blue/Green 中のリソース数の一時的な増加による、本来より小さいメトリクスの値の報告の方が重要度が高い場合が多いです。後者はスケールアウトを招く可能性がある一方、前者であるこれはスケールインを招くことから、サービスの提供そのものに影響を与える可能性があるからです。
ECS Service における Application Auto Scaling と Blue/Green デプロイメント戦略の詳細
前章では、一般的な Blue/Green と Auto Scaling の併用による複雑さについて説明しました。
具体的なサービスや機能ではこれらの点を部分的にカバーしている場合もあります。ECS で本テーマについて考える際には、以下 5 つの点を押さえる必要があります。
1. デフォルトのメトリクスは Blue 環境と Green 環境のリソースを統合的に扱う
ECS のターゲット追跡ポリシーで提供するデフォルトのメトリクス設定のうち、「ALBRequestCountPerTarget」は現時点で Blue/Green デプロイに対応していません。残りの「ECSServiceAverageMemoryUtilization」、「ECSServiceAverageCPUUtilization」は、いずれも ECS Service がディメンションであるメトリクスです。つまり ECS Service に含まれる、各 ECS Task のリソース使用率の平均を元にスケールを判断します。つまり、Blue/Green 中はタスクが 2 倍になることで本来の値より低い値となる可能性があります。
ブルー/グリーンデプロイタイプでは、ターゲット追跡スケーリングポリシーの ALBRequestCountPerTarget メトリクスはサポートされません。
2. ECS はデプロイメント中はスケールインのみ無効化する
ECS Service のデプロイ中は、外部デプロイコントローラーを使用する場合を除き、スケールインのみ無効化されます。これは Application Auto Scaling による意図しないタスク削除を防ぐための保護メカニズムで、スケールアウトは通常通り動作を継続します。
対象となる ECS Service における Blue/Green の切り替えにかかる時間が非常に短い場合、こちらの性質を活用するだけで十分な可能性もあります。
Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。
注意点として、デプロイが終了した時点からスケールインのプロセスも有効になります。スケールイン実施判断に使用されるメトリクスは Blue/Green 中に出力されたメトリクスを含むため、厳密にはデプロイ完了直後において本来必要のないスケールインが発生するリスクが存在します。こちらは 4 で解説します。
3. ロールバック機能
Blue/Green デプロイメントではロールバックの機能がありますが、これはデプロイメントプロセス中の中で行われます。したがってロールバックが終了するまでがデプロイメントの範囲となるため、スケールインは無効化されます。
そのため、ロールバックの発生に関して特別な設定は必要ありません。しかし、ロールバックを選択する際は、通常のデプロイが意図通り成功しなかったと言うことであり、デプロイにかかっている時間が増加している可能性があります。そういった場合に意図せずスケールインされないかについては確認する必要があります。
4. ターゲット追跡スケーリングの参照範囲とデプロイ時間の関係
ECS のターゲット追跡ポリシーで提供するデフォルトのメトリック設定を適用した場合、スケールアウト方向には過去3データポイント（3分間）のメトリックが、スケールイン方向には過去15データポイント（15分間）のメトリックを対象に基準値との相違点や距離を判定します。
Blue/Green によるデプロイ時間が短い場合は問題ないと考えられる一方、15分以上デプロイに時間がかかる場合、本来より低いメトリックの値が15分以上記録されることになります。 2. で述べたとおり ECS ではデプロイ中のスケールインは無効化されているものの、デプロイ明け直後にはスケールインが可能となるため、デプロイ明け直後にスケールインが走るリスクがある場合は、ポリシーを見直す必要があるでしょう。
5. ECS で推奨されるユーザーのカスタマイズ範囲
以下の通り、ECS Service に対して Auto Scaling を設定する際は、事前定義された設定を利用する、もしくは Auto Scaling でカスタムのメトリクスを利用する方法の 2 種類になります。
この際、以下の通り自動で作成される Amazon CloudWatch Alarm の設定の変更については推奨されていません。つまり、アラームの発火に使用するデータポイント数の設定などの変更が現状は非推奨であるため、スケールインに使用されるデータポイントの期間の範囲が15分であることの変更等は現時点では難しい、といった状況に注意する必要があります。なお、ステップスケーリングではデータポイントの数の変更については明記されていませんので注意してください。
ターゲットメトリクスを使用して Amazon ECS サービスをスケールする
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html
ターゲット追跡スケーリングポリシーのためにサービスの自動スケーリングが管理する CloudWatch アラームを編集または削除しないでください。スケーリングポリシーを削除するときに、サービスの自動スケーリングはアラームを自動的に削除します。
ECS Service における Application Auto Scaling と Blue/Green デプロイメント戦略の併用の例
ここまでの内容を踏まえると、まずは ECS のデフォルトの仕組みで十分対応可能であるかどうかについて検討する必要があります。失敗時のケース等を含め、デプロイ時間が十分に短い等、リスクを許容し併用するといった意思決定もありうると思います。
スケールイン等のリスクが許容できない場合、Green リソースの追加による一時的なリソースの増加に対応する必要があります。ここからは特にスケールインのリスクに対する対応の例を3つ示します。これらの例で対応可能な場合は併用を採用し、それでも要件上難しい場合は併用しないといった意思決定をとることになります。
なお、以下説明で頻出する、ECS Service におけるカスタムのメトリクスやアラームを設定する具体的な方法については以下のブログを参考ください。
カスタムメトリクスに基づいた Application Auto Scaling による Amazon ECS サービスのオートスケール | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/autoscaling-amazon-ecs-services-based-on-custom-metrics-with-application-auto-scaling/
パターン1: 「本来のタスク数をベースとしたリソース使用率を算出するカスタム設定されたアラーム」を使用するターゲット追跡スケーリングポリシーを設定する
この方法は、スケールインの懸念に対する対応として有効です。
ECS のメトリクスでは、Blue/Green 中も値が変化しないメトリクスとして、DesiredTaskCount が利用可能です。そのため、例えば Container Insights のメトリクスを利用し、以下のような式に対してアラームを設定することで、本来のタスク数を分母とした CPU 使用率に近い値を導出することができます。
式
CPUUtilization * RunningTaskCount / DesiredTaskCount
各メトリクスの説明
- DesiredTaskCount: ECS Service で設定した必要なタスクの数
- RunningTaskCount: 現在 RUNNING 状態にあるタスクの数
- CPUUtilization サービスに属するタスクで使用されている CPU ユニットの総数を、サービスに属するタスク用に予約されている CPU ユニットの総数で割った値
パターン2: 「バックエンド ECS Task に依存しないカスタムメトリクスを活用するカスタムアラーム」を使用するターゲット追跡スケーリングポリシーを設定する
ECS Task の前段に配置される ALB の TargetResponseTime や NewConnectionCount などのメトリクスは、Blue/Green 中もリソースの状態が変化しません。そのため、実際のリソース使用状況ではなく間接的な値となるものの、これらを利用することで この方法は、 ECS Task の状態に依存しないため、スケールイン方向、スケールアウト方向いずれの方向においても一貫した値をベースにBlue/Green 中もスケールを判断することができます。
式
TargetResponseTime
NewConnectionCount
パターン3: ECS Service に対して複数のターゲット追跡スケーリングポリシーを設定する
ECS では一つの ECS Service に対して複数のターゲット追跡スケーリングポリシーを設定できます。この場合、スケールアウト方向にはいずれか 1 つのメトリックが閾値を超えれば良いのに対し、スケールインでは全てのメトリックが条件を満たす必要があります。
ターゲットメトリクスを使用して Amazon ECS サービスをスケールする – Amazon Elastic Container Service
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html
Amazon ECS サービスに対して複数のターゲット追跡スケーリングポリシーを設定できます。ただし、各ポリシーがそれぞれ異なるメトリクスを使用している必要があります。サービスの自動スケーリングの目的は常に可用性を優先することであるため、その動作は、スケールアウトまたはスケールインに対するターゲット追跡ポリシーの準備が整っているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分がオン) でスケールインする準備ができている場合にのみスケールインされます。
従って、現在設定しているポリシーに追加で、Blue/Green 中に発火しにくい、低い値のターゲット追跡スケーリングポリシーを設定することで、スケールアウト方向にはこれまでと同じ速度である一方、スケールインについてはより緩やかな実施を実現することが可能です。この方法はこれまでのパターンと併用することが可能です。
まとめ
本記事では、ECS built-in Blue/Green デプロイメントとApplication Auto Scaling の効果的な併用方法について包括的に解説しました。従来の運用では、Auto Scaling と Blue/Green の併用時に発生する技術的課題を回避するため、デプロイ中の Auto Scaling 停止という対処法が一般的でしたが、これによりトラフィック増加への対応不可、デプロイ頻度の制限、運用工数の増加といった新たな課題が生じていました。
本記事では、サービスによっては既存の ECS の仕組みに任せたり、カスタムのメトリクスを設定することで Auto Scaling と ECS Blue/Green デプロイを設定変更せず併用する余地があることを示しました。また、その背景となる Auto Scaling と Blue/Green デプロイの相互作用の仕組みを明らかにし、ユーザーのより高度な活用の基礎となる要素を示すことができたと考えています。
ECS built-in Blue/Green デプロイメントと Auto Scaling の組み合わせは、現代のクラウドネイティブアプリケーション運用において、可用性、効率性、アジリティのすべてを同時に向上させる強力なソリューションです。ビジネスやサービスの要件に応じて適切な選択をする際に、本記事がその一助となれば幸いです。