概要

「入門監視」（Mike Julian著）を読む前に押さえておくべき監視の全体像

• 監視は「ビジネス→フロントエンド→アプリ→サーバ→ネットワーク」の5層で設計する
• アラートは「症状ベース」で設計し、CPUなどの「原因」はダッシュボードに置く
• Django + AWS CloudWatchの組み合わせで、各層の監視を実装できる

監視とは何か・なぜ必要か

監視とはシステムの振る舞いを継続的に観察する行為であり、壊れる前・瞬間に気づくための仕組みだ

監視の目的は「システムが正しく動いているか」を知ること。よくある誤解は「サーバが落ちていないか確認すること」だが、それは監視の一部に過ぎない。本書が強調するのは 「ユーザーへの影響」から逆算して監視設計をする という考え方だ。

監視対象は大きく5層に分かれる：

[ ビジネス ]        ← 売上・ユーザー数・コンバージョン率
[ フロントエンド ]  ← ページロード・エラー率
[ アプリケーション ]← レスポンスタイム・例外・ログ
[ サーバ ]          ← CPU・メモリ・ディスク
[ ネットワーク ]    ← レイテンシ・パケットロス

DjangoアプリをAWS ECS上で動かしている場合、CloudWatchには自動でコンテナのCPU/メモリが届く。しかし「500エラーが増えている」「レスポンスが遅い」はアプリ層の監視を別途設計しないと見えない。

💡 ポイント: 「サーバが生きている ≠ サービスが正常」。死活監視だけでは、スローリークやDB接続枯渇は検知できない。

用語

監視のアンチパターン

「ツールを入れれば監視できている」という思い込みが、監視を形骸化させる最大の罠だ

本書が挙げる代表的なアンチパターンは4つ：

① ツール依存        → ツールを入れること自体が目的になる
② 役割としての監視  → 「監視チームがやること」になり、開発者が無関心になる
③ チェックボックス監視 → アラートを設定したら終わり、中身を見ない
④ 障害対応だけの監視 → 壊れてから見るだけ。予兆を活かせない

特に②が重要で、監視はスキルであって役割ではないというのが本書の核心のひとつ。自分が作ったサービスは自分で監視設計すべき、という考え方だ。監視チームはツールや基盤を提供するのはOKだが、アラートの定義・閾値の設定はアプリ・インフラの担当者自身が行うべきだ。

「CloudWatchアラームを設定した」で安心するのがアンチパターンの典型。CPU 80%超えのアラームを設定しても、それが何を意味するか・どう対応するかが決まっていなければ、アラートは単なるノイズになる。

💡 ポイント: アラートが多すぎて無視されるようになったら、それはすでに監視が機能していないサイン（＝アラート疲れ）。

用語

監視のデザインパターン

監視は「低レベル（CPU）」からではなく「高レベル（ユーザー影響）」から設計を始めるのが正しい順序だ

本書が推奨するデザインパターンの核心は 「外から内へ」 の設計順序：

① ユーザーが体験する症状から始める
      ↓
② その症状を引き起こすアプリ層の指標を定義する
      ↓
③ その原因を掘り下げるためにサーバ・インフラ層を見る

重要な概念として 「症状 vs 原因」 がある：

CPUが高いこと自体はアラートの理由にならない。「ユーザーに影響が出ているか」が判断基準。CloudWatchでまず設定すべきは 5xxエラー率 や ALBのレイテンシ。CPU/メモリは原因調査用のダッシュボードに置く。

💡 ポイント: 「CPUが80%超えたらアラート」は典型的な原因ベース監視。症状ベースに切り替えるだけで、アラート疲れが大幅に減る。

用語

アラート・オンコール・インシデント管理

アラートは「人を夜中に起こすに値するか」を基準に設計する

アラートの分類:
┌─────────────────────────────────────┐
│ 緊急（今すぐ起こす）                │
│  → ユーザーへの影響が出ている       │
│  → 例: 5xxエラー率が5%超           │
├─────────────────────────────────────┤
│ 要対応（営業時間内でOK）            │
│  → 放置すると問題になる             │
│  → 例: ディスク使用率が70%超       │
│  → 例: SSL証明書の有効期限が30日後 │
├─────────────────────────────────────┤
│ 情報（通知不要・ログだけでOK）      │
│  → 記録しておくだけでよい           │
│  → 例: デプロイ完了通知             │
└─────────────────────────────────────┘

SSL証明書の有効期限が30日後に切れる場合は「要対応（営業時間内でOK）」。放置すると証明書切れ→サービス停止という深刻な問題になるため、チケット化・担当者通知が必要。7日前なら「緊急」に格上げする等、期限に応じて分類を動的に変える設計もよく使われる。

# Django側でカスタムメトリクスを送信する例
import boto3

cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-1')

def record_error_rate(error_count, total_count):
    cloudwatch.put_metric_data(
        Namespace='MyDjangoApp',
        MetricData=[{
            'MetricName': 'ErrorRate',
            'Value': error_count / total_count * 100,
            'Unit': 'Percent'
        }]
    )

