ECSとSystems ManagerによるAWS死活監視設計｜コンテナ異常の自動検知と復旧構成

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ ECSとSystems ManagerによるAWS死活監視設計｜コンテナ異常の自動検知と復旧構成
「ECSのタスクが何時間も異常な状態で動き続けていた。ステータスはRUNNINGのままだったので、誰も気づけなかった」
コンテナ環境で起きやすいのは、このようなケースです。

プロセスは起動しているが、アプリケーションの内部では処理が止まっている。
コンテナのステータスだけを確認していると、このような異常を見逃します。

この記事では、AWS ECSのヘルスチェック機能とSystems Manager（SSM）を組み合わせた、aws死活監視の設計を解説します。
コンテナの異常を自動で検知し、復旧まで自動実行できる構成の実装手順を理解できます。

ECS Fargateを使ったWebアプリのコンテナ構成を想定環境として説明します。

この記事のポイント

・ECSタスク定義のhealthCheckで、プロセスの内部状態をAWSが30秒ごとに自動確認し、失敗が続いたときにタスクを再起動できる
・ALBヘルスチェックはネットワーク到達性の確認、ECSヘルスチェックはプロセス内部の応答確認という役割の違いがある
・EventBridgeでECSのタスク停止イベントを取得し、SSMオートメーションで復旧処理を自動実行できる
・SSMパラメーターストアにヘルスチェックの設定を集中管理すると、複数サービスの死活監視を統一した運用で管理できる


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

コンテナの死活監視でオンプレミスと考え方が違う点


オンプレミスのサーバーでは、nginxやApacheが起動しているかどうかをsystemctlで確認する方法が一般的でした。
サービスが異常終了すれば、systemdが自動で再起動を試みます。

コンテナ環境では、この考え方だけでは不十分です。
コンテナのプロセス自体は起動していても、アプリケーションが応答できない状態になっているケースが発生します。

典型的な例として、次のような状態が挙げられます。

・データベースへの接続が切れてスレッドがデッドロック状態になっているが、プロセスは起動したまま
・外部APIへのリクエストがタイムアウトし続け、スレッドプールが枯渇しているが、コンテナのステータスはRUNNING
・メモリリークが進行し、GCが止まらなくなっているが、コンテナは落ちていない

このような状態を検知するには、プロセスの起動確認だけでなく、アプリケーション内部への問い合わせが必要です。
それを担うのが、ECSタスク定義のヘルスチェック設定です。

ECSタスク定義に設定するヘルスチェックの仕組み

1. healthCheckパラメーターの設定項目


ECSタスク定義のコンテナ定義に、healthCheckブロックを追加します。
以下は、Webアプリに組み込んだ/healthエンドポイントをHTTPで確認する設定例です。


# タスク定義のJSON（containerDefinitions内に追加）
"healthCheck": {
    "command": [
        "CMD-SHELL",
        "curl -f http://localhost:8080/health || exit 1"
    ],
    "interval": 30,
    "timeout": 5,
    "retries": 3,
    "startPeriod": 60
}
各パラメーターの意味は以下のとおりです。

・command：ヘルスチェックとして実行するコマンド。exit 0で正常、非0で異常と判定されます
・interval：ヘルスチェックを実行する間隔（秒）。デフォルトは30秒
・timeout：コマンドの実行が終わるまで待つ時間（秒）。デフォルトは5秒
・retries：UNHEALTHYと判定するまでに失敗を許容する回数。デフォルトは3回
・startPeriod：コンテナ起動直後に判定を猶予する時間（秒）。初期化が長いアプリに設定します

コマンドにはcurlを使う例が一般的ですが、curlをインストールしていない軽量イメージでは、代わりにwgetやPythonを使う方法もあります。

2. ヘルスチェック失敗から自動復旧までの流れ


ECSがヘルスチェックの失敗を検知してから、タスクが置き換えられるまでの流れを説明します。

まず、設定した間隔ごとにcommandが実行されます。
非0が返ったとき、ECSはそのコンテナを「失敗状態」として記録します。

retriesに設定した回数を超えて連続して失敗すると、コンテナのステータスがUNHEALTHYに変わります。
ECSサービスがこのステータスを検知すると、新しいタスクの起動を開始します。

新しいタスクが起動して正常状態になるまでの間、古いタスクはサービスから切り離されます。
最終的に古いタスクはSTOPPEDになり、ECSが後片付けを自動で実行します。

この仕組みを有効にするには、ECSサービスの「最小ヘルス率」と「最大率」の設定が重要です。
デフォルトでは最小100%・最大200%になっていますが、新しいタスクを起動できる余裕がある設定かどうかを事前に確認してください。

3. ALBヘルスチェックとECSヘルスチェックの役割の違い


