オブザーバビリティの基礎

このドキュメントの目的

オブザーバビリティの基本概念を理解し、なぜ従来のモニタリングだけでは不十分なのかを把握することが目標です。SLI/SLO設計の考え方を学び、システムの信頼性を定量的に管理できるようになることを目指します。

IDサービスを題材にした具体例を使用しますが、設計原則自体はあらゆるSaaSに共通して適用できます。

モニタリングとオブザーバビリティの違い

モニタリング: 既知の問題を監視する

モニタリングは「何を監視すべきか」を事前に知っている前提で設計します。

モニタリングのアプローチ:

  事前に定義した監視項目:
  ┌──────────┐  ┌──────────┐  ┌──────────┐
  │ CPU使用率 │  │ メモリ   │  │ ディスク │
  │ > 80%?   │  │ > 90%?   │  │ > 85%?   │
  └─────┬────┘  └─────┬────┘  └─────┬────┘
        │              │              │
        └──────┬───────┘──────────────┘
               │
         ┌─────▼─────┐
         │ アラート   │  「閾値を超えたら通知」
         │ 発火       │
         └───────────┘

限界: 事前に想定していない問題（例: 特定テナントの認証レイテンシだけが悪化）は検出できません。

オブザーバビリティ: 未知の問題を調査できる能力

オブザーバビリティは「何が起きているか分からない状態」から原因を特定できる能力です。

オブザーバビリティのアプローチ:

  任意の質問に答えられるデータ基盤:
  ┌─────────────────────────────────────────────────┐
  │  構造化ログ  ×  メトリクス  ×  トレース          │
  │                                                 │
  │  「テナントAの認証が遅いのはなぜ?」              │
  │  「昨日の15時に何が変わった?」                   │
  │  「このエラーはどのリクエストパスで発生する?」    │
  └─────────────────────────────────────────────────┘
         │
         ▼
  事前に想定していなかった問題も調査・特定できる

比較まとめ

観点	モニタリング	オブザーバビリティ
前提	何を監視すべきか事前に知っている	何が起きるか分からない
問い	「この値は正常か?」	「なぜこの状態になったのか?」
データ	事前定義されたメトリクス	ログ・メトリクス・トレースの組み合わせ
対応できる問題	既知の障害パターン	未知の問題・複合的な障害
例（IDサービス）	「ログインAPIの応答時間 > 3秒」	「テナントXのOTP認証だけが遅い原因は?」

重要: オブザーバビリティはモニタリングを置き換えるものではありません。モニタリングはオブザーバビリティの一部です。既知の問題にはアラート（モニタリング）で対応し、未知の問題にはオブザーバビリティで調査します。

オブザーバビリティの3本柱

ログ・メトリクス・トレースの役割

┌─────────────────────────────────────────────────────────────────┐
│                    オブザーバビリティの3本柱                       │
├───────────────────┬───────────────────┬─────────────────────────┤
│                   │                   │                         │
│   ログ (Logs)     │ メトリクス        │ トレース (Traces)        │
│                   │ (Metrics)         │                         │
│  「何が起きたか」  │ 「どのくらいか」   │ 「どこで起きたか」       │
│                   │                   │                         │
│  個別イベントの    │  集計された       │  リクエスト単位の        │
│  詳細記録         │  数値データ        │  処理経路追跡           │
│                   │                   │                         │
│  例:              │  例:              │  例:                    │
│  "user=alice      │  login_requests   │  POST /authorize        │
│   action=login    │  _total: 1523     │   → validateClient     │
│   status=failed   │                   │   → checkConsent       │
│   reason=invalid  │  auth_latency     │   → generateCode      │
│   _password"      │  _p99: 245ms     │   → 合計: 320ms        │
│                   │                   │                         │
└───────────────────┴───────────────────┴─────────────────────────┘

3本柱の関係

3つのシグナルは独立ではなく、相互に補完し合います。

障害調査の流れ（IDサービスの例）:

  1. メトリクスで異常を検出
     「認証エラー率が5%を超えた」
                │
                ▼
  2. ログで詳細を確認
     「テナントBのOTP検証で "expired_code" エラーが急増」
                │
                ▼
  3. トレースで原因を特定
     「OTP検証→外部SMS API呼び出しのレイテンシが10秒超
       → タイムアウトでOTPコード期限切れ」
                │
                ▼
  4. 根本原因の特定
     「SMS APIプロバイダの障害によるレスポンス遅延」

シグナル	強み	弱み	適した用途
ログ	詳細なコンテキスト情報	データ量が大きい	エラー調査、監査証跡
メトリクス	集計・トレンド分析が得意	個別イベントの詳細がない	アラート、ダッシュボード
トレース	リクエスト全体の流れが見える	全リクエストは記録できない	レイテンシ分析、ボトルネック特定

SLI / SLO / SLA

