はじめに

Amazon ECSでコンテナアプリケーションをデプロイした後、本番環境で安定稼働させるためには適切な運用監視体制が不可欠です。タスク定義の作成やネットワーク設計ができても、運用フェーズでの監視やスケーリング設定が不十分では、障害発生時の対応が遅れたり、負荷変動に追従できなかったりする問題が発生します。

本記事では、ECSサービスの運用監視について、CloudWatch Logsによるログ収集からメトリクス監視、Application Auto Scalingによる自動スケーリング、そして障害対応のポイントまでを体系的に解説します。

この記事を読むことで、以下のことが理解できるようになります。

  • ECSタスクのログをCloudWatch Logsで効率的に収集・分析する方法
  • CloudWatchメトリクスを活用したECSサービスの監視設計
  • Application Auto Scalingによるタスク数の自動調整
  • 障害発生時のトラブルシューティングと対応フロー

ECSサービス運用監視の全体像

運用監視で押さえるべき3つの柱

ECSサービスの運用監視は、以下の3つの柱で構成されます。

flowchart TB
    subgraph Operations["ECS運用監視の3つの柱"]
        subgraph Logging["ログ監視"]
            Log1["アプリケーションログ"]
            Log2["コンテナログ"]
            Log3["ECSイベントログ"]
        end
        
        subgraph Metrics["メトリクス監視"]
            Met1["CPU/メモリ使用率"]
            Met2["タスク数"]
            Met3["ALBメトリクス"]
        end
        
        subgraph Scaling["自動スケーリング"]
            Scale1["ターゲット追跡"]
            Scale2["ステップスケーリング"]
            Scale3["スケジュールスケーリング"]
        end
    end
    
    CloudWatch["Amazon CloudWatch"]
    
    Logging --> CloudWatch
    Metrics --> CloudWatch
    CloudWatch --> Scaling
柱 目的 主要なAWSサービス
ログ監視 問題の原因特定、監査証跡 CloudWatch Logs
メトリクス監視 リソース状態の可視化、異常検知 CloudWatch Metrics, Alarms
自動スケーリング 負荷変動への自動対応 Application Auto Scaling

ECSにおけるCloudWatch連携の仕組み

ECSサービスとCloudWatchの連携は、タスク定義での設定を基点として自動的に構成されます。

flowchart LR
    subgraph ECS["Amazon ECS"]
        TaskDef["タスク定義"]
        Service["ECSサービス"]
        Task1["タスク1"]
        Task2["タスク2"]
    end
    
    subgraph CloudWatch["Amazon CloudWatch"]
        Logs["CloudWatch Logs"]
        Metrics["CloudWatch Metrics"]
        Alarms["CloudWatch Alarms"]
    end
    
    subgraph AutoScaling["Application Auto Scaling"]
        Policy["スケーリングポリシー"]
    end
    
    TaskDef -->|logConfiguration| Logs
    Service -->|メトリクス自動収集| Metrics
    Task1 -->|ログ出力| Logs
    Task2 -->|ログ出力| Logs
    
    Metrics --> Alarms
    Alarms --> Policy
    Policy -->|タスク数調整| Service

CloudWatch Logsによるログ監視

awslogsログドライバーの設定

ECS Fargateでは、awslogsログドライバーを使用してコンテナログをCloudWatch Logsに送信します。タスク定義のlogConfigurationで設定を行います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.0.0",
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "app",
          "awslogs-create-group": "true",
          "mode": "non-blocking",
          "max-buffer-size": "25m"
        }
      }
    }
  ]
}

各オプションの意味は以下のとおりです。

オプション 説明 推奨値
awslogs-group ロググループ名 /ecs/<サービス名>
awslogs-region リージョン タスク実行リージョン
awslogs-stream-prefix ログストリームのプレフィックス コンテナ名
awslogs-create-group ロググループの自動作成 true
mode ログ送信モード non-blocking
max-buffer-size 非ブロッキング時のバッファサイズ 25m

ログストリームの命名規則

awslogsドライバーは、ログストリーム名を以下の形式で自動生成します。

<prefix>/<container-name>/<task-id>

例えば、プレフィックスがapp、コンテナ名がweb、タスクIDがabc123def456の場合、以下のようなログストリーム名になります。

app/web/abc123def456

この命名規則により、特定のタスクのログを容易に特定できます。

