REDメソッドとは？マイクロサービス監視の3指標（流量・失敗・所要時間）と実装手順を解説

REDメソッドとは、サービスの振る舞いを「Rate（流量）・Errors（失敗）・Duration（所要時間）の3指標に絞って、すべてのサービスに同じ形で当てる」監視の手法です。Tom Wilkieが提唱し、Googleの4つのゴールデンシグナルからリクエスト側に効く3つを取り出して簡約したもので、マイクロサービスのように似た形のサービスが多数並ぶ環境で威力を発揮します。この記事では3指標の定義と、Prometheus・PromQLを使った具体的な取り方、リソース側のUSEメソッドやGolden Signalsとの層別の使い分け、そしてバッチやストリーム処理では過剰になる境界までを、実装者の解像度でまとめます。

まとめ：REDメソッドの結論とUSEメソッドとの使い分け

先に結論を置きます。REDメソッドは「どのサービスにも流量・失敗・所要時間の3指標だけを、まったく同じ形で貼る」という統一の型です。サービスごとに監視指標を考え直す手間をなくし、初めて見るサービスでも3枚のグラフで健康状態を読めるようにするのが狙いになります。

3指標のうち利用者の体感に直結するのはDuration（所要時間）とErrors（失敗）です。Rateは負荷の文脈を与える背景情報で、単体では良し悪しを判断できません。所要時間は平均ではなく95・99パーセンタイルで見るのが要点で、平均が正常でも上位1%のリクエストが極端に遅ければ一部の利用者は障害として体感します。

視点の向きで姉妹手法と役割が分かれます。REDはリクエスト側（サービスの外から見た振る舞い）、USEメソッドはリソース側（CPUやメモリの詰まり）を見ます。REDで「遅い・失敗している」という症状を掴み、その原因が「どの資源の飽和か」をUSEで掘る、という組み合わせが扱いやすい構成です。リソース側の詳細はUSEメソッド（使用率・飽和・エラー）とはで整理しています。飽和（Saturation）を明示的に含む上位の枠組みが必要なら、Golden Signals（4つのゴールデンシグナル）とはを傘として併用します。

REDメソッドの定義と提唱の出所（流量・失敗・所要時間の3指標）

REDメソッドは、監視ツールを手がけたTom Wilkieが2010年代後半に「サービスを計装するときの最小セット」として広めた手法です。頭字語のR・E・Dは、リクエストを受けて処理するすべてのサービスに共通して当てる3つの数字を表します。GoogleがSRE本で示した4つのゴールデンシグナル（遅延・トラフィック・エラー・飽和）から、サービス自身が出せる3つを取り出した簡約版という位置づけになります。

Rate・Errors・Durationの3指標がそれぞれ捉えるサービスの振る舞い

各指標が観測する対象は次の通りです。3つをどのサービスにも同じ形で当てるのがREDの核で、サービスごとに指標を作り分けないところに価値があります。

Rateは秒あたりのリクエスト数で、負荷の大きさとその変化を示します。Errorsは全体に対する失敗の割合（エラー率）として見るのが実務的です。流量が増えれば絶対数も増えるため、率で正規化しないと判断を誤ります。Durationは1つの平均値ではなく分布として持ち、後述するパーセンタイルで裾野の遅さを捉えます。

4つのゴールデンシグナルから飽和を落として3指標に簡約した理由

REDが飽和（Saturation）を外しているのには理由があります。飽和は「資源がどれだけ詰まっているか」を表す指標で、サービス自身のコードからは測りにくく、CPUやコネクションプールといったリソース側の観測が必要になるからです。REDは「アプリケーションが自分で出せる3つ」に絞ることで、どの言語・どのフレームワークでも同じ計装を横展開できるようにしています。

そのぶん飽和の観測はUSEメソッドやリソース監視に委ねる分担になります。RED単体では「詰まりの予兆」を先取りできず、レイテンシが悪化してから原因を資源側に下ろす後追いの構図です。この役割分担を理解しておくと、REDとUSEをどちらも作り込む必要はなく、層で貼り分ければよいと分かります。

各指標のPrometheus・PromQLでの計測手順とクエリの考え方