このメトリクスに対してCloudWatchアラームで「5%超 → SNS通知 → PagerDuty」のような連携が典型構成。

💡 ポイント: アラートが多すぎて無視されるのが最悪の状態。「アラートを減らす勇気」も監視設計のスキルのひとつ。

用語

ビジネスを監視する

技術指標をビジネスKPIに接続できて初めて、監視はエンジニア以外にも価値を持つ

技術指標だけでは「サービスが健全かどうか」を経営層・PdMに伝えられない。技術指標とビジネス指標を橋渡しする設計が必要：

技術指標                    ビジネスKPI
─────────────────────────────────────────
5xxエラー率の上昇      →   購入完了率の低下
レスポンスタイム悪化   →   直帰率の上昇
ログイン失敗率の急増   →   アクティブユーザー数の減少
DB応答遅延             →   売上・決済完了数の低下

ECサイトで最もビジネスへの影響が大きいカスタムメトリクスは注文完了数（OrderCompleted）。OrderCompleted が突然ゼロになれば、即座に売上ゼロを意味する。

# 注文完了数をカスタムメトリクスとして送信
def order_complete(request):
    # ...注文処理...
    cloudwatch.put_metric_data(
        Namespace='MyDjangoApp/Business',
        MetricData=[{
            'MetricName': 'OrderCompleted',
            'Value': 1,
            'Unit': 'Count'
        }]
    )

CloudWatch Dashboardに OrderCompleted と 5xxエラー率 を並べて表示することで、技術障害がビジネスに与えた影響を即座に可視化できる。

💡 ポイント: ビジネスKPIはシステムごとに異なるので「これを監視すればOK」というテンプレートはない。自分のサービスの「お金を生む動線」を特定することが出発点。

用語

フロントエンド監視

サーバが正常でもブラウザで遅ければユーザーにとっては「壊れている」のと同じだ

フロントエンド監視はサーバ側では見えない「ユーザーの実体験」を計測する：

パフォーマンス系:
  LCP  (Largest Contentful Paint) 最大描画タイミング
  FID  (First Input Delay) 入力遅延
  CLS  (Cumulative Layout Shift) レイアウトずれ
  → まとめてCore Web Vitalsと呼ぶ

エラー系:
  JSエラー率・APIエラー率・404発生数

ユーザー行動系:
  直帰率・セッション時間・離脱ポイント

合成監視（Synthetic Monitoring）: スクリプトで定期的に動作確認する監視手法。CloudWatch Syntheticsはブラウザを自動操縦して「ログイン→商品閲覧→購入」の一連フローが動くかを定期チェックできる。対になる概念として**リアルユーザー監視（RUM: Real User Monitoring）**があり、実際のユーザーのブラウザから計測データを収集する。

💡 ポイント: 「サーバのレスポンスは200ms」でも「ブラウザでのLCPは4秒」はよくある乖離。ネットワーク・CDN・JS実行時間が上乗せされるから。

用語

アプリケーション監視

アプリ層の監視は「ログ・メトリクス・トレース」の3本柱で設計する

「どのDBクエリが遅いか」の調査にはトレースが最も適している。AWSではX-Rayがトレースに対応しており、DjangoにはAWS X-Ray SDKを組み込むことで、スロークエリの特定まで一気通貫で調査できる。

# settings.py - watchtowerでDjangoログをCloudWatch Logsへ転送
LOGGING = {
    'version': 1,
    'handlers': {
        'cloudwatch': {
            'class': 'watchtower.CloudWatchLogHandler',
            'log_group': '/django/myapp',
            'stream_name': 'application',
        }
    },
    'loggers': {
        'django': {
            'handlers': ['cloudwatch'],
            'level': 'WARNING',  # WARNING以上をCloudWatchへ送信
        }
    }
}

watchtower ライブラリを使うとDjangoのログを直接CloudWatch Logsに送れる。CloudWatch Logs Insightsでクエリ検索も可能になる。

💡 ポイント: ログは「障害が起きたときに原因を調べるもの」。メトリクスは「異常を検知するもの」。役割が違うので両方必要。

用語

サーバ監視

CPU・メモリ・ディスクは「診断ツール」であって「アラートの主役」ではない

サーバメトリクスは原因調査用として使うのが正しい位置づけ：

メモリリークは時間とともにメモリ使用率が単調増加するパターンとして現れる。放置するとECSタスクがOOM（Out of Memory）でkillされ、タスク再起動が繰り返される状態になる。

// CloudWatch Agent設定（抜粋）
{
  "metrics": {
    "metrics_collected": {
      "disk": {
        "measurement": ["used_percent"],
        "resources": ["/"]
      },
      "mem": {
        "measurement": ["mem_used_percent"]
      }
    }
  }
}

ECSはタスクが落ちると新しいタスクが立ち上がるため「サーバが落ちた」に気づきにくい。タスク再起動回数もメトリクスとして監視すべき。

💡 ポイント: ECSのCPU/メモリはCloudWatchに自動送信されるが、ディスクやDB接続数はCloudWatch Agentの追加設定が必要。

用語

ネットワーク監視

