システム監視とアラート設計：理論と概念編

本記事では、システム運用における監視（モニタリング）とアラートの基礎概念と設計原則について解説します。具体的な実装方法や運用ノウハウについては、実践編を参照してください。

目次

• 監視とアラートの目的
• 監視の4つのゴールデンシグナル
• 監視の種類と階層
• APM と RUM
• アラート設計の原則
• メトリクス収集の戦略
• アラート疲れを防ぐ
• 次のステップ

---

監視とアラートの目的

なぜ監視するのか？

監視の主な目的は以下の通りです：

• 障害の早期発見: ユーザーが気づく前に問題を検知し、影響を最小限に抑える
• 原因究明の支援: 問題発生時に、何が起きたのかを迅速に特定できるようにする
• キャパシティプランニング: リソース使用状況を把握し、将来の拡張計画を立てる
• SLA/SLO の達成: サービスレベル目標を満たしているかを継続的に確認する
• パフォーマンス最適化: ボトルネックを発見し、システムを改善する

監視 vs 観測可能性（Observability）

現代のシステムでは、両方が必要です。監視で問題を検知し、観測可能性で原因を究明します。

---

監視の4つのゴールデンシグナル

Googleの「Site Reliability Engineering」で提唱された、最も重要な4つの監視指標です。

レイテンシ（Latency）

「応答にどれくらい時間がかかるか」

• 成功リクエストのレイテンシ: 正常処理の応答時間
• 失敗リクエストのレイテンシ: エラー時の応答時間（即座に返る500エラーと、タイムアウトする500エラーは別物）

なぜ「平均値」ではなく「パーセンタイル(P95/P99)」を見るのか？

レイテンシの監視において、平均値（Mean）はしばしば真実を隠してしまうため、パーセンタイル（Percentile）を使用します。

1. 平均値の罠:

   • 例: 1人が100秒待たされ、99人が1秒で終わった場合
   • 平均 = 約2秒（「まあまあ速い」と誤解する）
   • 実態 = 1人のユーザーは激怒している

2. パーセンタイルの定義:

   • P50 (Median/中央値): 全体の50%のユーザーがこれより速い。全体の真ん中。
   • P95: 全体の95%のユーザーがこれより速い。「最も遅い5%」の境界線。
   • P99: 全体の99%のユーザーがこれより速い。「最も遅い1%」の境界線。

3. 用途と意味:

   • P50: 通常時のパフォーマンス傾向を知るために使う。
   • P95/P99 (テールレイテンシ): **「最悪の体験をしているユーザー」**を守るために使う。SLA/SLOでは、少数の外れ値を除外した「大多数のユーザー体験」を保証するためにP95やP99を基準にします。
   • 例: 「P99が200ms以下であること」 = 「99%のリクエストは200ms以内で返すが、残り1%の遅延は許容する」という現実的な合意形成に使われます。

トラフィック（Traffic）

「どれくらいの需要があるか」

• Webサービス: リクエスト数/秒
• ストレージ: I/O回数、データ転送量
• ストリーミング: 同時接続数、ビットレート

エラー（Errors）

「どれくらい失敗しているか」

• 明示的なエラー: HTTP 5xx、例外、タイムアウト
• 暗黙的なエラー: HTTP 200だが内容が不正、SLA違反のレスポンス

重要：エラー率 = エラー数 / 総リクエスト数（絶対数だけでは判断できない）

サチュレーション（Saturation）

「どれくらいリソースが埋まっているか」

• CPU使用率、メモリ使用率、ディスク使用率
• ネットワーク帯域、接続数
• 重要: 100%になる前（例: 80%）で警告を出す

監視 vs アラート：すべてにアラートすべきか？

Google SRE Bookでは、これら4つのシグナルを**監視（Monitor）することを推奨していますが、すべてに即時アラート（Page）**を設定することは推奨していません。すべてに緊急アラートを設定すると、オペレーターが疲弊してしまうためです。