ログの保持期間設定

CloudWatch Logsのロググループには保持期間を設定できます。コスト最適化の観点から、用途に応じた適切な保持期間を設定することを推奨します。

用途 推奨保持期間 理由
開発環境 7日 短期的なデバッグ用途
ステージング環境 30日 リリース前後の検証
本番環境（通常） 90日 障害調査、監査対応
本番環境（コンプライアンス要件あり） 1年以上 法令・規制対応

AWS CLIでの保持期間設定例を示します。

1
2
3
4

# 保持期間を90日に設定
aws logs put-retention-policy \
  --log-group-name "/ecs/my-app" \
  --retention-in-days 90

CloudWatch Logs Insightsによるログ分析

CloudWatch Logs Insightsを使用すると、ログデータに対してクエリを実行し、効率的に分析できます。

エラーログの抽出

1
2
3
4

fields @timestamp, @message
| filter @message like /ERROR|Exception|FATAL/
| sort @timestamp desc
| limit 100

特定のタスクIDのログ検索

1
2
3

fields @timestamp, @message, @logStream
| filter @logStream like /abc123def456/
| sort @timestamp asc

リクエスト処理時間の統計

1
2
3

fields @timestamp, @message
| parse @message /duration=(?<duration>\d+)ms/
| stats avg(duration), max(duration), min(duration), count() by bin(5m)

HTTPステータスコードの集計

1
2
3
4

fields @timestamp, @message
| parse @message /HTTP\/\d\.\d" (?<status>\d{3})/
| stats count() as requests by status
| sort requests desc

構造化ログの推奨

アプリケーションのログはJSON形式で出力することを推奨します。構造化ログを使用すると、CloudWatch Logs Insightsでのクエリが容易になります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "timestamp": "2026-01-25T12:00:00.000Z",
  "level": "INFO",
  "service": "my-app",
  "traceId": "abc-123-def",
  "message": "Request processed successfully",
  "duration": 150,
  "statusCode": 200,
  "path": "/api/users"
}

構造化ログを使用したクエリ例を示します。

1
2
3
4

fields @timestamp, level, message, duration, statusCode
| filter level = "ERROR"
| sort @timestamp desc
| limit 50

CloudWatchメトリクスによる監視

ECSサービスの標準メトリクス

ECSは以下のメトリクスをCloudWatchに自動的に送信します。

メトリクス 説明 単位 監視ポイント
CPUUtilization タスクのCPU使用率 % 高負荷の検知
MemoryUtilization タスクのメモリ使用率 % メモリ不足の検知
RunningTaskCount 実行中のタスク数 Count サービスの正常性
DesiredTaskCount 希望タスク数 Count スケーリング状態
PendingTaskCount 保留中のタスク数 Count 起動遅延の検知

これらのメトリクスはAWS/ECS名前空間で、ClusterNameおよびServiceNameディメンションとともに送信されます。

Container Insightsの有効化

Container Insightsを有効にすると、より詳細なメトリクスが収集できます。クラスター作成時またはアカウント設定で有効化します。

1
2
3
4

# 既存クラスターでContainer Insightsを有効化
aws ecs update-cluster-settings \
  --cluster my-cluster \
  --settings name=containerInsights,value=enabled

Container Insightsで追加されるメトリクスには以下があります。

メトリクス 説明
CpuReserved 予約されたCPU
CpuUtilized 使用されたCPU
MemoryReserved 予約されたメモリ
MemoryUtilized 使用されたメモリ
NetworkRxBytes 受信バイト数
NetworkTxBytes 送信バイト数
StorageReadBytes ストレージ読み取りバイト数
StorageWriteBytes ストレージ書き込みバイト数

CloudWatchアラームの設定

運用上重要なメトリクスにはアラームを設定し、異常を早期に検知できるようにします。

CPU使用率のアラーム

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "AlarmName": "ECS-HighCPU-my-service",
  "AlarmDescription": "ECSサービスのCPU使用率が80%を超えた場合にアラート",
  "MetricName": "CPUUtilization",
  "Namespace": "AWS/ECS",
  "Dimensions": [
    {
      "Name": "ClusterName",
      "Value": "my-cluster"
    },
    {
      "Name": "ServiceName",
      "Value": "my-service"
    }
  ],
  "Statistic": "Average",
  "Period": 300,
  "EvaluationPeriods": 2,
  "Threshold": 80,
  "ComparisonOperator": "GreaterThanThreshold",
  "AlarmActions": [
    "arn:aws:sns:ap-northeast-1:123456789012:alert-topic"
  ]
}

