メトリクスとアラート設計
このドキュメントの目的
メトリクスの種類と適切な選択方法を理解し、REDメソッド・USEメソッドを活用した実践的なメトリクス設計ができるようになることが目標です。また、アラート疲れを防ぐ効果的なアラート設計の原則を学びます。
IDサービスを題材にした具体例を使用しますが、設計原則自体はあらゆるSaaSに共通して適用できます。
メトリクスの種類
4つの基本メトリクスタイプ
メトリクスタイプの概要:
Counter（カウンター） Gauge（ゲージ）
┌──────────────────┐ ┌──────────────────┐
│ 累積値（増加のみ）│ │ 現在値（増減あり）│
│ │ │ │
│ ▲ │ │ ╱╲ │
│ │ ╱ │ │ ╱ ╲ ╱╲ │
│ │ ╱ │ │ ╱ ╲╱ ╲ │
│ │╱ │ │ ╱ ╲ │
│ └──────▶ │ │ └──────▶ │
│ 例: リクエスト総数│ │ 例: 接続数 │
└──────────────────┘ └──────────────────┘
Histogram（ヒストグラム） Summary（サマリー）
┌──────────────────┐ ┌──────────────────┐
│ 値の分布 │ │ 値の分位数 │
│ │ │ │
│ █ │ │ p50: 120ms │
│ █ █ │ │ p90: 250ms │
│ █ █ █ │ │ p99: 890ms │
│ █ █ █ █ █ │ │ p999: 2100ms │
│ └──────▶ │ │ │
│ 例: レイテンシ分布│ │ 例: レイテンシ要約│
└──────────────────┘ └──────────────────┘
メトリクスタイプの選択基準
| タイプ | 特徴 | 使い所 | IDサービスでの例 |
|---|---|---|---|
| Counter | 単調増加、リセットはプロセス再起動時のみ | イベント回数の計測 | auth_requests_total, token_issued_total |
| Gauge | 任意の値（増減可能） | 現在の状態の計測 | active_sessions, db_connection_pool_size |
| Histogram | 値をバケットに分類、分布を記録 | レイテンシ・サイズの分布 | auth_request_duration_seconds |
| Summary | クライアント側で分位数を計算 | 正確な分位数が必要な場合 | token_validation_duration_seconds |
Histogram vs Summary
| 観点 | Histogram | Summary |
|---|---|---|
| 集約可能性 | 複数インスタンスの集約が可能 | インスタンス間の集約が不正確 |
| パフォーマンス | バケット数に比例するメモリ使用 | 分位数計算のCPUコスト |
| 柔軟性 | バケット境界を事前に定義する必要 | 分位数をクエリ時に変更可能 |
| 推奨 | ほとんどの場合はHistogramを推奨 | 正確な分位数が必要な特殊ケース |
REDメソッド
サービスメトリクスの設計
REDメソッドは、リクエスト駆動型サービスのメトリクス設計フレームワークです。
REDメソッドの3要素:
┌─────────────────────────────────────────────────┐
│ REDメソッド │
│ │
│ R: Rate（レート） │
│ 1秒あたりのリクエスト数 │
│ │
│ E: Errors（エラー） │
│ 失敗したリクエストの割合 │
│ │
│ D: Duration（デュレーション） │
│ リクエストの処理時間 │
│ │
│ → 「ユーザーから見たサービスの健全性」を計測 │
└─────────────────────────────────────────────────┘
IDサービスでのREDメト リクス設計
| エンドポイント | Rate | Errors | Duration |
|---|---|---|---|
POST /token | token_requests_total (Counter) | token_errors_total{error="invalid_grant"} | token_request_duration_seconds (Histogram) |
GET /authorize | authorize_requests_total | authorize_errors_total{error="access_denied"} | authorize_request_duration_seconds |
POST /userinfo | userinfo_requests_total | userinfo_errors_total{error="invalid_token"} | userinfo_request_duration_seconds |
POST /ciba | ciba_requests_total | ciba_errors_total{error="expired_token"} | ciba_request_duration_seconds |
REDメトリクスから分かること
REDメトリクスによるサー ビス健全性の把握:
正常時:
┌─────────────────────────────────────────────┐
│ Rate: 500 req/s（安定） │
│ Errors: 0.1%（正常範囲） │
│ Duration: p99 = 200ms（正常範囲） │
└─────────────────────────────────────────────┘
異常パターン1: トラフィック急増
┌─────────────────────────────────────────────┐
│ Rate: 2000 req/s ← 急増 │
│ Errors: 5% ← 増加 │
│ Duration: p99 = 3000ms ← 悪化 │
│ → スケールアウトまたはレートリミット必要 │
└─────────────────────────────────────────────┘
異常パターン2: 外部依存の障害
┌─────────────────────────────────────────────┐
│ Rate: 500 req/s（変化なし） │
│ Errors: 30% ← 急増 │
│ Duration: p99 = 10000ms ← 大幅悪化 │
│ → 外部APIのタイムアウト（DBやSMS API等） │
└─────────────────────────────────────────────┘
USEメソッド
リソースメトリクスの設計
USEメソッドは、インフラリソースのメトリクス設計フレームワークです。
USEメソッドの3要素:
┌─────────────────────────────────────────────────┐
│ USEメソッド │
│ │
│ U: Utilization（使用率） │
│ リソースがどの程度使われているか │
│ │
│ S: Saturation（飽和度） │
│ リソースの待ち行列・溢れ具合 │
│ │
│ E: Errors（エラー） │
│ リソース関連のエラー │
│ │
│ → 「インフラの健全性」を計測 │
└─────────────────────────────────────────────────┘
IDサービスでのUSEメトリクス設計
| リソース | Utilization | Saturation | Errors |
|---|---|---|---|
| CPU | cpu_usage_percent | cpu_throttled_seconds_total | - |
| メモリ | memory_usage_bytes | memory_swap_usage_bytes | memory_oom_kills_total |
| DBコネクションプール | db_pool_active / db_pool_max | db_pool_pending_requests | db_pool_timeout_total |
| スレッドプール | thread_pool_active / thread_pool_max | thread_pool_queue_size | thread_pool_rejected_total |
REDメソッドとUSEメソッドの使い分け
┌───────────────────────────────────────────────────────────┐
│ メトリクス設計の全体像 │
│ │
│ ユーザーに近い側 インフラに近い側 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ REDメソッド │ │ USEメソッド │ │
│ │ │ │ │ │
│ │ サービスの │ │ リソースの │ │
│ │ 健全性を計測 │ │ 健全性を計測 │ │
│ │ │ │ │ │
│ │ Rate │ │ Utilization │ │
│ │ Errors │ │ Saturation │ │
│ │ Duration │ │ Errors │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 「ユーザーは快適か?」 「基盤は持つか?」 │
│ │
│ → まずREDで異常を検出 │
│ → 次にUSEで根本原因を特定 │
└───────────────────────────────────────────────────────────┘
メトリクス命名規則
命名規約
一貫した命名規則により、メトリクスの意味を素早く把握できるようにします。
命名パターン:
<namespace>_<subsystem>_<name>_<unit>
例:
idp_auth_requests_total ← リクエスト合計（Counter）
idp_auth_request_duration_seconds ← リクエスト処理時間（Histogram）
idp_db_connections_active ← アクティブDB接続数（Gauge）
idp_token_issued_total ← トークン発行数（Counter）
命名のベストプラクティス
| ルール | 良い例 | 悪い例 | 理由 |
|---|---|---|---|
| 単位をサフィックスに含める | _seconds, _bytes, _total | _latency, _size | 単位の曖昧さを排除 |
| snake_caseを使用 | request_duration | requestDuration | Prometheus標準に準拠 |
Counterには_totalを付ける | requests_total | requests_count | タイプの明示 |
| 基本単位を使用 | _seconds（秒） | _milliseconds | 変換の手間を省く |
| 動詞より名詞を使用 | errors_total | failed_total | 一貫性の維持 |
ラベル設計
ラベル設計の原則:
┌─────────────────────────────────────────────────────┐
│ 良いラベル設計 │
│ │
│ idp_auth_requests_total{ │
│ method="password", ← 認証方式 │
│ status="success", ← 結果 │
│ tenant_id="tenant-a" ← テナント（マルチテナント） │
│ } │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ 悪いラベル設計（高カーディナリティ） │
│ │
│ idp_auth_requests_total{ │
│ user_id="user-12345", ← ユーザーIDは値が多すぎる │
│ request_id="req-xxx", ← リクエストIDは一意すぎる │
│ ip_address="1.2.3.4" ← IPアドレスも多すぎる │
│ } │
└─────────────────────────────────────────────────────┘
カーディナリティの管理
| カーディナリティ | 値の例 | メトリクスラベルとして | 代替 手段 |
|---|---|---|---|
| 低（推奨） | method={"password","otp","fido2"} | 適切 | - |
| 中（注意） | tenant_id（数十〜数百） | 許容範囲だがモニタリング必要 | - |
| 高（避ける） | user_id, request_id | 不適切（メモリ・ストレージ爆発） | ログに記録 |
ルール: ラベルの値の組み合わせ（カーディナリティ）が数千を超える場合は、メトリクスではなくログに記録します。
アラート設計
アラート疲れの問題
アラート疲れの悪循環:
大量のアラート
│
▼
┌──────────────┐
│ 対応しきれない │
└──────┬───────┘
│
▼
┌──────────────┐
│ アラートを │
│ 無視し始める │
└──────┬───────┘
│
▼
┌──────────────┐
│ 本当に重要な │
│ アラートも │
│ 見逃す │
└─── ───┬───────┘
│
▼
┌──────────────┐
│ インシデント │
│ 対応の遅延 │
└──────────────┘
アラートの重要度分類
| 重要度 | 対応方針 | 通知先 | IDサービスでの例 |
|---|---|---|---|
| Critical（P1） | 即座に対応（24/7） | PagerDuty / 電話 | サービス全停止、全テナントの認証不能 |
| High（P2） | 1時間以内に対応 | Slack（即時） | 特定テナントの認証エラー率50%超 |
| Warning（P3） | 翌営業日に対応 | Slack（通常） | DBコネクションプール使用率80%超 |
| Info（P4） | 確認のみ | ダッシュボード | 証明書の有効期限が60日以内 |
効果的なアラートの原則
良いアラートの条件:
┌─────────────────────────────────────────────────────┐
│ 1. アクション可能（Actionable） │
│ → 受信者が具体的に何かできる │
│ │
│ 2. 緊急性がある（Urgent） │
│ → 今すぐ対応が必要（翌日でよいならP3以下） │
│ │
│ 3. ユーザー影響がある（User-impacting） │
│ → ユーザーが実際に困っている / 困る予兆がある │
│ │
│ 4. ランブックがある（Documented） │
│ → 対応手順が文書化されている │
└─────────────────────────────────────────────────────┘
SLOベースのアラート
従来の閾値ベースアラートとSLOベースアラートの違いを示します。
閾値ベース vs SLOベース:
閾値ベースアラート（従来型）:
┌─────────────────────────────────────────────────────┐
│ ルール: エラー率 > 1% でアラート │
│ │
│ 問題: 一時的なスパイクでもアラート発火 │
│ ノイズが多くなりがち │
└─────────────────────────────────────────────────────┘
SLOベースアラート（推奨）:
┌─────────────────────────────────────────────────────┐
│ ルール: 「このペースでエラーが続くと、 │
│ SLO（月間99.95%）を達成できない」場合にアラート│
│ │
│ バーンレート = 実際のエラー消費速度 / 許容速度 │
│ │
│ 例: バーンレート > 14.4（1時間ウィンドウ） │
│ → 月間エラーバジェットの2%を1時間で消費 │
│ → Critical アラート │
│ │
│ 例: バーンレート > 6（6時間ウィンドウ） │
│ → 月間エラーバジェットの5%を6時間で消費 │
│ → Warning アラート │
└─────────────────────────────────────────────────────┘
ランブック（対応手順書）
アラートには必ずランブック（対応手順書）を紐付けます。
ランブックの構成:
┌─────────────────────────────────────────────────────┐
│ アラート名: auth_error_rate_high │
│ │
│ 概要: │
│ 認証エラー率がSLOバーンレートを超過 │
│ │
│ 影響: │
│ ユーザーがログインできない可能性 │
│ │
│ 調査手順: │
│ 1. ダッシュボードでテナント別エラー率を確認 │
│ 2. エラーログでエラーコードを確認 │
│ 3. 外部依存（DB, SMS API）の状態を確認 │
│ │
│ 対応手順: │
│ - DB障害の場合: フェイルオーバー実行 │
│ - SMS API障害の場合: フォールバック有効化 │
│ - 原因不明の場合: エスカレーション │
│ │
│ エスカレーション先: │
│ #ops-incident チャンネル │
└─────────────────────────────────────────────────────┘
まとめ
| 設計領域 | ポイント |
|---|---|
| メトリクスタイプ | Counter（累積）、Gauge（現在値）、Histogram（分布）を適切に選択 |
| REDメソッド | Rate / Errors / Duration でサービスの健全性を計測 |
| USEメソッド | Utilization / Saturation / Errors でリソースの健全性を計測 |
| 命名規則 | <namespace>_<subsystem>_<name>_<unit> の形式を統一 |
| カーディナリティ | ラベル値の組み合わせが数千を超えないように管理 |
| アラート設計 | SLOベースのアラート、ランブックの紐付け、重要度分類でアラート疲れを防止 |
最終更新: 2026-03-04 対象: SaaSアプリケーション開発者、SRE