• ページング（Pages）: ユーザー影響があり、即座に人間が対応すべき緊急事態（例：レイテンシの悪化、エラー率の急増）。
• チケット（Tickets）: 数日以内に対応が必要だが、今すぐでなくても良いもの（例：ディスク容量が90%に達したが、枯渇まで数日ある）。
• 記録（Logging）: 後で分析するための記録。

ベストプラクティス: レイテンシやエラーといった「症状（ユーザーが困っていること）」には即時アラートを設定し、トラフィックやサチュレーションといった「原因」は、それ自体が即座にサービス停止につながらない限り、チケット起票やダッシュボードでの確認に留めるのが一般的です。

---

監視の種類と階層

レイヤー別の監視

システムは複数の層で構成されており、各層で監視が必要です。

監視の3つのタイプ

プロアクティブ監視（予防的）

問題が起きる前に兆候を検知します。

• リソース使用率の上昇トレンド
• エラー率の緩やかな増加
• レスポンスタイムの劣化

目的: 障害を未然に防ぐ

リアクティブ監視（対処的）

問題が起きた時に検知します。

• サーバーダウン
• アプリケーションクラッシュ
• エラー率の急激な上昇

目的: 影響を最小限に抑える

トレンド分析（計画的）

長期的なデータから傾向を把握します。

• 月次のトラフィック増加率
• ストレージ容量の消費ペース
• ピーク時の負荷パターン

目的: キャパシティプランニング

---

APM と RUM

APM（Application Performance Monitoring）とは

**APM（アプリケーションパフォーマンスモニタリング）**は、ビジネスクリティカルなアプリケーションのパフォーマンスをリアルタイムで監視するプロセスです。ソフトウェアツールとテレメトリデータを使用して、アプリケーションの動作、レスポンスタイム、エラー率、リソース使用状況などを可視化します。

APM の主な機能

• トランザクション追跡: アプリケーション内での個々のトランザクションを最初から最後まで追跡
• パフォーマンスメトリクス: 応答時間、エラー率、スループット、CPU/メモリ使用率などを測定
• 依存関係の可視化: データベース、外部API、マイクロサービス間の依存関係を把握
• ボトルネックの特定: スロークエリやパフォーマンス劣化の原因を迅速に特定
• 分散トレーシング: マイクロサービスアーキテクチャでのリクエストフローを追跡

APM のメリット

• 迅速な診断と復旧: 問題の原因を素早く特定し、ダウンタイムを最小限に抑える。ほんの数分のダウンタイムが経済的損失を引き起こす可能性があるため、迅速な診断は重要
• 顧客満足度の向上: アプリケーション全体で問題が発生している箇所を特定し、デジタルカスタマージャーニーにおける一般的な問題を明らかにすることで、エンドユーザーに最大の価値を提供できる
• 運用コストの削減: アプリケーションの最適なパフォーマンスを維持するために必要なリソース、インフラストラクチャ、コンピューティング性能を判断し、運用コストを最小限に抑える
• 効果的な製品開発: テスト環境やライブ環境で APM を実装し、制限を明らかにしてエラーを特定。開発チームは、アプリケーションが本稼働する前にバグを修正できる
• ビジネス上のコラボレーション: ビジネスユニット間でメトリクスと分析を共有できるため、コミュニケーションの改善、サイロの解消、従業員のエンゲージメントや生産性の向上につながる

APM と観測可能性の関係

APM は観測可能性（Observability）のサブセットです。APM はメトリクスの集約ビューを提供しますが、観測可能性は分散トレーシング、構造化ログ、メトリクスを統合し、アプリケーションの動作を包括的に理解できるようにします。

主な APM ツール

• Datadog APM: フルスタック監視プラットフォーム
• New Relic: アプリケーションパフォーマンス管理
• AWS X-Ray: AWS アプリケーション向け分散トレーシング
• Dynatrace: AI を活用した自動検知
• Elastic APM: Elastic Stack の一部