タスク数異常のアラーム

実行中のタスク数が希望タスク数を下回った場合に通知するアラームを設定します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

aws cloudwatch put-metric-alarm \
  --alarm-name "ECS-TaskCountAnomaly-my-service" \
  --alarm-description "実行中タスク数が不足している" \
  --metric-name "RunningTaskCount" \
  --namespace "AWS/ECS" \
  --dimensions Name=ClusterName,Value=my-cluster Name=ServiceName,Value=my-service \
  --statistic Average \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 2 \
  --comparison-operator LessThanThreshold \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:alert-topic"

推奨アラーム設定一覧

本番環境で設定すべきアラームの一覧を示します。

アラーム名 メトリクス 条件 閾値 優先度
High CPU CPUUtilization > 80% 中
Critical CPU CPUUtilization > 95% 高
High Memory MemoryUtilization > 80% 中
Critical Memory MemoryUtilization > 95% 高
Task Count Low RunningTaskCount < 希望数 高
Pending Tasks PendingTaskCount > 0（5分以上） 中

CloudWatchダッシュボードの作成

運用監視用のダッシュボードを作成し、ECSサービスの状態を一目で把握できるようにします。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "title": "ECS CPU/Memory Utilization",
        "view": "timeSeries",
        "metrics": [
          ["AWS/ECS", "CPUUtilization", "ServiceName", "my-service", "ClusterName", "my-cluster"],
          [".", "MemoryUtilization", ".", ".", ".", "."]
        ],
        "region": "ap-northeast-1",
        "period": 60
      }
    },
    {
      "type": "metric",
      "x": 12,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "title": "ECS Task Count",
        "view": "timeSeries",
        "metrics": [
          ["AWS/ECS", "RunningTaskCount", "ServiceName", "my-service", "ClusterName", "my-cluster"],
          [".", "DesiredTaskCount", ".", ".", ".", "."]
        ],
        "region": "ap-northeast-1",
        "period": 60
      }
    }
  ]
}

Application Auto Scalingの設定

ECSサービスのAuto Scaling概要

ECSサービスでは、Application Auto Scalingを使用してタスク数を自動的に増減させます。EC2 Auto Scalingとは異なるサービスですが、概念は類似しています。

flowchart TB
    subgraph Trigger["トリガー"]
        CW["CloudWatch Metrics"]
        Schedule["スケジュール"]
    end
    
    subgraph AutoScaling["Application Auto Scaling"]
        Target["スケーラブルターゲット<br/>（ECSサービス）"]
        Policy["スケーリングポリシー"]
    end
    
    subgraph ECS["Amazon ECS"]
        Service["ECSサービス"]
        Task1["タスク"]
        Task2["タスク"]
        Task3["タスク"]
    end
    
    CW --> Policy
    Schedule --> Policy
    Policy --> Target
    Target --> Service
    Service --> Task1
    Service --> Task2
    Service --> Task3

スケーラブルターゲットの登録

Auto Scalingを使用するには、まずECSサービスをスケーラブルターゲットとして登録します。

1
2
3
4
5
6

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 10
パラメータ 説明
service-namespace サービス名前空間（ECSの場合はecs）
resource-id リソースID（service/<cluster>/<service>形式）
scalable-dimension スケーリング対象（タスク数の場合ecs:service:DesiredCount）
min-capacity 最小タスク数
max-capacity 最大タスク数

ターゲット追跡スケーリング

ターゲット追跡スケーリングは、指定したメトリクスを目標値に維持するようにタスク数を自動調整します。最も推奨されるスケーリング方式です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

利用可能な事前定義メトリクス

メトリクスタイプ 説明
ECSServiceAverageCPUUtilization サービスの平均CPU使用率
ECSServiceAverageMemoryUtilization サービスの平均メモリ使用率
ALBRequestCountPerTarget ターゲットあたりのリクエスト数

ALBリクエスト数に基づくスケーリング

ALBと連携している場合、リクエスト数に基づくスケーリングが効果的です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name alb-request-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 1000.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/my-alb/1234567890abcdef/targetgroup/my-tg/0987654321fedcba"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

ステップスケーリング