REDの実装は「サービスの入口に3種類のメトリクスを1組だけ計装し、それを全サービスで揃える」作業に落ちます。ここではPrometheusとPromQLを前提に、流量・失敗・所要時間の取り方を見ていきましょう。これらの生の指標は、収集して時系列で見るメトリクス監視の基盤に乗せて初めて継続運用になります。

リクエストカウンタとヒストグラムからRate・Errors・Durationを取り出す

3指標はたった2つのメトリクスから導けます。処理件数のカウンタと、所要時間のヒストグラムです。下の対応で、1組の計装から3枚のグラフが揃います。

Rateは、増え続けるリクエストカウンタに rate() を当てて「毎秒あたりの増分」に直します。Errorsは同じカウンタをステータスコードのラベルで分け、5xxの rate() を全体の rate() で割ったエラー率です。Durationは histogram 型メトリクスに histogram_quantile() を当て、p95・p99を取り出します。カウンタは単調増加のため、必ず rate() や increase() を通してから読む点に注意してください。

マイクロサービス横断で同じダッシュボードをテンプレートで量産する設計

REDの真価は、この3枚組をサービス数だけ複製できる点にあります。メトリクス名とラベル（サービス名・エンドポイント）の付け方を全サービスで統一しておけば、共通ダッシュボードはテンプレート変数でサービスを切り替える1枚で済む構成です。新しいサービスを足しても、同じ計装ライブラリを組み込むだけで監視が付いてきます。

エラー率とp99レイテンシには、サービス横断で同じ閾値のアラートを敷けます。ただし瞬間値ではなく数分の移動窓で評価し、流量が極端に少ない時間帯のエラー率は分母が小さく暴れるため、一定の流量を下回る区間はアラートから除外するのが誤検知を防ぐコツです。個々のサービス内部の詳細な追跡が要るときは、APM（アプリケーション性能監視）のトレースへ掘り下げます。

RED・USE・Golden Signalsの違いと監視の層別の使い分け

REDは単独で完結する手法ではなく、リソース側・全体側の手法と層で組み合わせます。混同されやすいUSEメソッド・Golden Signalsとの境界を、視点の向きで切り分けます。

リクエスト側のREDとリソース側のUSE・全体側のGolden Signalsの境界

3つは競合ではなく観測する層が違います。REDはサービス単位の振る舞いを、USEは資源単位の詰まりを、Golden Signalsは飽和まで含めたサービス全般を見ます。

REDとGolden Signalsはよく似ていますが、Golden Signalsが飽和を含むのに対し、REDはそれを落として3つに絞った実装寄りの型です。多数のサービスに一律で貼るならRED、飽和も含めて1つの重要サービスを丁寧に見るならGolden Signals、という選び分けになります。REDとUSEは対象が「サービスか資源か」で明確に分かれるため、両方を層として貼っておくのが定石です。

症状はREDで検知し原因はUSEで掘る運用での切り分けの流れ

実務では、アラートはRED（症状ベース）で鳴らし、原因の切り分けはリソース側に下ろす構成が扱いやすいです。あるサービスのp99レイテンシがSLOを割ったアラートを受けたら、まずそのサービスのRED3枚で流量急増か失敗増かを確かめ、次にそのサービスが載るホストのUSEマトリクスを開いて飽和した資源を特定します。この症状ベースのアラート設計は、上位概念であるオブザーバビリティ（可観測性）の考え方とも地続きです。原因ではなく症状でアラートし、原因はUSEで辿る分担を固定すると、警報の数を抑えながら復旧を速められます。

REDメソッドの導入判断（バッチ等の非リクエスト系で過剰になる境界）

ここは判断を言い切ります。REDメソッドは万能ではなく、「リクエストを受けて応答を返すサービス」でこそ本領を発揮する手法です。採用が効く条件と、あえて別の指標に置き換える場面を条件付きで示します。

REDを全サービスに一律で貼る価値があるシステムの条件と要件

次のいずれかに当てはまるなら、RED3指標を全サービスに揃える価値があります。