RUM（Real User Monitoring）とは

**RUM（リアルユーザーモニタリング）**は、実際のユーザーがアプリケーションをどのように体験しているかを監視する手法です。エンドユーザーのブラウザやモバイルアプリから実際のパフォーマンスデータを収集し、ユーザー体験の品質を測定します。

RUM の主な機能

• 実ユーザーのパフォーマンス測定: ページ読み込み時間、レンダリング速度、操作のレスポンスタイムなど
• 地理的な分布: 世界中のユーザーからのアクセスパターンとパフォーマンスを把握
• ブラウザ/デバイス別の分析: 異なる環境でのパフォーマンス差異を特定
• ユーザージャーニーの追跡: ユーザーがアプリケーション内でどのように移動しているかを可視化
• JavaScript エラーの検知: フロントエンドで発生するエラーをリアルタイムで捕捉

RUM のメリット

• 実際のユーザー体験を測定: Synthetic Monitoring（合成監視）では検知できない、実際のユーザー環境（デバイス、ネットワーク、地域）での体験を正確に把握できる
• データに基づく意思決定: どの地域、デバイス、ブラウザでパフォーマンスが低下しているかを特定し、優先順位をつけて改善できる
• ビジネスインパクトの可視化: ページ読み込み時間とコンバージョン率、直帰率などのビジネス指標との相関関係を明らかにし、パフォーマンス改善の ROI を証明できる
• フロントエンドエラーの早期検知: ユーザーが報告する前に JavaScript エラーやレンダリングの問題を検知し、迅速に対応できる
• 継続的な改善: リリース前後のパフォーマンス比較により、新機能やコード変更が実際のユーザー体験に与える影響を測定できる

RUM と Synthetic Monitoring の違い

主な RUM ツール

• Google Analytics（GA4）: ウェブサイトのユーザー行動分析
• Amazon CloudWatch RUM: AWS アプリケーション向けユーザー監視
• Datadog RUM: フロントエンドパフォーマンス監視
• New Relic Browser: ブラウザ側のパフォーマンス監視
• Sentry: エラー追跡とパフォーマンス監視

APM と RUM を組み合わせる価値

APM と RUM を併用することで、バックエンドとフロントエンドの両方からアプリケーションのパフォーマンスを包括的に理解できます。

ユーザー体験の全体像：
RUM（フロントエンド） + APM（バックエンド） = エンドツーエンドの可視化

例：
- RUM: ページ読み込みに5秒かかっている
- APM: APIレスポンスに4秒かかっている（スロークエリが原因）
→ 統合することで、ユーザー体験の問題と技術的な原因を紐付けられる

詳細情報

APM と RUM についてさらに詳しく知りたい場合は、以下の公式ドキュメントを参照してください：

AWS

• APM とは? - アプリケーションパフォーマンスモニタリングの説明
• Amazon CloudWatch Application Signals
• Amazon CloudWatch RUM

Google Cloud

• Cloud Monitoring
• Application Performance Management

---

アラート設計の原則

良いアラートの条件

良いアラートは以下の条件を満たします：

• Actionable（対処可能）: 受け取った人が何をすべきか明確
• Urgent（緊急）: 即座に対応が必要
• Real（実際の問題）: ユーザー影響がある、または間もなく発生する
• Understandable（理解可能）: アラートメッセージが明確

悪いアラートの例

❌ NG例：対処不可能なアラート

「CPU使用率が80%を超えました」
→ 80%は正常範囲内かもしれない。どう対処すべきか不明確。

⭕ 改善例：対処可能なアラート

「過去15分間、CPU使用率が95%超過が継続。
レスポンスタイムが通常の2倍に増加。
スケールアウトまたは負荷調査が必要です。」
→ 明確な状態と推奨アクション

アラートの優先度と対応種別 (Page vs Ticket vs Log)

