Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@555hamano(Akr)

「Dockerはわかるけど…」から卒業！AWSでコンテナを動かすための30日集中講座 - Day 23: コンテナのモニタリングとログ管理：Amazon CloudWatchとPrometheus

Last updated at Posted at 2025-08-23

Day 23: コンテナのモニタリングとログ管理：Amazon CloudWatchとPrometheus 📊

皆さん、こんにちは！30日集中講座、Day 23へようこそ。

昨日までに、GitHub Actionsを使ってコードの変更を自動でECRにプッシュするCI/CDパイプラインを構築しました。しかし、デプロイ後のアプリケーションが正常に動いているか、エラーが発生していないかをどうやって知ればよいでしょうか？

今日の講座では、本番環境で必須となるモニタリングとログ管理の概念を学びます。そして、AWSの代表的なサービスであるAmazon CloudWatchと、オープンソースのデファクトスタンダードであるPrometheusを使って、コンテナの状態を把握する方法を解説します。

1. モニタリングとログ管理の役割

モニタリングとログ管理は、アプリケーションの健全性を維持し、問題を早期に発見するために不可欠です。

  • モニタリング: アプリケーションやインフラリソース（CPU、メモリ、スループット、エラー率など）のパフォーマンスをリアルタイムで可視化します。これにより、予期せぬ負荷の増加やパフォーマンスの低下を検知できます。
  • ログ管理: アプリケーションが出力するログ（エラーメッセージ、リクエストログなど）を収集し、一元的に管理します。問題が発生した際に、原因を調査するために使われます。

これらは、車のダッシュボードとメンテナンス記録簿に例えることができます。ダッシュボード（モニタリング）で速度や燃料をリアルタイムで確認し、問題が発生した際にはメンテナンス記録簿（ログ）を見て原因を特定するのです。

監視のフレームワーク

アプリケーションの監視には、RED（Rate, Errors, Duration）やUSE（Utilization, Saturation, Errors） といったフレームワークを参考にすると、体系的なメトリクス収集が可能です。

REDメトリクス（サービス指向）

  • Rate: リクエスト/秒の処理数
  • Errors: エラー率（HTTP 4xx/5xx）
  • Duration: レスポンス時間

USEメトリクス（リソース指向）

  • Utilization: CPU・メモリ使用率
  • Saturation: キュー長・待機時間
  • Errors: ハードウェアエラー数

構造化ログのベストプラクティス

本番環境では、JSON形式の構造化ログが強く推奨されます：

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "ERROR",
  "service": "user-api",
  "traceId": "abc123def456",
  "userId": "user_****", // 機密情報をマスキング
  "message": "Database connection failed",
  "error": {
    "type": "ConnectionTimeout",
    "details": "Timeout after 30s"
  }
}

セキュリティ考慮事項

  • 個人情報やパスワードは絶対にログに出力しない
  • ユーザーIDは末尾4文字以外をマスキング
  • APIキーやトークンは完全にマスキング

2. AWSネイティブなモニタリング：Amazon CloudWatch ☁️

Amazon CloudWatchは、AWSが提供するフルマネージドなモニタリングサービスです。ECSやEKSといったコンテナサービスとシームレスに統合されており、特別な設定なしでコンテナのメトリクスやログを収集できます。

CloudWatch Logsの設定例（ECS on Fargate）

ECS on Fargateでは、タスク定義にawslogsドライバーを指定するだけで、自動でログがCloudWatch Logsに送信されます。

{
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "my-app-image",
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs",
          "awslogs-create-group": "true"  // ロググループが存在しない場合に自動作成
        }
      },
      // カスタムメトリクス用のラベル設定
      "dockerLabels": {
        "prometheus.io/scrape": "true",
        "prometheus.io/port": "8080"
      }
    }
  ]
}

CloudWatch Metricsとアラーム設定

CloudWatchは、CPU使用率やメモリ使用量、ロードバランサーのリクエスト数といったメトリクスを自動で収集します。

実践的なアラーム設定例

# CPU使用率の監視
aws cloudwatch put-metric-alarm \
  --alarm-name "ECS-HighCPUUtilization" \
  --alarm-description "Alert when CPU exceeds 80%" \
  --metric-name CPUUtilization \
  --namespace AWS/ECS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

# ALBエラー率の監視
aws cloudwatch put-metric-alarm \
  --alarm-name "ALB-HighErrorRate" \
  --alarm-description "Alert when error rate exceeds 5%" \
  --metric-name HTTPCode_Target_5XX_Count \
  --namespace AWS/ApplicationELB \
  --statistic Sum \
  --period 60 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1

CloudWatch Insights によるログ分析

CloudWatch Insightsを使用すると、SQLライクなクエリでログを効率的に分析できます：

# エラーログの傾向分析
fields @timestamp, level, message
| filter level = "ERROR"
| stats count() by bin(5m)
| sort @timestamp desc

# レスポンス時間の分析
fields @timestamp, duration
| filter @message like /response_time/
| stats avg(duration), max(duration), min(duration) by bin(1h)

トラブルシューティングのコツ

  • awslogs-groupが存在しない場合はawslogs-create-group: "true"を設定
  • IAMロールにlogs:CreateLogGroup権限が必要
  • ログが表示されない場合は、タスクロールにCloudWatch Logsへの書き込み権限を確認

3. オープンソースのデファクトスタンダード：PrometheusとGrafana 📈

