ある企業が AWS CodePipeline と CodeBuild を使ったデプロイパイプラインを運用していますが、本番デプロイ後に障害が発生した場合の復旧時間（MTTR）が長いという問題があります。現在のデプロイはすべてのインスタンスを同時に更新するローリングデプロイで、問題が検出された時点では既に全インスタンスが更新されています。デプロイリスクを軽減し、問題発生時の即時ロールバックを実現するためのアーキテクチャ改善はどれですか？
- A. AWS CodeDeploy を使って Blue/Green デプロイメントに切り替える。新バージョン（Green 環境）を ALB の別ターゲットグループにデプロイし、CloudWatch Alarm でエラー率や P99 レイテンシーを監視して、アラームが発火した場合は自動的に Blue 環境（旧バージョン）に即時ロールバックする
- B. デプロイ前に必ずステージング環境でテストを実施し、テスト合格後のみ本番デプロイを許可するゲートを CodePipeline に追加する
- C. AWS Elastic Beanstalk に移行し、Beanstalk の組み込みデプロイ戦略（Rolling with additional batch）を使用する
- D. AMI ゴールデンイメージを毎リリースで作成し、Auto Scaling グループの起動テンプレートを更新して新しい AMI に切り替える
解答と解説を見る
正解: A
Blue/Green デプロイメントはゼロダウンタイムのデプロイと即時ロールバックを実現する最も効果的な方法です。CodeDeploy の Blue/Green では新バージョン（Green）を完全にデプロイした後、ALB のルーティングを切り替えます。CloudWatch Alarm との統合でエラー率や P99 レイテンシーの悪化を自動検出し、ALB のルーティングを瞬時に Blue（旧バージョン）に戻すロールバックが実現できます。 B: ステージング環境のテストゲートはデプロイ前の品質確保に有効ですが、本番特有の問題（本番トラフィックパターン、データ量など）への対応や、本番デプロイ後の即時ロールバック要件を満たしません。 C: Elastic Beanstalk への移行は大きなアーキテクチャ変更を要し、「Rolling with additional batch」も部分的なロールバックには複雑な手順が必要で、即時ロールバックを保証しません。 D: AMI ゴールデンイメージへの切り替えは時間がかかり（新インスタンスの起動・ウォームアップ）、即時ロールバックの要件を満たしません。
📚 関連サービスの解説: AWS CodeDeploy ・ Elastic Load Balancing（ELB）