この記事は Safie Engineers' Blog! Advent Calendar の15日目の記事です。
はじめに
こんにちは、Safie でサーバーサイドエンジニアをしている金成といいます。 今回は AWS ECS Blue/Greenデプロイをサービスに導入してみたので、そちらについて共有させてください
AWS ECS Blue/Green デプロイは今年になって有効化された機能で、今迄は ECS ではローリングリリースのみ、Blue/Green デプロイをやる場合は CodeDeployを使う必要がありました。 今回の機能追加で、ECSのサービス設定の変更と関連リソースを追加することで、ECSの設定のみで Blue/Greenデプロイができるようになりました。
今回、自分たちのチームで運用しているサーバーについて、適用してみました
- はじめに
- 背景とモチベーション
- リリースの手法
- B/G デプロイのフロー
- ECS における B/G デプロイの選択肢
- Lifecycle Hooks によるリリース安全性向上
- 制限事項とハマりポイント
- 現状の課題と今後の展望
- おわりに
背景とモチベーション
現在、自分のチームでは、認証サーバーの運用をしています。 こちらは多くのサービスで利用されるため、リリースの際の障害のリスクを最小限に抑えることが課題でした。 特に、環境差分に起因する障害や考慮漏れなどはstaging環境でのチェックから漏れやすく、サービスの安定性を脅かすリスクとなっていました これらの課題を解決するため、我々は既存のデプロイ手法を見直し、より安全性の高いリリースプロセスへと改善を図ることにし、新に導入された Blue/Green デプロイを利用することにしました。
リリースの手法
ローリングリリース
現在、ECSのデフォルトでよく採用されているのはローリングリリースです。 一部のサーバーから新しいバージョンを段階的に適用していくデプロイ方法です。サービスを停止せずにデプロイすることができます. Blue/Green デプロイと比べるとロールバックに時間がかかり、一時的に新旧サーバーが混在するデメリットはありますが、インフラの構成自体はシンプルで管理しやすいです。
Blue/Green デプロイ
Blue(旧環境)と Green(新環境) を作成し、トラフィックを切り替えることでデプロイする手法で Blue環境は落とさずに、一定時間残すため、問題発生時のダウンタイムが少なくなります。ローリングデプロイの切り替えにはタスクの起動を待つ必要がありますが、トラフィックの切り替えで済むため、早くロールバックができます. 一方、インフラの構成が増え、デプロイの複雑さは増します。また、管理するリソースが増えます。
認証サーバーのようにサービスレベルが高い、リスクを最小にしたい場合には、ロールバックを早く確実に実現できる Blue/Green デプロイは有効な選択肢になると思います
B/G デプロイのフロー
B/G デプロイは、以下の手順で進みます。問題発生時の切り戻しポイントが明確で、手順5〜6の間であれば、即座にBlue環境（旧環境）にトラフィックを戻すことが可能です。
- 初期状態: Blue環境 (旧バージョン) にトラフィックが流れている。
- Green環境 (新バージョン) を構築。
- テスト用トラフィックをGreen環境に流し、動作検証を実施。
- 本番トラフィックをGreen環境へ一部または全体に段階的に移行。
- トラフィックがGreen環境に100%切り替え。
- 一定期間の監視後、Blue環境を停止。
出典: Amazon ECS blue/green service deployments workflow Webページ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-how-it-works.html (2025年12月9日アクセス)
ECS における B/G デプロイの選択肢
AWSでは、ECS環境でB/Gデプロイを実現する方法として、以下の2種類が提供されています。
- CodeDeploy を使う（従来の方式）
- ECS B/G デプロイを使う（ECS サービス設定に統合された新しい方式）
| 比較項目 | CodeDeploy 連携 | ECS B/G デプロイ (NEW) |
|---|---|---|
| トラフィック移行 | 豊富 (Canary, Linear, AllAtOnceなど比率を自由に設定可能) | 現状は AllAtOnce のみ。 |
| 設定管理 | CodeDeploy側で設定。 | ECSサービス定義に統合され、管理がまとまる。 |
| 戦略切り替え | 複雑。 | ローリング ↔ B/G の変更がサポートされており比較的楽。 |
| 検証フック | Lifecycle Hooks (固定タイムアウト) | Lifecycle Hooks (柔軟なタイムアウト設定が可能) |
自分たちは、設定管理の容易さと、将来的なローリングリリースへの切り戻しの容易さを評価し、ECS B/G デプロイを選択しました。
Lifecycle Hooks によるリリース安全性向上
ECS B/G デプロイおよび CodeDeployには、Lifecycle Hooksという非常に重要な機能があります。 これはデプロイの特定のステージ（例: トラフィック切り替え前）で、カスタムの検証ステップ（AWS Lambda）を実行し、その検証が成功するまでデプロイの進行をブロックできる機能です。 フックの利用イメージ: 新しいGreen環境にトラフィックが流れる前に、Health Checkや簡単なSmoke Test用のLambdaを実行し、環境起因の設定ミスがないかを自動的に検証できます。 これにより、トラフィックを本番環境に切り替える前に、設定ミスなどによる障害リスクを大幅に低減し、より安全にデプロイを進めることが可能になります。
Safieでは、簡単なSmoke Test用のLambdaを本番トラフィック切り替え前に実行し、チェックした上でデプロイできるように変更しました
制限事項とハマりポイント
導入にあたり、いくつかの注意点と制限事項に直面しました。
1. B/G → ローリングへの切り替え時
B/Gデプロイ設定を解除しローリングに戻した直後のデプロイで、内部的にB/Gデプロイの設定（例: ロール）を参照し続けることがありました。この影響で、新規デプロイができなくなる事態が発生しました。（1敗） => 不必要なIAMロールの削除は慎重に行う必要があります。
2. ALBリスナールールの制限
ALBの設定で、リスナールール数の上限があります（アカウントやリージョンにより異なる可能性あり）。B/Gデプロイではトラフィック切り替えにリスナールールを利用するため、多くのリスナールールを使用している既存のALBでは、B/Gデプロイの導入が難しい場合があります。
現状の課題と今後の展望
ローリングリリースから Blue/Greenデプロイに切り替えることで、素早いロールバック、デプロイ前の検証ができるようになりました。 ただし、検証はごく簡単なもので、特定のユースケースの考慮漏れをカバーできず、選択できるデプロイ戦略にも制限があります (例えば, CodeDeployと違いカナリアリリースはできない)*1
今後の展望として、E2E/統合テストとの組み合わせや、AWS ECS 今後の機能追加に合わせてより柔軟なデプロイができるように検討をすすめる予定です。
もし、似た課題をもつ方がいれば、導入を検討してみてはいかがでしょうか？
おわりに
最後になりますが、セーフィーではエンジニアを積極的に募集しています。気になる方はこちらをご覧ください！ https://safie.co.jp/teams/engineering/ カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 最後までお読みいただき、ありがとうございました。
*1 2025/10/30 ~ で AWS ECS は リニアデプロイ と カナリアデプロイのサポートを開始してます (https://aws.amazon.com/jp/about-aws/whats-new/2025/10/amazon-ecs-built-in-linear-canary-deployments/)