ステップスケーリングは、メトリクスの値に応じて段階的にタスク数を調整します。急激な負荷変動に対応する場合に有効です。

flowchart LR
    subgraph Steps["ステップスケーリングの動作"]
        Step1["CPU 70-80%<br/>+1タスク"]
        Step2["CPU 80-90%<br/>+2タスク"]
        Step3["CPU 90%以上<br/>+3タスク"]
    end
    
    CW["CloudWatch<br/>Alarm"] --> Step1
    CW --> Step2
    CW --> Step3

ステップスケーリングポリシーの設定例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-step-scaling \
  --policy-type StepScaling \
  --step-scaling-policy-configuration '{
    "AdjustmentType": "ChangeInCapacity",
    "StepAdjustments": [
      {
        "MetricIntervalLowerBound": 0,
        "MetricIntervalUpperBound": 10,
        "ScalingAdjustment": 1
      },
      {
        "MetricIntervalLowerBound": 10,
        "MetricIntervalUpperBound": 20,
        "ScalingAdjustment": 2
      },
      {
        "MetricIntervalLowerBound": 20,
        "ScalingAdjustment": 3
      }
    ],
    "Cooldown": 60
  }'

スケジュールスケーリング

予測可能な負荷パターンがある場合、スケジュールに基づいてタスク数を調整できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 平日の営業時間開始時にスケールアウト
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name scale-out-business-hours \
  --schedule "cron(0 9 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=5,MaxCapacity=20

# 平日の営業時間終了時にスケールイン
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name scale-in-after-hours \
  --schedule "cron(0 21 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=2,MaxCapacity=10

スケーリングポリシーの選択指針

ポリシータイプ ユースケース メリット 注意点
ターゲット追跡 一般的なワークロード 設定が簡単、自動調整 複雑な条件には不向き
ステップスケーリング 急激な負荷変動 きめ細かな制御 設定が複雑
スケジュール 予測可能な負荷パターン 事前対応が可能 予測外の負荷に弱い

実際の運用では、ターゲット追跡をベースにスケジュールスケーリングを組み合わせるパターンが効果的です。

障害対応のポイント

ECSサービスで発生する主な障害パターン

flowchart TB
    subgraph Failures["主な障害パターン"]
        F1["タスク起動失敗"]
        F2["ヘルスチェック失敗"]
        F3["OOMによる停止"]
        F4["アプリケーションエラー"]
        F5["リソース不足"]
    end
    
    F1 --> C1["イメージプル失敗<br/>IAMロール問題<br/>リソース制限"]
    F2 --> C2["ALBヘルスチェック<br/>コンテナヘルスチェック<br/>起動遅延"]
    F3 --> C3["メモリリーク<br/>メモリ割り当て不足"]
    F4 --> C4["アプリケーションバグ<br/>依存サービス障害"]
    F5 --> C5["Fargate容量不足<br/>ENI制限"]

タスク起動失敗時のトラブルシューティング

タスクが起動しない場合、まずECSイベントを確認します。

1
2
3
4
5

# サービスのイベント確認
aws ecs describe-services \
  --cluster my-cluster \
  --services my-service \
  --query 'services[0].events[:10]'

よくある原因と対処法を示します。

エラーメッセージ 原因 対処法
CannotPullContainerError ECRからのイメージ取得失敗 実行ロールの権限、VPCエンドポイント確認
ResourceNotFoundException タスク定義が見つからない タスク定義のARN確認
RESOURCE:CPU / RESOURCE:MEMORY リソース不足 タスク定義のリソース設定見直し
AGENT ECSエージェントの問題 EC2起動タイプの場合、エージェント再起動

停止したタスクの調査

停止したタスクの理由を確認するには、describe-tasksコマンドを使用します。

1
2
3
4
5

# 停止したタスクの詳細確認
aws ecs describe-tasks \
  --cluster my-cluster \
  --tasks arn:aws:ecs:ap-northeast-1:123456789012:task/my-cluster/abc123 \
  --query 'tasks[0].{stoppedReason:stoppedReason,stopCode:stopCode,containers:containers[*].{name:name,exitCode:exitCode,reason:reason}}'

OOM（Out of Memory）エラーの対処

メモリ不足でタスクが停止する場合、以下の手順で対処します。

  1. タスク定義のメモリ割り当て確認