ECSでALBを使う構成では、ALBヘルスチェックとECSヘルスチェックという2種類の確認が動いています。
それぞれの役割が違うため、両方を設定することが必要です。

チェック種類 確認する内容 失敗したときの動作
ALBヘルスチェック ALBからターゲットへのHTTPリクエストが届くかどうか ターゲットグループから切り離す（トラフィックを止める）
ECSヘルスチェック コンテナ内部のアプリケーションが応答できるかどうか タスクをUNHEALTHYにして、新しいタスクで置き換える

ALBヘルスチェックが失敗するのは、ネットワーク的に接続できない場合です。
一方、ECSヘルスチェックが失敗するのは、コンテナには接続できても中のアプリが正常でない場合です。

冒頭で紹介したデッドロックやスレッドプール枯渇のケースでは、ALBへの疎通自体は通ることがあります。
そのため、ECSヘルスチェックを設定していないと、ALBの判定では「正常」のまま異常なタスクにリクエストが届き続けます。

AWS Systems Managerで実現するaws死活監視の設計パターン


ECSのヘルスチェックは、コンテナ単体の自動復旧には有効です。
ただし、タスクが繰り返し再起動している状況を検知したり、復旧処理を詳細に制御したりするには、EventBridgeとSystems Managerとの連携が必要です。

ECSをAWSで運用する前提となる、Amazon Linuxの環境構築や基礎的なコマンド操作については、AWSとAmazon Linuxの基礎も参考にしてください。

1. EventBridgeでタスク停止イベントを取得する


ECSはタスクの状態が変わるたびに、EventBridgeにイベントを送信します。
このイベントをEventBridgeルールで捕捉することで、タスクが停止したことをリアルタイムに検知できます。

以下は、ヘルスチェック失敗によってタスクが停止したイベントを捕捉するルールのパターンです。


# EventBridgeルールのイベントパターン（JSON）
{
    "source": ["aws.ecs"],
    "detail-type": ["ECS Task State Change"],
    "detail": {
        "lastStatus": ["STOPPED"],
        "containers": {
            "healthStatus": ["UNHEALTHY"]
        }
    }
}
このルールに合致したイベントが発生した場合、SNSトピックへの通知やSSMオートメーションの起動をターゲットとして設定します。

イベントのdetailフィールドには、タスクのARN、クラスター名、停止理由（stoppedReason）が含まれています。
stoppedReasonを確認することで、ヘルスチェック失敗による停止かどうかを判断できます。

2. SSMオートメーションで復旧処理を自動実行する


EventBridgeのターゲットにSSMオートメーションを指定すると、タスクの異常停止を検知してから復旧処理を自動で実行できます。

SSMオートメーションで実行できる代表的な復旧アクションは以下のとおりです。

・サービスの強制再デプロイ：aws ecs update-serviceを実行して、サービスのタスクを新しいものに置き換える
・アラート通知：Amazon SNSに通知を送って、担当者に障害情報を届ける
・OpsItemの作成：SSM OpsCenterにインシデントを記録して、対応状況を追跡できるようにする

SSMオートメーションのRunbookでは、実行するアクションを順番に定義できます。
まず通知を送り、その後に自動再起動を試みて、再起動後のヘルス確認まで含めた一連の処理をコードで管理できます。

ECS + SSM + EventBridgeで構築するaws死活監視の実装手順

1. タスク定義にhealthCheckを追加する


既存のタスク定義にヘルスチェックを追加するには、コンテナ定義のhealthCheckブロックに設定を書いて、新しいリビジョンとして登録します。

AWS CLIで設定する場合は、次のようにjsonファイルを用意して実行します。


# タスク定義の新しいリビジョンを登録する
aws ecs register-task-definition \
    --cli-input-json file://task-definition.json
登録したリビジョンを反映するには、ECSサービスを更新します。


# サービスに新しいタスク定義を反映する
aws ecs update-service \
    --cluster my-cluster \
    --service my-service \
    --task-definition my-task:2 \
    --force-new-deployment
コンテナが起動したあと、ヘルスチェックが実際に機能しているかどうかは、タスクの詳細を確認することで判断できます。


# 実行中タスクのヘルス状態を確認する
aws ecs describe-tasks \
    --cluster my-cluster \
    --tasks タスクのARN

# 出力例（環境により異なります）
# "containers": [
#     {
#         "name": "webapp",
#         "healthStatus": "HEALTHY"
#     }
# ]

2. EventBridgeルールを設定してタスク異常を検知する


AWS CLIでEventBridgeルールを作成する手順を説明します。
まずルールを作成し、次にターゲット（SNSトピックまたはSSMオートメーション）を追加します。