Prometheusは、メトリクス収集と時系列データベースに特化したオープンソースのモニタリングツールです。
Grafanaは、Prometheusと組み合わせて使われる可視化ツールで、データをグラフやダッシュボードで分かりやすく表示します。

Prometheusのデプロイ例（EKS）

Kubernetes環境では、kube-prometheus-stackを使ってPrometheusエコシステムを簡単にデプロイできます。

# Helmリポジトリを追加
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Prometheusスタックをインストール
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=admin123

このコマンド一つで、Prometheus、Grafana、アラートマネージャーなど、モニタリングに必要なコンポーネントがすべてデプロイされます。

Grafanaの価値: Grafanaは、PrometheusだけでなくCloudWatch、MySQL、Elasticsearchなど、様々なデータソースと統合できます。豊富なダッシュボードテンプレートがコミュニティで共有されており、簡単に本格的な監視環境を構築できます。

運用の注意点: Prometheusを大規模に運用する場合、データの長期保持にはリモートストレージへの統合が必要になるなど、運用負荷が高まる場合があります。

カスタムメトリクスの設定例

アプリケーション独自のメトリクスを収集するための設定：

# アプリケーション内でのメトリクス定義例（Node.js）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-metrics-config
data:
  metrics.yml: |
    # カスタムメトリクス例
    - name: application_requests_total
      help: Total number of HTTP requests
      type: counter
      labelNames: [method, status_code]
      
    - name: application_request_duration_seconds
      help: Request duration in seconds
      type: histogram
      buckets: [0.1, 0.5, 1.0, 2.0, 5.0]

Grafanaダッシュボードの活用

Grafanaでは、コミュニティテンプレートを活用して効率的にダッシュボードを構築できます：

# Grafanaのポートフォワード（開発環境）
kubectl port-forward svc/prometheus-grafana 3000:80 -n monitoring

# ブラウザでhttp://localhost:3000にアクセス
# デフォルト: admin/admin123

推奨ダッシュボードテンプレート

  • Kubernetes Cluster Monitoring (ID: 7249)
  • Node Exporter Full (ID: 1860)
  • NGINX Ingress Controller (ID: 9614)

運用時の注意点

  • Prometheusのデータ保持期間はデフォルトで15日
  • 大規模環境では長期保存用にThanos等のリモートストレージ統合が必要
  • メトリクスの爆発的増加を防ぐため、ラベルの使い方に注意

4. 実践的なアラート戦略

アラート設定の基本原則

緊急度によるアラート分類

  • Critical: サービス停止、即座の対応が必要
  • Warning: パフォーマンス劣化、近い将来問題になる可能性
  • Info: 一般的な状態変更、ログ確認レベル

アラート疲れを防ぐコツ

  • 本当に重要なもののみアラート設定
  • 営業時間外は緊急度Criticalのみ通知
  • 自動復旧したアラートは自動クローズ

SLI/SLOの設定例 

# SLI/SLO設定例
slo:
  - name: api-availability
    description: "API availability should be 99.9%"
    sli: "sum(rate(http_requests_total{status!~'5..'}[5m])) / sum(rate(http_requests_total[5m]))"
    target: 0.999
    
  - name: api-latency
    description: "95th percentile latency should be under 500ms"
    sli: "histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))"
    target: 0.5
  • SLI (Service Level Indicators)：サービスレベル指標
    • サービスのパフォーマンスを測定するための具体的な指標です。サービスの健全性を客観的に測る「メトリクス」のようなものです。
  • SLO (Service Level Objectives)：サービスレベル目標
    • そのSLIの目標値です。サービスがどの程度の品質を維持すべきかを示す「目標」です。

5. まとめ：CloudWatch vs Prometheus

項目 Amazon CloudWatch Prometheus
統合性 AWSの全サービスとシームレスに統合 豊富なKubernetesエコシステムと連携
運用負荷 フルマネージドで運用不要 自分でコンポーネントを管理する必要がある
学習コスト 低い（AWSコンソールで完結） 高い（Kubernetesの知識が必要）
拡張性 AWSのサービスに依存 カスタムメトリクスやカスタムダッシュボード作成が容易
費用 収集したメトリクス量に応じた従量課金 運用コスト＋EC2などのインフラ費用
データ保持 標準で15ヶ月 設定可能（デフォルト15日）

コストの目安

  • CloudWatch: 小規模なコンテナ環境であれば、月数百円〜数千円程度
  • Prometheus: Prometheusサーバー用のEC2インスタンス（t3.medium以上）の費用

選択指針

  • CloudWatch採用ケース: AWS中心のインフラ、運用負荷最小化、スタートアップ
  • Prometheus採用ケース: マルチクラウド戦略、高度なカスタマイズ、エンタープライズ環境
  • ハイブリッド構成: CloudWatchでインフラ監視、Prometheusでアプリケーション詳細監視

6. 運用開始時のチェックリスト

導入初日に確認すべき項目

  • ログが正常に出力されている
  • アラートの通知先が正しく設定されている
  • ダッシュボードでメトリクスが表示される
  • アラートのテスト通知が成功する

1週間後に見直すべき項目

  • 不要なアラートが発生していないか
  • ログの量とコストが想定内か
  • ダッシュボードが実際の運用で活用されているか

これで、皆さんはコンテナの本番運用に不可欠なモニタリングとログ管理の基礎から実践まで学びました。明日は、さらに重要なセキュリティについて掘り下げていきます。

次回の予告

Day 24: コンテナセキュリティのベストプラクティス

それでは、また明日お会いしましょう！

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?