アラートの優先度（Priority）は、オペレーターが「いつ」「どのように」対応すべきか（Page/Ticket/Log）と直結させるべきです。 DatadogやNew Relicなどの監視ツール設定とも以下のようにマッピングすると運用がスムーズになります。

用語の定義:

• Page (ページ): 夜中でも休日でも担当者を呼び出す緊急通知
• Ticket (チケット): 業務時間内に処理するタスク
• Log (ログ): 記録として残し、事後分析や傾向把握に使用

アラート設定のアンチパターン

「念のため」アラート

全てのエラーログに対してアラート
→ 大量の誤検知で本当の問題が埋もれる

解決策: エラーの率と影響で判断する

閾値が厳しすぎる

CPU 50%でアラート
→ 正常な負荷でも頻繁に発報

解決策: ベースラインを把握し、異常値を閾値にする

一時的なスパイクでの発報

1回でも閾値を超えたら即アラート
→ 瞬間的なスパイクで誤検知

解決策: 連続N回、または一定期間継続で発報

アラートメッセージが不明瞭

「Error occurred」
→ 何のエラー？どこで？どう対処する？

解決策: 5W1H（何が、どこで、いつ、なぜ、どうする）を含める

---

メトリクス収集の戦略

メトリクスの3つの型

Counter（カウンター）

常に増加する値。リセットされるまで減らない。

例：
- 総リクエスト数
- エラー発生回数
- 処理完了件数

使い方: 増加率（rate）を見る

Gauge（ゲージ）

任意の時点での値。増減する。

例：
- CPU使用率
- メモリ使用量
- 同時接続数

使い方: 現在値や平均値を見る

Histogram（ヒストグラム）

値の分布を記録。パーセンタイルが計算できる。

例：
- リクエストレイテンシの分布
- ファイルサイズの分布

使い方: P50、P95、P99などを見る

サンプリング周期の決め方

トレードオフ: 短周期 = コスト増 vs 検知速度向上

---

アラート疲れを防ぐ

アラート疲れ（Alert Fatigue）とは

頻繁なアラートにより、重要な通知を見逃したり無視したりする状態。

防止策

アラートの定期レビュー

• 月次レビュー: 過去1ヶ月のアラートを分析
  • 誤検知が多いアラート → 閾値調整または削除
  • 対応不要だったアラート → 優先度を下げる
  • 見逃したアラート → 設定を追加

グルーピングとデデュプリケーション

同じ原因による複数アラートを1つにまとめる。

例：
10台のサーバーが同時にダウン
→ 「サーバー群Aで障害発生」として1通知

アラートのミュート（一時停止）

計画メンテナンス時や既知の問題対応中は、関連アラートをミュートする。

エスカレーションポリシー

- 1次担当者へ通知（Slack）
- 10分後も未対応 → 2次担当者へ通知（SMS）
- 30分後も未対応 → マネージャーへ通知（電話）

アラートのSLO

「アラート精度」自体をSLOとして設定する。

目標：
- 誤検知率 < 10%
- 平均対応時間 < 15分
- 見逃し率 < 1%

---

次のステップ

理論と概念を理解したら、次は実践編で具体的な実装方法を学びましょう。

→ 実践編：システム監視とアラート設計の実装と運用

実践編では以下のトピックを扱います：

• 死活監視（ヘルスチェック）の実装
• CloudWatchアラームの詳細設定
• 運用フェーズ別の監視戦略
• 監視ダッシュボードの設計
• チェックリスト
• 参考リソース

---

参考リソース

Google SRE（Site Reliability Engineering）

• SRE Book（Site Reliability Engineering）

  • 目次: https://sre.google/sre-book/table-of-contents/
  • 分散システムの監視: https://sre.google/sre-book/monitoring-distributed-systems/
  • アラートの定義: https://sre.google/sre-book/monitoring-distributed-systems/#alerting

• SRE Workbook（実践編）

  • 目次: https://sre.google/workbook/table-of-contents/
  • SLOに基づくアラート: https://sre.google/workbook/alerting-on-slos/