# EventBridgeルールを作成する
aws events put-rule \
    --name ecs-task-stopped-rule \
    --event-pattern '{
        "source": ["aws.ecs"],
        "detail-type": ["ECS Task State Change"],
        "detail": {
            "lastStatus": ["STOPPED"],
            "containers": {
                "healthStatus": ["UNHEALTHY"]
            }
        }
    }' \
    --state ENABLED
ルール作成後、ターゲットとしてSNSトピックのARNを指定します。


# ルールのターゲットにSNSを設定する
aws events put-targets \
    --rule ecs-task-stopped-rule \
    --targets "Id=NotifySNS,Arn=arn:aws:sns:ap-northeast-1:123456789012:ecs-alert"

3. SSMオートメーションでアラートと復旧を自動化する


EventBridgeのターゲットにSSMオートメーションを追加することで、タスク停止の検知から復旧処理の実行まで自動化できます。

SSMオートメーションのRunbookでは、InputPayloadとしてEventBridgeから受け取ったイベント情報を使えます。
タスクが停止したクラスター名とサービス名を取得して、強制再デプロイを実行するステップを定義します。


# SSMオートメーションRunbookのステップ例（YAML形式）
mainSteps:
  - name: UpdateECSService
    action: aws:executeAwsApi
    inputs:
      Service: ecs
      Api: UpdateService
      cluster: "{{ ClusterName }}"
      service: "{{ ServiceName }}"
      forceNewDeployment: true
このRunbookに「通知ステップ（SNSへの送信）」と「確認ステップ（サービスの安定化を待つ）」を組み合わせると、復旧処理全体を管理できます。

死活監視の設定でよく起きる問題と対処


ヘルスチェックを設定したあとに、意図せずタスクが繰り返し再起動されることがあります。
よく起きる原因と対処を整理します。

問題1：startPeriodが短すぎてコンテナ起動直後に失敗する
アプリケーションの初期化（データベース接続確立、設定ファイルの読み込みなど）に時間がかかる場合、startPeriodの設定が短いと初期化中にUNHEALTHYと判定されます。
アプリケーションが実際に起動完了するまでの時間を計測して、余裕を持たせた値に設定してください。

問題2：/healthエンドポイントが認証を要求している
ヘルスチェック用のエンドポイントがBearerトークンや基本認証を要求する設定になっていると、curlのコマンドが認証エラーで失敗します。
ヘルスチェック専用のエンドポイントは認証なしで応答できるように設計してください。

問題3：curlが入っていない軽量コンテナイメージで失敗する
Alpine LinuxやDistrolessベースのイメージにはcurlが含まれていないことがあります。
その場合は、wget、nc（netcat）、またはPythonのurllib.requestを使ったコマンドに変更してください。


# curlの代わりにwgetを使う例
"command": ["CMD-SHELL", "wget -q -O- http://localhost:8080/health || exit 1"]

# curlの代わりにncを使う例（TCPポートの疎通確認）
"command": ["CMD-SHELL", "nc -z localhost 8080 || exit 1"]
問題4：タスクが繰り返し再起動してECSサービスが安定しない
短時間に何度もタスクが再起動を繰り返すと、ECSサービスがドレイン状態に移行することがあります。
その場合は、まずCloudWatch Logsでコンテナのログを確認して、アプリケーション側の原因を特定してから対処してください。

本記事のまとめ


ECSとSystems Managerを組み合わせたaws死活監視の設計のポイントをまとめます。

やりたいこと 使う機能・コマンド
コンテナ内部の死活状態を自動確認する ECSタスク定義のhealthCheck設定
ヘルスチェック失敗時にタスクを自動で置き換える ECSサービスのデプロイメント設定（最小ヘルス率・最大率）
タスク停止イベントをリアルタイムに検知する aws events put-rule（EventBridgeルール）
実行中タスクのヘルス状態を確認する aws ecs describe-tasks
異常停止したサービスを自動で再デプロイする SSMオートメーション + aws ecs update-service
障害対応を記録して追跡する SSM OpsCenter（OpsItemの自動作成）

ECSのヘルスチェックは、コンテナ内部のアプリケーション状態を継続的に確認して、異常があれば自動で新しいタスクに置き換える仕組みです。
ALBヘルスチェックとは役割が異なるため、両方を設定することが必要です。

EventBridgeとSystems Managerを組み合わせると、タスク停止の検知から担当者への通知、自動復旧処理の実行までを一連の流れとして設計できます。
コンテナの異常に気づくのが遅れる状況を防ぎ、サービスの稼働率を高める設計につながります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
ECSやAWSのコンテナ運用を現場で活かすには、Linuxサーバーの基礎設計を体系的に理解していることが前提になります。
AWSのEC2上でAmazon Linuxを使ったサーバー構築から学びたい場合は、Linux Master Pro Seminarをご確認ください。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

運営

リナックスマスター.JP（代表 宮崎智広）

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。