3つの概念の関係

┌─────────────────────────────────────────────────────────────┐
│ SLA (Service Level Agreement) - ビジネス契約                 │
│ 「月間稼働率99.9%を保証。違反時は利用料の10%を返金」         │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │ SLO (Service Level Objective) - 内部目標              │    │
│  │ 「月間稼働率99.95%を目標とする」（SLAより厳しく設定）   │    │
│  │                                                       │    │
│  │  ┌─────────────────────────────────────────────┐      │    │
│  │  │ SLI (Service Level Indicator) - 計測指標      │      │    │
│  │  │ 「成功リクエスト数 / 全リクエスト数 × 100」    │      │    │
│  │  └─────────────────────────────────────────────┘      │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

SLI（Service Level Indicator）の設計

SLIはシステムの信頼性を計測するための指標です。

SLIカテゴリ	計測内容	IDサービスでの例
可用性（Availability）	成功リクエストの割合	トークンエンドポイントの成功率
レイテンシ（Latency）	レスポンス時間	認可リクエストのp99レイテンシ
スループット（Throughput）	処理量	1秒あたりのトークン発行数
正確性（Correctness）	正しい結果の割合	ID Tokenのクレームが正しい割合

SLI設計のポイント:

ユーザーに近い場所で計測する（サーバー内部ではなくロードバランサーで計測）
意味のある粒度にする（全APIの平均ではなく、エンドポイント別に計測）
計測可能で自動化できる指標を選ぶ

SLO（Service Level Objective）の設計

SLOは「どの程度の信頼性を目標とするか」を定義します。

IDサービスのSLO設計例:

┌──────────────────────┬────────────────────┬────────────────────┐
│ エンドポイント        │ SLI                │ SLO                │
├──────────────────────┼────────────────────┼────────────────────┤
│ POST /token          │ 成功率             │ 99.95% / 月         │
│ POST /token          │ p99レイテンシ       │ < 500ms            │
│ GET /authorize       │ 成功率             │ 99.9% / 月          │
│ POST /userinfo       │ 成功率             │ 99.95% / 月         │
│ POST /ciba           │ 成功率             │ 99.9% / 月          │
└──────────────────────┴────────────────────┴────────────────────┘

エラーバジェット

エラーバジェットは「SLOの範囲内で許容される障害の量」です。

エラーバジェットの計算:

  SLO = 99.95%（月間）
  月間リクエスト数 = 10,000,000

  許容エラー率 = 100% - 99.95% = 0.05%
  エラーバジェット = 10,000,000 × 0.0005 = 5,000リクエスト

  ┌─────────────────────────────────────────────┐
  │ 月初                              月末       │
  │ ████████████████████░░░░░░░░░░░░░░░░░░░░░░ │
  │ ◀── 消費済み (2,100) ──▶◀── 残り (2,900) ──▶│
  └─────────────────────────────────────────────┘

  エラーバジェットの使い方:
  - 残りが多い → 新機能リリースやリファクタリングに使う
  - 残りが少ない → リリース凍結、信頼性改善に集中

MTTD / MTTR

インシデント対応の時間指標

インシデントのタイムライン:

  障害発生        検出          対応開始       復旧完了
     │            │              │              │
     ▼            ▼              ▼              ▼
  ───●────────────●──────────────●──────────────●───▶ 時間
     │            │              │              │
     │◀── MTTD ──▶│              │              │
     │  (検出時間) │              │              │
     │            │◀──────── MTTR ──────────────▶│
     │            │  (復旧時間)                   │
     │                                           │
     │◀──────────── 影響時間 ────────────────────▶│

指標	正式名称	意味	短縮する方法
MTTD	Mean Time To Detect	障害が発生してから検出するまでの平均時間	アラート設計の改善、異常検知
MTTR	Mean Time To Recover	障害を検出してから復旧するまでの平均時間	ランブック整備、自動復旧

オブザーバビリティによるMTTD/MTTRの改善

                      改善前           改善後
  MTTD（検出）:       30分    →       3分
  ┌──────────────────────────────────────────────┐
  │ 改善前: ユーザーからの報告で気づく             │
  │ 改善後: メトリクスアラートで自動検出           │
  └──────────────────────────────────────────────┘

  MTTR（復旧）:       120分   →       25分
  ┌──────────────────────────────────────────────┐
  │ 改善前: ログをgrepで手動検索、原因特定に時間   │
  │ 改善後: トレースで即座にボトルネック特定        │
  │         構造化ログで関連イベントを瞬時に検索    │
  └──────────────────────────────────────────────┘

IDサービスでのMTTD改善例:

障害シナリオ	改善前の検出方法	改善後の検出方法	MTTD改善
特定テナントの認証エラー率上昇	ユーザーからの問い合わせ	テナント別エラー率メトリクス	30分 → 2分
トークンエンドポイントのレイテンシ悪化	定期的な手動チェック	p99レイテンシアラート	60分 → 1分
DBコネクションプールの枯渇	アプリケーションのハング	コネクション使用率メトリクス	15分 → 即座

