ある金融機関は、国内の決済処理サービスをAmazon ECS on Fargate（3アベイラビリティゾーン構成、ALBでトラフィック分散）で運用しています。毎月2回の機能リリースでは過去に本番障害が複数回発生したため、エンジニアリングリードは以下の厳格なデプロイ要件を定めました。 ・リリース中のダウンタイムゼロ ・最初は全体の10%のトラフィックを新バージョンに転送するカナリアデプロイ ・エラーレートが1%を超えた場合、5分以内に旧バージョンへ自動ロールバック ・デプロイ設定はInfrastructure as Codeで管理し、開発・検証・本番の3環境に一貫して適用 ・新バージョンのヘルスチェック通過後のみ残り90%のトラフィックを移行 上記要件を最も効果的に充足するアーキテクチャはどれですか？
AWS CodeDeployのECS Blue/Greenデプロイは、ALBリスナーに紐づくBlue（現行）とGreen（新バージョン）の2つのターゲットグループ間でトラフィックを段階移行する。「CodeDeployDefault.ECSCanary10Percent5Minutes」設定を使用することで、最初に10%のリクエストをGreenターゲットグループへ転送し5分間の観測ウィンドウ後に残り90%を自動移行するという要件を正確に実現できる。CloudWatch Alarmsをデプロイメントアラームに指定することで、エラーレートが1%を超えた時点でCodeDeployが即座にBlue環境へロールバックしALBの加重ルールを元に戻すため、5分以内の切り戻しが保証される。CloudFormationでCodeDeployアプリケーション・デプロイグループ・ECSサービス・ALBリスナーを一括IaC管理することで3環境に一貫したデプロイ設定を適用できる。 選択肢BのECSローリング更新はタスクを順次入れ替える方式であり、10%に固定したまま安定性を評価してから残り90%を移行するカナリアパターンを実現できない。サーキットブレーカーはロールバックを提供するがエラーレート閾値ベースの自動制御とは動作が異なる。 選択肢CのAllAtOnce設定は全トラフィックを即座に新バージョンへ切り替えるため段階的カナリアデプロイに反する。Route 53加重ルーティングはDNSレベルの制御でDNS TTLが存在するため、ロールバック時に即時のトラフィック切り戻しを保証できず5分以内要件を満たさない。 選択肢DのApp MeshはEnvoyサイドカーによるサービスメッシュを提供するが、ECS Blue/Greenデプロイと組み合わせるとALBとEnvoyの二重トラフィック制御が競合し設定複雑性が増大する。Step Functionsロールバックフローの追加は不要な運用オーバーヘッドとなりオーバーエンジニアリング。