ECS B/GデプロイとStep Functionsによる自動E2Eテスト

参考になった

レビュー投稿日の情報になります

セーフィー株式会社 / 金成朗史

メンバー / バックエンドエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 11名〜50名

最終更新日2026/05/27投稿日2026/05/28

ツールの利用規模

ツールの利用開始時期

事業形態

11名〜50名

2025年12月

B to B

B to C

ツールの利用規模

11名〜50名

ツールの利用開始時期

2025年12月

事業形態

B to B

B to C

アーキテクチャ

本番環境にデプロイしてみるまで、「本当の意味」での動作保証ができなかったことです。具体的には下記の3点です。

サービス間連携の不確実性: 認証サーバーは多くのプロダクトの起点となるため、SDKや外部サービスとの連携が生命線です。従来のCIでのテストは外部をモック化していたため、本番相当の環境でしか起きない「疎通の不整合」を事前に防げませんでした。
環境差分による事故: コード自体が正しくても、本番環境の環境変数の設定ミスや、インフラ構成の微細な差分によって発生するエラーを、デプロイ前に検知する仕組みがありませんでした。
リリースの心理的プレッシャー: 影響範囲が広大であるため、リリースのたびに手動確認が必要となり、エンジニアにとって大きな心理的負荷と工数が発生していました。

壊れたものをユーザーに届けない、万が一の際も即座に無傷で戻れることを目指しました。具体的には下記の3点です。

安全な失敗ができる基盤: ECS B/Gデプロイのテストトラフィックを活用し、ユーザーに影響が出る前の隔離された新環境で全ての検証が完了している状態。
リリース判断の完全自動化: Step FunctionsによるE2Eテストの結果をトリガーに、機械的にトラフィックの切り替えまたはロールバックが行われる状態。
本番環境との差分をほぼゼロに: 認証フロー（特にAuthorization Code Flowなどの込み入ったフロー）が、本番と全く同じネットワーク経路・設定値で正常動作することをデプロイパイプラインの中で証明できている状態。

本番環境に起因する致命的なデグレをリリース前にある程度は遮断できる状態になりました。

破壊的変更の検出: 主要な認可フローをデプロイパイプライン内で自動検証するため、意図しない仕様変更が本番に混入するリスクはほぼ解消されました。
本番特有エラーの事前検知: テストトラフィックを利用して「本番と同じ設定値（環境変数・ネットワーク）」でテストを実行するため、デプロイ後の「環境差分による起動失敗」をリリース前に検知できるようになりました。
影響範囲のコントロール: 以前は「リリース後に手動で確認して、ダメなら手動で戻す」という状態でしたが、現在はStep Functionsがテスト失敗を検知した瞬間に、ユーザーに影響が出る前に自動ロールバックが走るようになっています。

最大の成果は、リリースボタンを押す際の心理的ハードルが劇的に下がったことです。

リグレッションテストの自動化: 認可フローなど主要ユースケースが毎回自動で走るため、コード修正時の「どこか壊れていないか」という不安がなくなりました。
「安全な失敗」の確立: 失敗が許容されるパイプラインを構築したことで、チーム全体に「もしテストが落ちても、システムが勝手に守ってくれる」という安心感が浸透しました。