オブザーバビリティの成熟度モデル

4段階の成熟度

成熟度モデル:

  レベル4: プロアクティブ
  ┌─────────────────────────────────────────────────────────────┐
  │ 異常予兆の自動検出、エラーバジェット管理、自動復旧            │
  │ 例: コネクションプール使用率のトレンドから枯渇を事前に予測    │
  └─────────────────────────────────────────────────────────────┘
           ▲
  レベル3: オブザーバビリティ
  ┌─────────────────────────────────────────────────────────────┐
  │ 構造化ログ + メトリクス + トレースの統合分析                  │
  │ 任意の質問に対して原因を調査できる                           │
  │ 例: 「テナントAのCIBA認証だけが遅い原因」を即座に特定        │
  └─────────────────────────────────────────────────────────────┘
           ▲
  レベル2: 基本監視（モニタリング）
  ┌─────────────────────────────────────────────────────────────┐
  │ CPU/メモリ/ディスクの監視、基本的なアラート                   │
  │ ヘルスチェック、死活監視                                     │
  │ 例: 「CPU > 80% でアラート」                                │
  └─────────────────────────────────────────────────────────────┘
           ▲
  レベル1: アラートなし
  ┌─────────────────────────────────────────────────────────────┐
  │ ログファイルのみ、ユーザー報告で障害を認識                    │
  │ 例: 「ユーザーから "ログインできない" と連絡が来て初めて気づく」│
  └─────────────────────────────────────────────────────────────┘

成熟度の評価基準

観点	レベル1	レベル2	レベル3	レベル4
ログ	ファイル出力のみ	集約・検索可能	構造化・相関付け	異常パターン検出
メトリクス	なし	インフラメトリクス	アプリメトリクス（RED/USE）	SLI/SLOベース
トレース	なし	なし	分散トレーシング導入	サンプリング最適化
アラート	なし	閾値ベース	SLOベース	予兆検知
インシデント対応	手動・属人的	基本的なランブック	体系的な調査プロセス	自動復旧

成熟度向上のロードマップ

推奨ステップ:

  Step 1: 基本監視の導入（レベル1 → 2）
  ────────────────────────────────────
  ・ヘルスチェックエンドポイントの実装
  ・インフラメトリクス収集（CPU/メモリ/ディスク）
  ・基本的なアラート設定
          │
          ▼
  Step 2: 構造化ログの導入（レベル2 → 3）
  ────────────────────────────────────
  ・JSON形式の構造化ログに移行
  ・リクエストID/テナントIDの付与
  ・ログ集約基盤の構築
          │
          ▼
  Step 3: アプリメトリクスの導入（レベル2 → 3）
  ────────────────────────────────────
  ・REDメソッドに基づくメトリクス計装
  ・SLI/SLOの定義
  ・ダッシュボード構築
          │
          ▼
  Step 4: 分散トレーシングの導入（レベル3）
  ────────────────────────────────────
  ・OpenTelemetry SDKの組み込み
  ・コンテキスト伝播の実装
  ・トレースとログの相関付け
          │
          ▼
  Step 5: プロアクティブ運用（レベル3 → 4）
  ────────────────────────────────────
  ・エラーバジェットの運用
  ・異常検知の導入
  ・自動復旧の実装

まとめ

概念	ポイント
モニタリング vs オブザーバビリティ	モニタリングは既知の問題、オブザーバビリティは未知の問題にも対応
3本柱	ログ（詳細）・メトリクス（集計）・トレース（経路）を組み合わせる
SLI/SLO	ユーザー視点の指標を定義し、エラーバジェットで信頼性とスピードのバランスを取る
MTTD/MTTR	オブザーバビリティの成熟度が上がるほど検出・復旧が速くなる
成熟度モデル	段階的に投資し、ビジネス要件に見合ったレベルを目指す

最終更新: 2026-03-04 対象: SaaSアプリケーション開発者、SRE

このドキュメントの目的​

モニタリングとオブザーバビリティの違い​

モニタリング: 既知の問題を監視する​

オブザーバビリティ: 未知の問題を調査できる能力​

比較まとめ​

オブザーバビリティの3本柱​

ログ・メトリクス・トレースの役割​

3本柱の関係​

SLI / SLO / SLA​

3つの概念の関係​

SLI（Service Level Indicator）の設計​

SLO（Service Level Objective）の設計​

エラーバジェット​

MTTD / MTTR​

インシデント対応の時間指標​

オブザーバビリティによるMTTD/MTTRの改善​

オブザーバビリティの成熟度モデル​

4段階の成熟度​

成熟度の評価基準​

成熟度向上のロードマップ​

まとめ​