AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

DevOpsエンジニア-プロフェッショナル

正解 B問題

分野1：SDLC の自動化タスクステートメント1.4：インスタンス・コンテナ・サーバーレス環境向けのデプロイ戦略の実装

1 2 3 4

次の問題前の問題

問題文と選択肢

ある製薬企業の研究支援チームは、化合物の類似度を判定する推論 API を AWS Fargate 上の Amazon ECS サービスとして提供しています。このコンテナは起動直後に Amazon S3 から約 4 GB の学習済みモデルを取得してメモリ上に展開するため、リクエストを処理できる状態になるまで平均 6 分かかります。

新しいイメージへの入れ替えを開始すると、起動した新規タスクが Application Load Balancer のターゲットグループに登録されて間もなく異常と判断され、ECS サービスがそのタスクを停止して別のタスクを起こす動きが延々と続き、デプロイが終わりません。

運用の手間を最小限に抑えてこの状況を解消する対応はどれですか。

ターゲットグループ側でヘルスチェックの間隔と非正常のしきい値を上限まで引き上げ、異常と判断されるまでの時間を稼ぐ。
ECS サービスのヘルスチェックの猶予期間を、モデルの展開に要する時間を上回る長さに設定する。
タスク定義のコンテナ定義で startTimeout に 600 秒を指定し、起動処理が終わるまで ECS が待つようにする。
デプロイ方式を AWS CodeDeploy による Blue/Green に切り替え、元のタスクセットを終了するまでの待機時間を長めに設定する。

解説頻出度★★★★★

この問題は、「起動に 6 分かかるタスク × ALB のヘルスチェックで即異常判定 × タスク置き換えの無限ループ」という典型的な症状に対し、ECS サービスのヘルスチェック猶予期間 (healthCheckGracePeriodSeconds) を当てられるかがポイントです。

A. ターゲットグループ側でヘルスチェックの間隔と非正常のしきい値を上限まで引き上げ、異常と判断されるまでの時間を稼ぐ。

ALB のヘルスチェック間隔（最大 300 秒）と非正常のしきい値（最大 10 回）を上限まで引き上げれば、計算上は 6 分を超える猶予を作れます。しかしその設定はデプロイ直後だけでなく定常運用中もずっと効き続けるため、本当に落ちたタスクの切り離しが何十分も遅れ、障害時間を伸ばします。
ECS には「タスク起動直後だけヘルスチェックを無視する」ための専用パラメータが用意されており、そちらを使うのが正しい解き方です。
症状は一時的に消えますが、可用性を犠牲にする対症療法であり不適です。

正解

B. ECS サービスのヘルスチェックの猶予期間を、モデルの展開に要する時間を上回る長さに設定する。

正解です。ECS サービスの healthCheckGracePeriodSeconds（ヘルスチェックの猶予期間） は、AWS 公式に「タスクが最初に開始された後で異常な Elastic Load Balancing、VPC Lattice、コンテナのヘルスチェックを無視する期間」と定義されています。
既定値は 0 秒のため、モデル展開に 6 分かかるタスクは準備完了前に異常と判定され、サービススケジューラに停止・再起動され続けます。猶予期間をモデル展開時間より長く（例 600 秒）設定すれば、この期間の異常判定が無視されてデプロイが完走します。
最大 2,147,483,647 秒まで指定でき、サービス定義を 1 か所更新するだけで済むため、運用の手間も最小です。

C. タスク定義のコンテナ定義で startTimeout に 600 秒を指定し、起動処理が終わるまで ECS が待つようにする。

タスク定義の startTimeout はコンテナの依存関係（dependsOn）が解決されるのを待つ上限時間を定めるパラメータで、複数コンテナの起動順序を制御するためのものです。
本問のようにコンテナ自体は正常に起動しており、ALB のヘルスチェックに応答できるようになるまでが遅いケースには何の効果もありません。
「起動が遅い」という言葉から連想させる引っかけで、設定してもタスクの置き換えループは止まりません。

D. デプロイ方式を AWS CodeDeploy による Blue/Green に切り替え、元のタスクセットを終了するまでの待機時間を長めに設定する。

