新しいタスク定義を反映したら、タスクが起動してはすぐ消えて、デプロイがいつまでも終わらない。ログを見ようにもコンテナがもう無い。ECS を動かし始めると、一度はこの場面に当たります。慌てて設定を触る前に、どこに原因が書いてあるかを知っておけば、調べる順番は決まります。この記事では、止まったタスクの調べ方と、デプロイの失敗を止める仕組み、そして毎回手で調べなくて済む運用を説明します。
この記事の結論
- タスクが消えたら、まず止まったタスクの停止コードと停止理由を見ます。コンソールで見えるのは止まってから 1 時間です。
- サービス配下のタスクなら、サービスイベントに「止めて入れ替えた理由」（コンテナの停止、ロードバランサーのヘルスチェック失敗）が出ます。
- 起動前の失敗（イメージ取得・ロール・ネットワーク）は停止理由に、起動後の失敗はコンテナのログと終了コードに出ます。見る場所を分けます。
- ローリング更新では、サーキットブレーカーが失敗を数えてデプロイを FAILED にし、ロールバックを有効にすれば直前の COMPLETED に戻します。
- 失敗のたびに調べるより、デプロイ失敗のイベントを EventBridge で受けて通知する運用にします。
ECS のタスクが止まったとき、最初に何を見ればよいのか
最初に見るのは、止まったタスクそのものです。ECS は止まったタスクに、止まった理由を記録します。主に見るのは次の 2 つです。
- 停止コード（stopCode）: 何が原因で止まったかの分類です。
- 停止理由（StoppedReason）: 人が読める説明の文です。
ここで気をつけたいのは、コンソールで止まったタスクが見えるのは、止まってから 1 時間という点です。「あとで見よう」と置いておくと、手がかりごと消えます。タスクが消えたと気づいたら、先に停止理由を控えてから、設定を直しにいきます。
止まったタスクが一覧に出ないときは、タスクの絞り込みを「停止」に切り替えて探します。操作の画面は改定で変わるので、手順は公式の「止まったタスクのエラー」のページに任せます。
調べる順番を、先に全体で押さえておきます。
WHERE TO LOOK調べる順番
止まったタスクは停止理由 → イベント → ログ → ヘルスチェックの順に見る
-
停止コードと停止理由
止まったタスクの記録。コンソールでは 1 時間
-
サービスイベント
止めて入れ替えた理由
-
コンテナのログと終了コード
起動後の失敗の手がかり
-
ヘルスチェックの設定
パス・ポート・起動の猶予
CHECK 1ここまでの確認
起動したはずのタスクが一覧から消えていたとき、原因を探す最初の場所はどこ?
答えと解説
答え: 1. 止まったタスクの停止コードと停止理由
止まったタスクには、止まった理由が記録されます。コンソールで見えるのは止まってから 1 時間なので、早めに確認します。「ECS のタスクが止まったとき、最初に何を見ればよいのか」を読み直してください。
サービスイベントは何を教えてくれるのか
タスクが単独ではなくサービスの配下にある場合、もう 1 つの手がかりがあります。サービスイベントです。サービスは「決めた数のタスクを保ち続ける」仕組みなので、タスクが止まると新しいタスクを起動して入れ替えます。そのとき、なぜ止めて入れ替えたのかがイベントとして残ります。
たとえば、次のような理由がサービスイベントに出ます。
- コンテナが止まったので、タスクを入れ替えた
- ロードバランサーのヘルスチェックに失敗したので、タスクを入れ替えた
つまり、停止理由が「止まったタスク 1 つの記録」なら、サービスイベントは「サービスから見た、入れ替えの経緯」です。同じ事象を別の側から見ているので、両方を並べると原因を絞りやすくなります。ヘルスチェックの失敗で入れ替わっているのに、コンテナのログでは正常に見える、といったずれも、ここから気づけます。
この動きは、サービスが「数を保つ」ことの裏返しでもあります。起動しては止まるタスクを、サービスは健気に入れ替え続けます。だから、原因を直さない限り、一覧では「タスクが増えたり減ったりしている」ように見えます。
起動前に失敗したのか、起動後に失敗したのか
次に、どの段階で失敗したかを切り分けます。ここを間違えると、ログを探しても何も無い、という状況になります。
BEFORE OR AFTER失敗した段階
起動前と起動後で、見る場所が違う
起動前の失敗
停止理由に出る
- イメージを取り出せない
- 実行ロールの権限が足りない
- ネットワークに出られない
起動後の失敗
ログと終了コードに出る
- アプリが起動直後に終了する
- 設定の誤りで落ちる
- ヘルスチェックに応えられない
| 段階 | 起きがちなこと | 見る場所 |
|---|---|---|
| 起動前 | コンテナイメージを取り出せない、実行ロールの権限が足りない、ネットワークに出られない | 止まったタスクの停止理由 |
| 起動後 | アプリケーションが起動直後に異常終了する、設定の誤りで落ちる | コンテナのログと終了コード |
起動前に失敗したタスクは、コンテナがまだ動いていないので、ログは出ません。ログを見ても空なのは当たり前で、停止理由に出ている文を読みます。イメージの取得や実行ロールは、前の記事で扱った「タスク起動の流れ」のどこで使われるかと対応しています。
起動後に失敗した場合は、コンテナの出力が手がかりです。ただし、タスク定義でログドライバー（awslogs など）を設定していないと、出力は残りません。ログの置き場所を決めるのはタスク定義です。コンテナのヘルスチェックも同じくタスク定義に書くので、原因調査の入口として、タスク定義が「設計図」だったことを思い出してください。設計の考え方は別の記事で扱います。
ヘルスチェックの失敗は、起動後の失敗に入る
コンテナは動いているのに、ロードバランサーのヘルスチェックに応答できずに入れ替わる、という失敗もあります。アプリが立ち上がる前にチェックが始まっていないか、チェック先のパスやポートが合っているか、を確認します。この場合も、サービスイベントに「ヘルスチェックの失敗」と出るので、先ほどの手がかりと合わせて読みます。
停止メッセージの全種類はここに並べません。種類が多く、更新もされるため、公式の一覧を見るのが確実です。
CHECK 2ここまでの確認
ローリング更新でロールバックを有効にしたサーキットブレーカーが、デプロイを失敗と判定したとき、サービスはどこへ戻る?
答えと解説
答え: 2. 直前に COMPLETED になったデプロイ
戻る先は直前の COMPLETED のデプロイです。COMPLETED のデプロイが無いと戻る先が無く、停滞します。「サーキットブレーカーは何をするのか」を読み直してください。
デプロイが進まないとき、サーキットブレーカーは何をするのか
ここまでは「止まったタスクを調べる」話でした。次は、デプロイそのものが進まないときです。新しいタスク定義のタスクが起動と停止を繰り返すと、ローリング更新はいつまでも終わりません。
これを自動で止めるのが、デプロイサーキットブレーカーです。ローリング更新のデプロイで、新しいタスクの失敗を数え、一定を超えたらデプロイを FAILED と判定します。ロールバックを有効にしていれば、直前に COMPLETED になったデプロイへ自動で戻します。
CIRCUIT BREAKER失敗を止める流れ
失敗を数えてFAILEDにし、直前の COMPLETED へ戻す
ローリング更新
ロールバック有効時
- 新タスク起動
- 失敗を数える
- FAILED と判定
- 直前へ戻す
押さえておく点を整理します。
- 2 段で判定する: 公式の説明では、新しいタスクが RUNNING になれない失敗と、RUNNING になったあとのヘルスチェックの失敗の、2 段で見ています。起動前と起動後の切り分けと、ほぼ同じ発想です。
- デプロイの状態（rolloutState）に出る: 進行中、完了、失敗が区別されます。FAILED かどうかで、デプロイが止められたことが分かります。
- 戻る先は直前の COMPLETED: 一度も COMPLETED になったことがない最初のデプロイや、直前が COMPLETED でない場合は、戻る先がありません。そのときは停滞します。
- 対応はローリング更新のみ: ブルー/グリーンは別の仕組みです。切り替え前に検証する設計は、デプロイ方式の記事で扱います。
失敗の判定に使う回数の目安は、タスクの数などによって決まります。暗記するより、公式の仕様で確認するのが確実です。
サーキットブレーカーは、壊れたタスクが入れ替わり続けて、サービス全体が巻き込まれるのを防ぐ安全装置です。ただし、戻したあとの原因は直っていません。FAILED になったら、ここまでの順番（停止理由、サービスイベント、ログ）で原因を調べて直します。
CHECK 3ここまでの確認
サーキットブレーカーが対応しているデプロイ方式はどれ?
答えと解説
答え: 1. ローリング更新（ECS コントローラー）
公式の説明ではローリング更新向けの機能です。ブルー/グリーンは別の仕組みで、設計の記事で扱います。
毎回手で調べないための運用
止まるたびに人が調べにいく運用は、気づくのが遅れます。仕組みで受けるようにします。
- デプロイ失敗を通知で受ける: ECS はデプロイの状態変化をイベントとして出します。公式はサーキットブレーカーの使用時に、失敗のイベントを受けて通知することを勧めています。EventBridge のルールで受けて、メールやチャットに流します。
- ログを残す: タスク定義にログドライバー（awslogs）を設定すると、コンテナの出力が CloudWatch Logs に残ります。タスクが消えても、起動後の失敗を追えます。
- 見る場所を一覧にする: Container Insights を有効にすると、クラスター・サービス・タスク単位の CPU やメモリ、タスクの再起動の状況などを CloudWatch で追えます。追加の開発なしで見られる点が利点です。
- ヘルスチェックを設計に入れる: コンテナのヘルスチェックをタスク定義に書き、ロードバランサー側のチェックと整合させます。
| 手段 | 役割 | 見つけるもの |
|---|---|---|
| EventBridge のイベント | 失敗を知らせる | デプロイが FAILED になったこと |
| awslogs | 出力を残す | 起動後の失敗の原因 |
| Container Insights | 状態を見る | タスク単位のメトリクスと再起動の様子 |
通知は「気づく」ため、ログは「原因を追う」ため、Container Insights は「傾向を見る」ためで、役割が違います。1 つで全部をまかなおうとせず、組み合わせます。
CHECK 4ここまでの確認
デプロイ失敗を、人が画面を見に行かずに知るにはどうする?
答えと解説
答え: 2. デプロイのイベントを EventBridge で受けて通知につなぐ
ECS は状態変化をイベントとして出します。受け取る側のルールを作っておけば、失敗のたびに調べに行く運用から離れられます。「毎回手で調べないための運用」を読み直してください。
調べる順番のまとめ（チェックリスト）
タスクが止まる、デプロイが進まない、と感じたら、次の順に確認します。
- 止まったタスクの停止コードと停止理由を控える（1 時間で消える）
- サービスイベントで、止めて入れ替えた理由を見る
- 起動前の失敗なら停止理由を読む。起動後の失敗なら、ログと終了コードを見る
- ヘルスチェックの設定（パス・ポート・猶予）が、アプリの起動に合っているか確認する
- デプロイが止まっているなら、rolloutState を見て、サーキットブレーカーとロールバックの設定を確認する
- 次の失敗に備えて、失敗の通知とログの設定を入れる
ECS の次の判断として、EKS と比べてどちらを選ぶかはECS と EKS の選び方の記事につながります。
参照ソース
- Amazon ECS：止まったタスクのエラーの確認 — 停止コード・停止理由・コンソールで見える期間・サービスイベントの根拠
- Amazon ECS：デプロイサーキットブレーカー — 2 段の判定・rolloutState・ロールバック・ローリング更新のみ対応・失敗の通知の推奨の根拠
- Amazon ECS：監視（CloudWatch Logs などの手段） — awslogs ログドライバー・Container Insights・EventBridge・ヘルスチェックの根拠
