USE法とRED法：メトリクスの体系

メトリクス選定に「体系」が要る理由

監視を始めると指標は際限なく増やせます。CPU、メモリ、ディスクIO、各種キュー長、HTTP ステータス別カウント……。問題は数ではなく網羅性と視点の整合です。やみくもに集めると、障害時に「どこを見ればボトルネックがわかるか」が定まらない。USE法とRED法は、この「何を測れば対象を漏れなく診断できるか」を少数の固定軸に落とし込むためのフレームワークです。

両者の本質的な違いは視点の向きにあります。USE法は Brendan Gregg が提唱したもので、CPU・メモリ・ディスク・ネットワークといった**リソース（供給側）を見ます。RED法は Tom Wilkie が広めたもので、サービスが受け取る要求（需要側）**を見ます。同じ障害を、供給の枯渇として見るか、需要の劣化として見るか——この90度違う2視点を両方持つことが体系化の出発点です。

USE法：すべてのリソースに3つの指標

USE法の主張は単純です。システム内のあらゆるリソースについて、利用率・飽和・エラーの3つを測れ。リソースを列挙し、機械的に3軸を当てると診断の抜けがなくなります。

• Utilization（利用率）: そのリソースが仕事に使われていた時間の割合。CPU なら使用率、ディスクなら IO で埋まっていた時間の割合。0〜100% の平均的な忙しさを表します。
• Saturation（飽和）: リソースがさばききれず待たされている量。実行可能だが CPU を待つスレッド数（run-queue 長）、メモリのスワップ量、ディスクIOのキュー長など。利用率が「どれだけ使ったか」なのに対し、飽和は「どれだけ不足したか」を表します。
• Errors（エラー）: そのリソース由来のエラーイベント数。ディスクの読み書き失敗、ネットワークのパケットドロップ、ECC訂正不能エラーなど。

なぜ飽和が利用率より早く動くのか。待ち行列理論 がこれを説明します。利用率 ρ（ロー）が1に近づくと、待ち時間は 1/(1-ρ) に比例して急増します。ρ が 0.7 から 0.9 へ上がるとき、利用率の見た目はわずか0.2の変化ですが、待ち時間（＝飽和の体感）は 1/0.3 ≒ 3.3 から 1/0.1 = 10 へと約3倍に跳ねる。利用率は線形に見えても、その裏で飽和は非線形に爆発しているのです。

利用率 ρ と平均待ち時間の関係（M/M/1 近似）
  ρ=0.5  → 待ち係数 1/(1-ρ) = 2
  ρ=0.8  → 待ち係数 = 5
  ρ=0.9  → 待ち係数 = 10
  ρ=0.95 → 待ち係数 = 20   ← 利用率の差は小さいが飽和は急増

RED法：すべてのサービスに3つの指標

RED法は視点を反転させ、リクエストを受けるサービスごとに3つを測れと言います。

• Rate（要求レート）: 単位時間あたりのリクエスト数（秒間リクエスト）。需要そのものの大きさ。
• Errors（エラー）: 失敗したリクエストの数または率。HTTP 5xx や、業務的に失敗とみなすレスポンス。
• Duration（処理時間）: リクエストの応答時間の分布。

RED法の要点は、Duration を平均で見ないことです。応答時間は右に長い裾を引くため、平均はテール（遅い少数）を覆い隠します。パーセンタイル統計 で見たとおり、p50・p90・p99 の分布で見て初めてユーザー体験の劣化が見えます。Rate と Errors も「率」として読み、Errors はレートを母数とする比率（エラー率）で正規化するのが基本です。

両者の関係：USEは原因、REDは症状

USE と RED は競合せず相補的です。ユーザーが体感するのは常に RED 側（遅い・失敗する）であり、その原因は多くの場合 USE 側（どこかのリソースが飽和した）にあります。

症状（RED）          原因（USE）
Duration p99 悪化  ← CPU run-queue 飽和 / ディスクIOキュー増大
Errors 増加        ← メモリ枯渇でOOM / コネクションプール飽和
Rate 急増          → 下流リソースの利用率・飽和を押し上げる

障害対応の定石は、REDで影響を検知し、USEで原因を局在化するという流れです。ダッシュボードはサービス階層を RED で、その下の各リソースを USE で並べると、上から下へ原因を辿れます。オブザーバビリティの三本柱 でいうメトリクスの設計指針として、この2フレームワークは「何をメトリクス化すべきか」の最小セットを与えます。

Four Golden Signals との関係

Google SRE 本の Four Golden Signals（4つの黄金信号）は、Latency・Traffic・Errors・Saturation の4つです。これは RED の3つに USE の飽和を足したハイブリッドとして理解できます。

Golden Signals が RED に Saturation を1つだけ足したのは偶然ではありません。RED の3つはサービス境界の外側から見える症状ですが、それだけでは「あと何分で破綻するか」がわからない。Saturation を1つ加えることで、症状が出る前の余力を測れます。利用率（Utilization）を採らなかったのは、利用率が飽和より情報量が少なく、テールを捉えにくいという USE 法と同じ判断です。

メトリクスの「数」を増やすことは容易ですが、増やすほど カーディナリティ のコストが膨らみ、アラートも騒がしくなります。USE・RED・Golden Signals が支持されるのは、少数の固定軸で網羅性を保証するからです。リソースには3つ、サービスには3つ——この機械的な当てはめが、ダッシュボードとアラートを「漏れなく、かつ最小限に」保ちます。

まとめ

• USE法はリソース（供給側）を利用率・飽和・エラーで、RED法はサービス（需要側）を要求レート・エラー・処理時間で測る。視点が90度違う相補的フレームワーク。
• 飽和（Saturation）は利用率100%未満でも待ち行列として伸びる先行指標で、待ち行列理論の 1/(1-ρ) により利用率より非線形に早く悪化する。
• RED の3指標はそのまま SLI/SLO の素材になり、Duration はパーセンタイルで見るのが必須。
• Four Golden Signals は RED に Saturation を加えた4つで、症状（RED）と先行指標（USE の飽和）を橋渡しする。
• 障害対応は RED で症状を検知し、USE で原因リソースを局在化する流れが定石。少数の固定軸が網羅性とコストを両立させる。