• マイクロサービスやAPIのように、リクエスト駆動のサービスが多数並ぶ
• サービスの数が増減しやすく、監視の付け外しを定型化したい
• SLOをレイテンシとエラー率で定義し、その達成を継続して追う

この場合、共通の計装ライブラリと1枚のテンプレートダッシュボードを用意すれば、サービスが増えても監視が自動で付いてきます。エラー率とp99を軸にSLOアラートを組めるため、利用者影響の一次検知をREDに寄せられる点も効いてきます。似た形のHTTPサービスが並ぶ受託開発の基盤では、REDが最も費用対効果を出す対象です。

バッチ・ストリーム・非リクエスト系でREDを補正すべき理由と代替指標

逆に、日次バッチや常時稼働のストリーム処理、キュー消費のワーカーのような非リクエスト系では、REDの素直な適用は過剰になります。これらは「単発のリクエストと応答」という単位を持たないため、Rateやp99レイテンシがそのままでは意味を持たないからです。バッチにp99を貼っても、読み取る対象がありません。

この場合はREDの発想を保ちつつ指標を置き換えます。ストリーム処理なら1秒あたりの処理メッセージ数（Rateの読み替え）、失敗メッセージ率（Errors）、メッセージが積まれてから処理されるまでの遅延やコンシューマーラグ（Durationの読み替え）が代替の3指標です。バッチなら成否・実行時間・処理件数に置き換え、キューの滞留はUSE的な飽和として別に監視します。監視基盤の設計から計装、SLOアラートの継続運用までを内製で抱えきれない場合は、外部の伴走を得る選択もあるでしょう。当社のシステムの保守運用・内製化支援では、REDやGolden Signalsを起点にした監視設計と運用体制づくりの相談を受け付けています。

よくある質問

REDメソッドの実装でつまずきやすい点をまとめます。

REDメソッドとUSEメソッドはどちらを使うべきですか？

対象で選びます。個々のサービスの振る舞いを見るならRED（流量・失敗・所要時間）、CPUやメモリなどの資源の詰まりを見るならUSE（使用率・飽和・エラー）です。実務では両方を層として併用し、REDで症状を検知してからUSEで原因の資源を掘る流れが扱いやすい構成になります。

REDメソッドとGolden Signalsは何が違いますか？

含む指標の数が違います。Golden Signalsは遅延・トラフィック・エラー・飽和の4つ、REDはそこから飽和を落とした3つです。REDは「アプリが自分で出せる指標だけ」に絞ってあるため、多数のサービスへ同じ計装を横展開しやすく、飽和が必要な場面ではリソース監視やUSEで補います。

Durationは平均で見てはいけないのですか？

平均は避け、パーセンタイルで見てください。平均レイテンシは少数の極端に遅いリクエストを薄めてしまい、一部の利用者だけが体感する遅延を隠します。p95・p99を見ると「上位数%がどれだけ待たされているか」が分かり、これがSLOの判断材料です。ヒストグラム型メトリクスに分位数関数を当てて取り出します。

エラー率はどう定義すればよいですか？

失敗リクエスト数を全リクエスト数で割った率で定義します。絶対数だと流量が増えるほど自然に増えて判断できないため、率での正規化が必須です。何を失敗とみなすか（HTTP 5xxのみか、4xxの一部を含めるか）はサービスの性質で決め、全サービスで定義を揃えると横断比較が効きます。

バッチ処理やワーカーにもREDは使えますか？

そのままでは使えません。リクエストと応答の単位がないため、Rateやレイテンシを読み替える必要があります。ストリームなら処理メッセージ数・失敗率・コンシューマーラグ、バッチなら成否・実行時間・件数に置き換え、REDの「症状を3つで掴む」考え方だけを流用するのが現実的です。

関連記事

• USEメソッド（使用率・飽和・エラー）とは：REDと対になるリソース側の性能分析手法
• Golden Signals（4つのゴールデンシグナル）とは：飽和を含む、REDの上位にあたる監視枠組み
• メトリクス監視とは？仕組みと実装：RED3指標を時系列で継続監視に乗せる基盤
• APM（アプリケーション性能監視）とは：サービス単位の性能をトレースまで掘り下げるツール
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱：RED指標が乗るメトリクス層の上位概念