ストーリー
田
田中VPoE
SLI/SLO体系の設計が完了した。次のステップは「予防的インシデント検知」だ。SLOが「問題の定義」だとすると、異常検知は「問題が顕在化する前に察知する仕組み」だ
田
田中VPoE
従来の静的閾値アラートだけでは不十分だ。「CPU使用率が80%を超えたらアラート」のような固定閾値は、正常な変動パターンを考慮できない。金曜夜のトラフィック増加で毎週誤報が飛ぶような状態では、アラートへの信頼が失われる
あなた
時間帯や曜日によって「正常」の基準が違うということですね
あ
田
田中VPoE
その通りだ。異常検知は「過去のパターンから逸脱した状態」を検出する。静的閾値では検出できない微妙な変化 — たとえばレイテンシのP99が徐々に上昇している傾向 — も検出できる。これがプロアクティブな運用の基盤だ
異常検知の基本概念
静的閾値 vs 動的異常検知
| 観点 | 静的閾値 | 動的異常検知 |
|---|
| 閾値設定 | 固定値(例: CPU > 80%) | 過去データから自動算出 |
| 季節性対応 | 不可 | 曜日・時間帯の変動を学習 |
| トレンド対応 | 不可 | 緩やかな変化傾向を検出 |
| 設定負荷 | 手動設定が必要 | モデルが自動学習 |
| 解釈容易性 | 単純明快 | 「なぜ異常か」の説明が必要 |
| 適用範囲 | 既知の障害パターン | 未知の障害パターンも検出可能 |
異常の3タイプ
| タイプ | 説明 | 例 |
|---|
| 点異常(Point Anomaly) | 単一のデータポイントが逸脱 | 突然のエラーレートスパイク |
| 文脈異常(Contextual Anomaly) | 特定の文脈で逸脱(値自体は正常範囲内) | 平日深夜にトラフィックが平日昼間レベルに急増 |
| 集団異常(Collective Anomaly) | データポイント群がパターンから逸脱 | レイテンシが3日間かけて徐々に上昇 |
異常タイプの可視化:
点異常:
正常: ──────────────────────────
実測: ─────────╱╲────────────── ← 突発的スパイク
文脈異常:
正常(昼): ╱╲╱╲╱╲╱╲ 正常(夜): ─────────
実測(夜): ╱╲╱╲╱╲╱╲ ← 夜間なのに昼間パターン
集団異常:
正常: ─────────────────────────
実測: ─────╱──╱──╱──╱──╱───── ← 緩やかな上昇トレンド
統計ベースの異常検知手法
手法1: 移動平均と標準偏差
| 概念 | 説明 |
|---|
| 原理 | 直近N期間の平均と標準偏差を計算し、Nσを超える値を異常とする |
| 利点 | シンプルで理解しやすい、計算コストが低い |
| 欠点 | 季節性を考慮できない、外れ値に平均が引きずられる |
| 適用 | エラーレート、リクエストレートの急変検知 |
設定例(Prometheus):
# 5分間の移動平均から3σ以上の逸脱を検出
(
rate(http_requests_total{status=~"5.."}[5m])
- avg_over_time(rate(http_requests_total{status=~"5.."}[5m])[1h:5m])
) / stddev_over_time(rate(http_requests_total{status=~"5.."}[5m])[1h:5m])
> 3
手法2: 季節性分解(STL分解)
| 概念 | 説明 |
|---|
| 原理 | 時系列をトレンド + 季節性 + 残差に分解し、残差の大きさで異常を判定 |
| 利点 | 季節性パターン(曜日、時間帯)を除外した真の異常を検出 |
| 欠点 | 十分な過去データ(2-4週間以上)が必要 |
| 適用 | レイテンシ、トラフィック量の異常検知 |
季節性分解の概念:
元の時系列データ:
╱╲╱╲╱╲╱╲╱╲╱╲╱╲╱╲ ← 毎日のパターンあり
分解後:
トレンド: ──────────────╱── ← 緩やかな上昇
季節性: ╱╲╱╲╱╲╱╲╱╲╱╲╱╲ ← 日次パターン
残差: ─────╲╱───────── ← ここが大きい = 異常
| 概念 | 説明 |
|---|
| 原理 | 中央値からの絶対偏差の中央値を使用。外れ値に頑健 |
| 利点 | 外れ値の影響を受けにくい(ロバスト統計量) |
| 欠点 | 正規分布を仮定しているため、偏った分布には不適 |
| 適用 | レイテンシのP99異常検知(外れ値が多い環境) |
機械学習ベースの異常検知手法
手法4: Isolation Forest
| 概念 | 説明 |
|---|
| 原理 | データをランダムに分割し、少ない分割回数で孤立するデータポイントを異常とする |
| 利点 | 高次元データに対応、学習が高速 |
| 欠点 | 異常の「理由」の説明が困難 |
| 適用 | 多数のメトリクスを同時に監視する多変量異常検知 |
手法5: Prophet / 時系列予測モデル
| 概念 | 説明 |
|---|
| 原理 | 過去データから将来の値を予測し、予測区間から逸脱した実測値を異常とする |
| 利点 | 季節性、祝日効果、トレンドを自動モデリング |
| 欠点 | モデルのチューニングが必要、誤検知の調整が難しい |
| 適用 | トラフィック予測とキャパシティプランニング |
手法の選択ガイド
| ユースケース | 推奨手法 | 理由 |
|---|
| エラーレートの急変 | 移動平均 + 標準偏差 | シンプルで即時検知が重要 |
| レイテンシの季節性を考慮した異常検知 | STL分解 or Prophet | 曜日・時間帯の変動を除外 |
| 多次元メトリクスの同時監視 | Isolation Forest | 高次元対応 |
| 緩やかな劣化の検知 | トレンド分析 + Prophet | 長期トレンドの変化を検出 |
| ビジネスメトリクスの予測 | Prophet | 季節性 + 祝日効果の自動モデリング |
組織レベルの異常検知戦略
サービスティア別の異常検知設定
| ティア | 手法 | 感度 | 検知対象 |
|---|
| Tier 1 | 多変量異常検知 + 季節性分解 | 高(2σ) | 全SLI + 依存メトリクス |
| Tier 2 | 季節性分解 + 静的閾値 | 中(3σ) | 主要SLI |
| Tier 3 | 移動平均 + 静的閾値 | 標準(3σ) | 可用性SLIのみ |
| Tier 4 | 静的閾値のみ | 低 | 基本メトリクスのみ |
異常検知の精度指標
| 指標 | 定義 | 目標値 |
|---|
| 適合率(Precision) | アラートのうち真の異常の割合 | 80%以上 |
| 再現率(Recall) | 真の異常のうち検知できた割合 | 95%以上 |
| F1スコア | 適合率と再現率の調和平均 | 85%以上 |
| MTTD(検知時間) | 異常発生から検知までの時間 | Tier 1: 5分以内、Tier 2: 15分以内 |
「異常検知の目的は”障害になる前に気づくこと”だ。障害が起きてから検知するのはモニタリング、障害の予兆を捉えるのが予防的インシデント検知だ。この違いが組織の信頼性を根本的に変える」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| 静的閾値の限界 | 季節性、トレンド、未知のパターンに対応できない |
| 異常の3タイプ | 点異常、文脈異常、集団異常を区別して適切な手法を選択 |
| 統計/ML手法 | ユースケースに応じて移動平均、STL分解、Isolation Forest等を使い分け |
| ティア別戦略 | サービスの重要度に応じて異常検知の感度と手法を段階的に設定 |
チェックリスト
次のステップへ
次は「アラート設計とノイズ削減」を学びます。異常を検知した後、どのようにアラートを設計し、偽陽性(ノイズ)を削減して本当に対応が必要な通知だけを届けるかを身につけましょう。
推定読了時間: 30分