AWS CodeDeploy による Blue/Green への切り替えは、デプロイ方式そのものを作り直す大掛かりな変更で、運用の手間を最小限に抑えるという要件に反します。
さらに Blue/Green でも新しいタスクセットは同じターゲットグループのヘルスチェックで評価されるため、猶予期間が 0 のままなら新タスクは同じように異常と判定されます。元のタスクセットの終了待ち時間を延ばしても、新タスク側の判定は変わりません。
根本原因（起動直後の猶予がない）に触れていない点で不適です。

これだけ覚える（記憶フック）
起動が遅くて置き換えループ＝ECS の猶予期間。ALB のしきい値をいじるのは定常監視まで鈍らせる。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
起動からリクエスト処理可能になるまで平均 6 分かかる	起動直後だけヘルスチェックを無視する仕組みが必要。ECS サービスの猶予期間がまさにその機能 →選択肢（B）が正解
ALB のターゲットグループで異常と判定 → ECS がタスクを停止して置き換えるループ	猶予期間 0（既定値）のままだとECS スケジューラが ELB の判定をそのまま採用する。判定を遅らせるのではなく無視させるのが筋 →選択肢（A）を消す
運用の手間を最小限に抑える	サービス定義のパラメータ 1 つで解決できる。デプロイ方式の全面変更は過剰 →選択肢（D）を消す
コンテナ自体は起動しており、遅いのは「応答可能になるまで」	startTimeout はコンテナの依存関係解決の待ち時間であって、ヘルスチェックとは無関係 →選択肢（C）を消す
恒久的な監視品質を落とさずに解決したい	ヘルスチェック間隔・しきい値の引き上げは定常運用中の障害検知も遅らせる副作用がある →選択肢（A）を消す

ひっかけポイント

選択肢 A は数字の上では成立してしまう（間隔 300 秒 × しきい値 10 回）ため技術的に否定しにくいが、デプロイ後もずっと効き続ける設定である点が急所。ECS には「起動直後だけ」という限定機能があるのだから、そちらを選ぶ
「ヘルスチェックの猶予期間」はECS サービス側の設定で、ALB のターゲットグループ側の設定ではない。設定場所を取り違えると選択肢 A に流れる
選択肢 C の startTimeout は「起動処理が終わるまで ECS が待つ」という説明文がもっともらしいが、実体はdependsOn の依存解決タイムアウト。名前から機能を推測させる典型的な罠
選択肢 D の Blue/Green は「デプロイの安全性を高める」定石として知られるため選びたくなるが、新タスクが unhealthy と判定される原因は解消されないうえ、運用オーバーヘッドが増える方向に働く

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「タスクは起動するがすぐ異常終了して停止コードが残る」	猶予期間ではなく、停止理由 (stoppedReason) と CloudWatch Logs の調査によるトラブルシューティングが論点に。
「ALB を使わずコンテナヘルスチェックだけで運用している」	猶予期間はコンテナヘルスチェックにも適用されるが、まずタスク定義の healthCheck の startPeriod の調整が正解軸に。
「デプロイ中に失敗を検知したら自動的に切り戻したい」	ECS のデプロイサーキットブレーカー（ロールバック有効）や CodeDeploy の自動ロールバックが正解軸に。
「4 GB のモデル取得そのものを速くして起動時間を短縮したい」	モデルをイメージに同梱する、Amazon EFS をマウントする、Fargate のイメージキャッシュ活用などが論点に変わる。
「新旧タスクが同時に稼働する台数を制御したい」	サービスの minimumHealthyPercent / maximumPercent の調整が正解軸に。

AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

A. ターゲットグループ側でヘルスチェックの間隔と非正常のしきい値を上限まで引き上げ、異常と判断されるまでの時間を稼ぐ。

B. ECS サービスのヘルスチェックの猶予期間を、モデルの展開に要する時間を上回る長さに設定する。

C. タスク定義のコンテナ定義で startTimeout に 600 秒を指定し、起動処理が終わるまで ECS が待つようにする。

D. デプロイ方式を AWS CodeDeploy による Blue/Green に切り替え、元のタスクセットを終了するまでの待機時間を長めに設定する。

次の問題 前の問題

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報