こんにちは。ニフティの おおい です。

今回はAmazon ECSの組み込みBlue/Greenデプロイ機能を活用して、AWS Lambdaによる自動テストを実施することで、安心してAPIをリリースできるようにしてみました。

はじめに

2025/7/17にリリースされたECSの組み込みBlue/Greenデプロイですが、デプロイの途中で自前のLambda関数を実行することができ、この関数が特定の値 (SUCCESSFUL、FAILED、IN_PROGRESSのいずれか) を返すことでデプロイの制御をすることができます。

この機能を使ってLambda関数による自動テストを組み込むことにより、安心してAPIをリリースできるようにしてみましたのでその事例をご紹介します。

アーキテクチャ概要

今回構築したものは以下の要素で構成されています：

• ECSサービス：Blue/Greenデプロイメント戦略を設定
• Application Load Balancer：本番用とテスト用のリスナーをポート違いで設定
• ターゲットグループ：メイン用と代替用の2つを用意
• Lambda関数：テストトラフィック移行後の自動テスト実行処理
• S3バケット：テストケースの定義ファイルを格納

ポイント

今回のキモとなるのはLambda関数とS3バケットに格納されるテストケースの定義ファイルの2つです。

またテスト用のフレームワークは利用せず、なるべくシンプルにテストができるようにしました。

テストケースの定義ファイル

今回はtomlで記述しました。tomlを選んだ理由は下記2点です。

• 後述のLambda関数をPythonで書いたので特別なライブラリ無しでパースができるため
• 可読性が高く人間が定義するのに難儀しないため

例)

[general]ブロックにはテスト全体で利用する基本的な設定を、[[test_cases]]ブロックにはタイトルとテスト対象のエンドポイントを、[[test_cases.assertions]]ブロックにはどの項目(→target)がどういう値であることを期待するか(→expected)の設定を書いています。

Lambda関数

この関数はECSの組み込みBlue/Greenデプロイ中、テストトラフィック移行後に実行するように設定します。

内容としても特別なことをしておらず、

1. S3バケットからテストケースの定義ファイルを持ってくる
2. ファイルの内容を読み取る
3. テストケースの数だけAPIリクエストを実行→アサーションを繰り返す

と処理するように書いています。

ただこの関数実行後にデプロイをどうするべきかを決めなければいけませんので、失敗したテストケースのタイトルを配列として持っておいて、最終的にその配列が空であれば{"hookStatus": "SUCCEEDED"}を返して本番トラフィックをGreen環境に流すように、配列に要素があれば{"hookStatus": "FAILED"}を返してデプロイをロールバックするようにしました。

さらに失敗したテストケースのタイトルを持つようにしたので、ログ出力によって失敗したテストが何なのかをCloudWatch Logsから確認でき、次に何をすべきかがわかるようになるのがうれしいポイントです。

CI/CDとの連携

GitHub Actionsの中で

• テストケースの定義ファイルをS3バケットにコピー
• ECSサービスの更新

の2点を行うように実装すれば、ワークフローを起動するだけで安心してデプロイができるようになります。

さいごに

ECSの組み込みBlue/GreenデプロイとLambda関数による自動テストの組み合わせによりこれまでよりも楽なAPIのリリースを実現できます。特に、テストトラフィック移行後にLambda関数を実行することで、本番影響を与えないで新バージョンの品質を確保できる点が大きなメリットです。

ECSの組み込みBlue/Greenデプロイはリリースされてから時間がたっておらず、手探りの状態で構築してみました。数ある事例の一つとして参考にしていただけたら嬉しいです。