SRE本 第6章「分散システムのモニタリング」詳細まとめ【図解・用語・実例付き】
🔰 はじめに
本記事では、SRE本（Site Reliability Engineering）第6章「分散システムのモニタリング」について、SRE未経験者や実務者にも理解しやすいよう要約・解説します。
モニタリングは、SREの基本中の基本。異常の検知・原因の特定・パフォーマンスの分析・容量管理など、あらゆるSRE活動の出発点になります。
📡 モニタリングの目的と役割
| 目的 | 説明 |
|---|---|
| 障害の検知 | サービスの異常をリアルタイムで察知する |
| トラブルシュート | 原因の絞り込みと復旧対応 |
| パフォーマンス管理 | 応答速度やスループットの把握 |
| キャパシティプランニング | リソース使用率を把握して将来の需要に備える |
🧠 SREが考える「良いモニタリング」とは？
✅ 原則
- ユーザー視点であること：ユーザー体験に直結するメトリクスを重視
- 自動でアラートを出せること：人手で気づくのでは遅い
- 無駄なアラートを出さないこと：ノイズ削減が運用の鍵
- 可観測性（Observability）を意識すること
🔍 重要用語の整理
| 用語 | 説明 | 例 |
|---|---|---|
| メトリクス (Metrics) | 数値化された状態情報 | CPU使用率、リクエスト数 |
| ログ (Logs) | イベントや状態の履歴 | エラーログ、アクセスログ |
| トレース (Traces) | リクエストの経路・処理時間を追跡 | 分散トレースツール |
| イベント (Events) | 特定の出来事を表す通知 | Podの再起動など |
| アラート (Alerts) | 事前定義した条件に基づく警告 | SLO違反、5xx増加 |
🧭 モニタリング設計の指針（図解）
📌 ブラックボックス vs ホワイトボックス監視
| 観点 | ブラックボックス | ホワイトボックス |
|---|---|---|
| 概要 | 外部からの観測 | 内部構造も把握 |
| 例 | curlでの死活確認 | アプリ内部のメトリクス確認 |
| メリット | ユーザー体験に近い | 詳細な状態が把握できる |
| デメリット | 原因特定が困難 | 実装依存で壊れやすい |
| ベストプラクティス | 両方組み合わせるのが理想 |
🧰 実務で使えるモニタリングツール一覧
| カテゴリ | ツール名 | 用途 |
|---|---|---|
| メトリクス収集 | Prometheus / Datadog / Cloud Monitoring | サービス状態を可視化 |
| ログ分析 | Cloud Logging / Fluentd / Logstash | エラー・リクエスト内容の追跡 |
| トレース | OpenTelemetry / Jaeger / X-Ray | APIや内部処理の可視化 |
| 可視化 | Grafana / Kibana / Looker Studio | ダッシュボード作成 |
| アラート管理 | PagerDuty / Opsgenie / VictorOps | 通知とオンコール対応連携 |
🛠 アラート運用のベストプラクティス
- SLOベースのアラート：SLO違反の兆候に基づいて通知
- 段階的な通知：Warning → Critical とレベル分け
- ノイズ除去：同一原因による多重通知はサプレッション設定
- 緊急度に応じたルーティング：重要度で通知先や手段を分岐
✅ モニタリングの失敗あるある
| 誤り | 解説 |
|---|---|
| なんでもかんでも監視対象にする | ノイズ過多・保守不能に |
| アラートを通知するだけ | 自動対応やRunbookがなければ意味なし |
| ダッシュボードが多すぎる | 見る人が迷い、使われなくなる |
📌 まとめ
- モニタリングは「検出・分析・改善」の出発点
- ブラックボックスとホワイトボックスの組み合わせが鍵
- 「SLI→SLO→アラート」の構成がSRE的王道
- ノイズ削減と自動化で運用負荷を抑える
🚀 次にやること
- 監視対象の一覧を整理して、ユーザー体験に直結するSLIを選定
- ダッシュボードとアラートを見直してノイズを削減
- 自動化できるアラート対応フローを検討・構築する