DOPSDLC の自動化
ある開発チームは、AWS CodeDeployを使用してAmazon ECS (Fargate) 上にコンテナ化されたアプリケーションをデプロイしています。
新しいバージョンをリリースする際、以下の戦略を導入したいと考えています。
・まず10%のトラフィックのみを新しい環境にルーティングする
・5分間エラー率を監視する
・問題がなければ残りの90%のトラフィックを自動的に切り替える
この要件を満たすための設定として正しいものはどれですか。
ACodeDeployのデプロイ設定で「CodeDeployDefault.ECSLinear10PercentEvery5Minutes」を指定してデプロイメントグループを作成する
Linearデプロイメント設定は、最初の移行後も指定された間隔(この場合は5分ごと)で段階的にトラフィックの移行(10%ずつ)を継続する方式です。指定された待機時間後に残りの全トラフィックを一括で切り替えるという問題の要件には合致しないため不適切です。
BCodeDeployのデプロイ設定で「CodeDeployDefault.ECSCanary10Percent5Minutes」を指定してデプロイメントグループを作成する
✓ 正解
Canaryデプロイメント設定は、指定された割合(10%)のトラフィックをまず新しいバージョンに移行し、設定された時間(5分)待機して評価を行った後、問題がなければ残りのトラフィック(90%)を一括で切り替えるという挙動となり、要件を完全に満たします。
CECSサービスの更新戦略で「RollingUpdate」を選択し、ヘルスチェックの猶予期間を300秒(5分)に設定してタスクを入れ替える
ECSのRollingUpdate(ローリングアップデート)戦略は、既存のタスクを指定された割合で徐々に新しいタスクに置き換える手法ですが、ALBを使用した細かいトラフィック割合の制御や、指定時間の待機後に全トラフィックを一括で切り替えるCanary特有の制御はできません。
DApplication Load Balancerのリスナールールで、TargetGroupの重みを10%と90%に手動で分割し、5分後にスクリプトで更新する
ALBの加重ルーティングを手動やカスタムスクリプトで変更するアプローチは技術的には可能ですが、CodeDeployがネイティブに提供している機能を再発明することになり、運用オーバーヘッドや障害リスクが増大するため、DevOpsのベストプラクティスとしては不適切です。
解説
選択肢AのCodeDeployDefault.ECSLinear10PercentEvery5Minutesは5分ごとに10%ずつ段階的にトラフィックを移行するLinearデプロイ設定です。本要件は最初に10%を移行し5分後に残り90%を一括移行するCanaryパターンであるため、この設定は適合しません。
選択肢BのCodeDeployDefault.ECSCanary10Percent5Minutesは、最初に10%のトラフィックを新環境にルーティングし、5分間の待機後に残り90%を一括で切り替えるCanaryデプロイ設定です。本要件のデプロイ戦略と完全に一致しており、ECS向けブルー/グリーンデプロイで利用できるAWS提供の事前定義設定です。
選択肢CのECSサービスのRollingUpdateは既存タスクを段階的に入れ替えるローリング方式です。ヘルスチェック猶予期間を300秒に設定しても、ALBでの10%/90%トラフィック分割と自動切り替えを実現するCanaryパターンは実現できません。
選択肢DのApplication Load Balancerリスナールールで手動でトラフィックを分割する方法は、スクリプトによる手動運用が必要でCodeDeployのオーケストレーション機能や自動ロールバック機能を活用できないため適切ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →