Lambda の段階的デプロイと自動ロールバック
ニュース配信サービスを運営する企業が、Amazon CloudFront、Amazon API Gateway、AWS Lambda 関数で構成されたサーバーレスアプリケーションを本番稼働させています。現在のデプロイ手順では、担当者が Lambda 関数の新しいバージョンを発行し、AWS CLI のスクリプトを実行して切り替えています。新バージョンで不具合が見つかった場合は、別の CLI スクリプトを実行して旧バージョンへ戻します。同社は、新しいアプリケーションロジックをデプロイするまでの時間を短縮し、あわせて障害の検出と切り戻しに要する時間も短縮したいと考えています。これを実現する最適なソリューションはどれですか。
解説を読む（正解: B）
サーバーレスアプリケーションのデプロイでは、AWS SAM がテンプレートの DeploymentPreference によって AWS CodeDeploy との統合をネイティブに提供している点が鍵になります。この仕組みでは、Lambda 関数のエイリアスに対して重み付けされたトラフィックシフトを行い、Canary10Percent5Minutes や Linear10PercentEvery1Minute といった定義済みの方式で新バージョンへ段階的に切り替えられます。さらに、切り替え前に実行する PreTraffic フックと切り替え後に実行する PostTraffic フックで自動検証を挟むことができ、指定した Amazon CloudWatch アラームが ALARM 状態になると CodeDeploy がデプロイを自動的に中止して旧バージョンへ即座に切り戻します。これにより、デプロイ時間の短縮と、障害検出および切り戻し時間の短縮という双方の要件を同時に満たせるため、選択肢 B が正解です。選択肢 A は、CloudFormation の変更セットに自動的な段階リリースや自動ロールバックのトリガーが備わっておらず、切り戻しは手動で別の変更セットを適用する運用になるため改善効果が限定的です。選択肢 C は、既存の手続き型スクリプトをまとめ直すだけで、段階的なトラフィック移行も自動ロールバックも実現できず、検出は依然としてデプロイ後のテスト頼みです。選択肢 D は、エンドポイントを増やして CloudFront のオリジンを人手で切り替える方式であり、伝播に時間がかかるうえ、監視と切り戻しが自動化されないため要件を満たしません。
ECS 決済 API のカナリアデプロイと自動ロールバック
ある決済プラットフォームは Amazon ECS on AWS Fargate 上で API を稼働させ、Application Load Balancer で受け付けています。同社はリリース起因の障害を減らすため、新バージョンをまず本番トラフィックの 10 パーセントに 10 分間だけ流し、HTTP 5xx 率と p99 レイテンシを監視して問題がなければ残りを一括で切り替える方式を採用したいと考えています。異常を検知した場合は 5 分以内に自動で旧バージョンへ切り戻す必要があります。データベーススキーマは新旧バージョン間で後方互換が確保されています。デプロイ処理の運用は最小限にとどめたいと考えています。最も適切なソリューションはどれですか。
解説を読む（正解: B）
AWS CodeDeploy の Amazon ECS 向け Blue/Green デプロイは、ALB の 2 つのターゲットグループとリスナーを CodeDeploy が制御し、あらかじめ定義されたデプロイ設定に従ってトラフィックを段階的に移す仕組みです。Canary10Percent10Minutes は最初に 10 パーセントを新しいタスクセットへ振り向け、10 分間経過後に残り 90 パーセントを一括で切り替えるという、この要件そのままの組み込み設定です。B ではさらにデプロイグループに CloudWatch アラームを関連付けることができ、デプロイ中にアラームが ALARM になると自動ロールバックが起動して、まだ稼働している旧タスクセットへリスナーを戻すだけで完了するため、切り戻しが短時間で済み 5 分以内という要件を満たします。A のローリングアップデートは新旧タスクが混在するだけで指定比率のカナリアを表現できず、切り戻しも人手であるため自動ロールバックの要件を満たしません。C は DNS ベースの切り替えであり、リゾルバーやクライアント側のキャッシュが TTL を超えて残ることがあるため、5 分以内に確実に旧環境へ戻す保証がなく、ALB を二重に持つコストも増えます。D は加重ターゲットグループ自体は妥当な手段ですが、判定と切り戻しが人手であり、EventBridge のスケジュールは健全性を評価せず時間だけで昇格させてしまうため、自動ロールバック要件を満たさず運用負荷も残ります。
CloudFormation 変更による本番障害を抑える CI/CD の改善
動画字幕を自動生成する SaaS を提供する企業が、AWS CodePipeline で Amazon EC2 Auto Scaling グループ上の推論サービスを継続的にデリバリーしています。インフラストラクチャはすべて AWS CloudFormation テンプレートで定義され、アプリケーションの実行ファイルとモデルライブラリは Amazon S3 バケットに置かれ、EC2 のユーザーデータスクリプトで Auto Scaling グループへ配布されています。機能追加と新しい音声認識モデルの導入が続いた結果、近ごろは CloudFormation テンプレートの変更が予期せぬサービス停止を招くことが増え、顧客からの苦情も出ています。テンプレート変更が本番障害につながる可能性を抑えつつ、デプロイの信頼性と効率を高めるために、ソリューションアーキテクトはパイプラインをどのように改善すべきですか。
解説を読む（正解: B）
CI/CD の信頼性向上は、本番へ届く前に欠陥を検出する仕組みと、届いてしまった欠陥の影響時間を短縮する仕組みの両輪で考えます。AWS CodeBuild をパイプラインに組み込んで自動テストを実行すれば、コミットごとに回帰を検出でき、手動テストのように実行漏れや属人化が起きません。CloudFormation の変更セットは、スタック更新を実行する前に「どのリソースが作成・更新・置換されるか」を提示する機能で、リソースの置換 (Replacement) によるダウンタイムを事前に把握して危険な変更を止められるため、本問で顕在化しているテンプレート変更起因の障害に直接効きます。さらに AWS CodeDeploy によるブルー/グリーンデプロイは、新環境へ切り替える前に検証でき、問題があればトラフィックを旧環境へ戻すだけで復旧できるため、平均復旧時間を大幅に短縮します。この 3 点を組み合わせた B が正解です。A はエラー検出が事後的で、しかも中核が人手によるテスト計画であるため、実行のばらつきと遅延を排除できません。C も IDE プラグインと構文検証は文法エラーしか捕捉できず、変更セットによる影響評価やロールバック機構がないうえ、最終判断が手動テストに依存します。D はブルー/グリーンデプロイという有効な要素を含みますが、自動テストと変更セットによる事前評価が欠けており、検証を人手のチェックリストに委ねているため、リリース頻度が上がるほど破綻します。