ネットワーク監視はアプリが「つながるか」「速いか」「安全か」の3軸で設計する

「特定の地域からだけレイテンシが高い」問題は、アプリサーバやDBは全ユーザーに共通なので、**CDN・エッジロケーションの設定ミスや、その地域とサーバ間の物理的な距離（ネットワーク経路）**が原因であることが多い。「地域で差が出る＝アプリではなくネットワーク経路・CDN層を疑う」が定石。

# Djangoミドルウェアでレイテンシを計測してCloudWatchに送る例
import time, boto3

def middleware_latency(get_response):
    def middleware(request):
        start = time.time()
        response = get_response(request)
        duration = (time.time() - start) * 1000  # ms換算
        boto3.client('cloudwatch').put_metric_data(
            Namespace='MyDjangoApp',
            MetricData=[{
                'MetricName': 'RequestLatency',
                'Value': duration,
                'Unit': 'Milliseconds'
            }]
        )
        return response
    return middleware

💡 ポイント: ACM（AWS Certificate Manager）でSSL証明書を管理すると自動更新されるため、証明書切れ障害をほぼゼロにできる。自前管理との差は大きい。

用語

セキュリティ監視

セキュリティ監視は「侵入後に気づく」ための仕組みであり、防御と検知は別物だ

セキュリティ対策（WAF・認証）は侵入を防ぐが、100%防げる前提には立てない。異常を早期検知して被害を最小化するのがセキュリティ監視の役割：

認証系:
  ログイン失敗の急増（ブルートフォース）
  普段と異なる時間・IPからのログイン

トラフィック系:
  リクエスト数の異常な急増（DDoS兆候）
  特定エンドポイントへの集中アクセス

操作系:
  本番DBへの直接アクセス
  IAMポリシーの変更・権限昇格
  大量データの一括取得

# ログイン失敗をCloudWatchカスタムメトリクスに送る
from django.contrib.auth.signals import user_login_failed
from django.dispatch import receiver

@receiver(user_login_failed)
def on_login_failed(sender, credentials, request, **kwargs):
    cloudwatch.put_metric_data(
        Namespace='MyDjangoApp/Security',
        MetricData=[{
            'MetricName': 'LoginFailed',
            'Value': 1,
            'Unit': 'Count'
        }]
    )

CloudTrailとGuardDutyの違い:

• CloudTrail: AWS上の操作を記録する（ログ収集・台帳）
• GuardDuty: その記録を分析して異常を検知する（脅威検出・探偵）

💡 ポイント: セキュリティ監視のアラートは「誤検知が多い」問題がある。閾値設計が甘いと毎日アラートが鳴り、アラート疲れでスルーされるようになる。

用語

監視アセスメント・改善サイクル

監視は一度作って終わりではなく、システムの成長に合わせて継続的に見直すものだ

現状評価の問い：

① 監視されていない単一障害点はないか？
② アラートの何割が実際に対応されているか
③ 障害時に原因特定まで何分かかるか？
④ ビジネスKPIと技術指標は紐づいているか
⑤ 監視設計をした人以外も理解できるか？

改善サイクル：

現状把握 → 優先順位付け → 実装 → 振り返り
   ↑________________________________↓

Django + ECS環境での実践チェックリスト：

監視の優先順位：まず「異常を検知する（5xxアラーム）」、次に「原因を調査する（Logsへの転送）」。ログ転送は原因調査のためなので、そもそも異常を検知できなければログを見る機会すら来ない。

💡 ポイント: 完璧な監視を目指すより「今一番痛い問題を1つ解決する」を繰り返す方が現実的。監視も技術的負債と同じで、少しずつ返済する発想が大事。

❌ やりがちなミス

「設定した＝監視できている」という思い込みと、原因をアラートにしてしまうことが最大の落とし穴

📝 自分のメモ・気づき

セッションを通じて「症状 vs 原因」の軸が監視設計全体を貫く核心概念だとわかった

• アプリ層の具体例が掴めた: user_login_failed シグナルや watchtower ライブラリなど、DjangoとCloudWatchを繋ぐ実装イメージが持てた
• SSL証明書は「情報」ではなく「要対応」: 猶予があるからといって無視すると致命的。期限に応じて分類を動的に変える発想が大事
• ECサイトの最重要メトリクスは注文完了数: ログイン失敗率も重要だが、それはセキュリティ監視の文脈。ビジネス監視の軸は「お金を生む動線」
• CloudTrail ≠ GuardDuty: 記録する（台帳）vs 検知する（探偵）の役割分担を明確に理解できた
• ECSの盲点: タスクが自動再起動するため「落ちた」に気づきにくい。タスク再起動回数を監視することが重要
• 監視の優先順位: 検知（5xxアラーム）→ 調査（ログ転送）の順。逆にすると障害が来ても気づけない

参考リンク

• 入門 監視 - O'Reilly Japan
• 【書評&要約】「入門 監視」の全章をまとめてみる
• Amazon CloudWatch ドキュメント
• watchtower - PyPI
• AWS X-Ray と Django の統合
• 「入門 監視」5年を経て変わったこと、変わらないこと（松浦氏登壇資料）