1
2
3
4
5
6
7
8
9

{
  "memory": "1024",
  "containerDefinitions": [
    {
      "memory": 512,
      "memoryReservation": 256
    }
  ]
}
  1. Container Insightsでメモリ使用状況を分析
1
2
3

fields @timestamp, @message
| filter @message like /OutOfMemory|OOM/
| sort @timestamp desc
  1. 対処オプション
対処 説明
メモリ増加 タスク定義のmemory値を増加
アプリ最適化 メモリリークの修正、キャッシュサイズ調整
水平スケーリング タスク数を増やして負荷分散

ヘルスチェック失敗時の対処

ALBのヘルスチェックが失敗する場合のチェックポイントを示します。

flowchart TB
    Start["ヘルスチェック失敗"] --> Q1{"アプリは<br/>正常起動?"}
    Q1 -->|No| A1["コンテナログを確認<br/>起動エラーを修正"]
    Q1 -->|Yes| Q2{"ヘルスエンドポイントは<br/>応答する?"}
    Q2 -->|No| A2["ヘルスチェックパスを確認<br/>エンドポイント実装を確認"]
    Q2 -->|Yes| Q3{"タイムアウト内に<br/>応答する?"}
    Q3 -->|No| A3["タイムアウト値を延長<br/>レスポンス速度改善"]
    Q3 -->|Yes| Q4{"セキュリティグループは<br/>正しい?"}
    Q4 -->|No| A4["SG設定を確認<br/>ALBからのアクセスを許可"]
    Q4 -->|Yes| A5["起動猶予期間を延長"]

ALBヘルスチェック設定の推奨値を示します。

パラメータ 推奨値 説明
HealthCheckPath /health または /healthz 軽量なヘルスチェック用エンドポイント
HealthCheckIntervalSeconds 30 チェック間隔
HealthCheckTimeoutSeconds 5 タイムアウト
HealthyThresholdCount 2 正常判定に必要な連続成功回数
UnhealthyThresholdCount 3 異常判定に必要な連続失敗回数

障害対応フローの整備

本番運用では、障害発生時の対応フローを事前に整備しておくことが重要です。

flowchart TB
    Alert["アラート発報"] --> Ack["アラート確認<br/>（5分以内）"]
    Ack --> Assess["影響範囲の確認"]
    Assess --> Q1{"サービス<br/>停止?"}
    Q1 -->|Yes| Escalate["エスカレーション"]
    Q1 -->|No| Investigate["原因調査"]
    Escalate --> Emergency["緊急対応<br/>ロールバック検討"]
    Investigate --> Fix["修正対応"]
    Emergency --> PostMortem["ポストモーテム"]
    Fix --> PostMortem
    PostMortem --> Improve["再発防止策"]

ベストプラクティス

ログ監視のベストプラクティス

項目 推奨事項
ログ形式 JSON形式の構造化ログを使用
ログレベル 環境変数で動的に変更可能に
保持期間 用途に応じて適切に設定
アラート連携 エラーログからSNS通知を設定

メトリクス監視のベストプラクティス

項目 推奨事項
Container Insights 本番環境では有効化
アラーム設定 段階的な閾値（Warning/Critical）
ダッシュボード サービス単位で作成
複合アラーム 関連メトリクスを組み合わせ

Auto Scalingのベストプラクティス

項目 推奨事項
最小タスク数 可用性を考慮して2以上
最大タスク数 コストとの兼ね合いで設定
クールダウン スケールイン時は長めに設定
ポリシー選択 ターゲット追跡をベースに

まとめ

本記事では、ECSサービスの運用監視について、ログ収集、メトリクス監視、Auto Scaling設定、障害対応のポイントを解説しました。

重要なポイントを振り返ります。

  • CloudWatch Logsでコンテナログを収集し、Logs Insightsで効率的に分析する
  • CloudWatchメトリクスとアラームを活用し、異常を早期に検知する
  • Container Insightsを有効化して、詳細なリソース使用状況を把握する
  • Application Auto Scalingでタスク数を自動調整し、負荷変動に対応する
  • 障害対応フローを事前に整備し、インシデント発生時に迅速に対応する

ECSサービスの安定運用には、これらの監視・自動化機能を適切に組み合わせることが不可欠です。本記事で紹介した設定を参考に、自社のワークロードに適した運用監視体制を構築してください。

参考リンク