USEメソッドとは？リソースのボトルネックを見つける性能分析の手順を解説

USEメソッドとは、システムの性能問題を「リソースごとに使用率（Utilization）・飽和（Saturation）・エラー（Errors）の3つを確認する」という一定の順序で切り分ける、Brendan Greggが提唱した分析手法です。無数のメトリクスを眺める前に、CPU・メモリ・ディスク・ネットワークといった各リソースに同じ3項目のチェックリストを当て、詰まっている箇所を最短で突き止めます。この記事では3観点の定義と、mpstat・vmstat・iostat・PSIを使ったLinuxでの取り方、REDメソッドやGolden Signalsとの層別の使い分け、そしてフルマネージド環境ではUSEが過剰になる境界までを、実装者の解像度でまとめます。

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

先に結論を置きます。USEメソッドは「すべてのリソースについて、使用率・飽和・エラーを順に見る」という網羅の型で、リソース側のボトルネックを取りこぼさずに見つけるための手順です。障害時に「どのメトリクスから見るか」で迷う状態を、リソース×3観点のマトリクスに落として解消します。

3観点のうち実務で効くのは飽和（Saturation）です。使用率はリソースが忙しい割合、エラーは失敗の件数を指しますが、性能劣化の予兆は「捌ききれず待ち行列に積まれた仕事＝飽和」に最も早く表れます。使用率が80%でも飽和ゼロなら余力があり、使用率が同じでも待ち行列が伸びていれば体感は悪化する、という切り分けがUSEの勘所になります。

視点の向きで姉妹手法と役割が分かれます。USEはリソース側（下から上）、REDメソッドやGolden Signalsはリクエスト側（上から下）を見ます。ユーザー体験の異常はRED/Golden Signalsで掴み、その原因が「どの資源の飽和か」をUSEで掘る、という組み合わせが扱いやすい構成です。4信号側の全体像はGolden Signals（4つのゴールデンシグナル）とはで整理しています。フルマネージドなサーバーレスでは、そもそもホスト資源が見えないためUSEの適用範囲は狭まります（詳細は導入判断の章）。

USEメソッドの定義と提唱の出所（使用率・飽和・エラーの3観点）

USEメソッドは、パフォーマンス分野の技術者Brendan Greggが2012年前後に体系化し、Communications of the ACM（2013年）の論文「Thinking Methodically about Performance」でも示された分析手法です。頭字語のU・S・Eは、あらゆるリソースに共通して当てる3つの問いを表します。数百のメトリクスに溺れず、資源単位で機械的に確認する点に価値があります。

使用率・飽和・エラーの3指標がそれぞれ捉えるリソース性能の側面

各観点が観測する対象は次の通りです。3つを1つのリソースに揃って当てるのがUSEの核で、どれか1つだけでは見落としが出ます。

使用率には2種類あります。時間ベース（一定期間に資源が忙しかった割合。ディスクやCPU向き）と、容量ベース（総量に対する消費割合。メモリやストレージ容量向き）です。飽和は「今は処理できず待たされている仕事の度合い」で、待ち行列長やスワップ発生が代表例になります。エラーは通常カウントで取れ、多くは即座に原因を絞れます。

エラーの確認を最初に置く理由と使用率だけを見る監視設計の落とし穴

Greggの推奨は「エラーを最初に、次に使用率、最後に飽和」という順序です。エラーは件数が少なく、原因の特定と修正が速いため、先に潰しておくと後の切り分けが濁りません。ディスクのリードエラーやネットワークの再送は、使用率が正常に見えても性能を静かに削ります。

使用率だけを監視ダッシュボードに並べる設計には落とし穴があります。使用率100%は必ずしも問題ではなく（バッチ処理なら望ましい状態です）、逆に使用率50%でも短時間のバースト飽和で体感が悪化することもあるからです。瞬間の使用率を平均で丸めると、この飽和のスパイクが消えます。使用率は「余力の有無」の一次情報にとどめ、判断は飽和とエラーを合わせて下してください。

各リソースへのUSEの当て方とLinux標準コマンドでの計測手順

USEの実装は「対象リソースを列挙し、各行に使用率・飽和・エラーの取得コマンドを割り当てる」作業に落ちます。ここではLinuxを前提に、CPU・メモリ・ディスク・ネットワークの4資源で具体的な取り方を見ていきましょう。これらの生の指標は、収集して時系列で見るメトリクス監視の基盤に乗せて初めて継続運用になります。

CPU・メモリ・ディスク・ネットワークへの3観点の割り当てと取得コマンド

資源ごとの取得手段を一覧にします。同じ3観点を横に並べると、どの資源のどの観点が未計装かが一目で分かります。

CPUの使用率は mpstat のusr＋sysで取り、飽和はランキュー長（vmstat のr列）やロードアベレージで判断します。メモリは使用量よりも飽和が効き、スワップの発生（vmstat のsi・so）やOOM Killerの記録が飽和の直接証拠です。ディスクは iostat の使用率と平均待ち行列長、ネットワークはスループットの帯域比と、ドロップ・再送・受信backlogの伸びを見ます。

飽和を横断で捉えるPSI（Pressure Stall Information）の読み方

飽和を資源ごとに別コマンドで追うのは手間なので、Linux 4.20系以降で使えるPSI（Pressure Stall Information）を併用すると横断的に把握できます。PSIはCPU・メモリ・I/Oの3つについて、タスクが資源待ちで停滞した時間の割合を出力し、飽和を横断で見る共通の指標です。値はプロセス統計ディレクトリ配下のpressureエントリから読み取れます。

PSIのsome行は「一部のタスクが待たされた時間割合」、full行は「全タスクが同時に待たされた割合」を示します。full値が継続して立つメモリやI/Oは、飽和が体感障害に直結している資源です。使用率メトリクスが天井に張り付く前にPSIが先行して上がることも多く、飽和の早期警報として扱えます。閾値アラートは瞬間値ではなく、10秒・60秒の移動平均に対して設定すると誤検知を抑えられます。

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

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

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

3つは競合ではなく観測する層が違います。REDはRate（流量）・Errors（失敗）・Duration（所要時間）でサービス単位の振る舞いを、USEは資源単位の詰まりを、Golden Signalsは両者を束ねたユーザー向けサービス全般を見ます。

両者は原因究明の流れでつながります。Golden SignalsやREDで「遅い・失敗している」という症状を掴んだら、その原因をUSEで資源に下ろして探すのが定石です。USEにもエラーが含まれ、Golden Signalsにも飽和が含まれるため重複はありますが、対象が資源かサービスかで貼る場所を分けると迷いません。3つを別物として全部を作り込む必要はありません。

症状はリクエスト側で検知し原因はリソース側のUSEで掘る実務の流れ

実務では、アラートはリクエスト側（症状ベース）で鳴らし、USEは掘るための道具として常時ダッシュボード化しておく構成が扱いやすいです。レイテンシがSLOを割ったアラートを受けたら、対象サービスが載るホストのUSEマトリクスを開き、飽和が立っている資源を1つに絞り込みます。この流れはSRE（サイト信頼性エンジニアリング）の障害対応でも定番の切り分けです。原因ではなく症状でアラートし、原因はUSEで辿る、という分担を固定すると警報疲れを抑えられます。

USEメソッドの導入判断（フルマネージド環境で過剰になる境界）

ここは判断を言い切ります。USEメソッドは万能ではなく、「ホストの資源が観測できる環境」でこそ本領を発揮する手法です。採用が効く条件と、あえて簡略化する場面を条件付きで示します。

USEマトリクスを全資源で組む価値があるシステムの条件と要件

次のいずれかに当てはまるなら、全資源のUSEマトリクスを組む価値があります。

• 仮想マシンやベアメタル、オンプレミスでホスト資源に責任を持つ
• データベースやバッチのように資源飽和が性能を直接左右する
• 容量計画のため、飽和の推移を継続して追う必要がある

この場合、資源×3観点の表をそのまま監視の設計図にし、未計装のセルを埋めていくと網羅が保てます。飽和の時系列を持てば、使用率が天井に当たる前の予兆で増強の判断を下せる点が効いてきます。自社で運用するDBサーバーやジョブ基盤は、USEが最も価値を出す対象です。

フルマネージド環境ではUSEを絞り込むべき理由と代替の監視観点

逆に、AWS LambdaやFargate、マネージドDBのようなフルマネージド環境では、USEの全面適用は過剰になります。ホストのCPU使用率やディスク待ち行列は基盤側に隠蔽され、そもそも観測できないからです。ここでUSEマトリクスを律儀に埋めようとしても、取れない指標の空欄が並ぶだけになります。

この場合は、自分が制御できる少数の容量指標だけにUSEの考え方を絞り込みます。具体的には、Lambdaの同時実行数の上限に対する飽和、コンテナのメモリ割り当てに対する使用率とOOM、マネージドDBのコネクションプールの飽和などです。ユーザー体験の一次検知はRED/Golden Signalsに寄せ、USEは「自分が上限を設定した資源」の飽和監視に限定するのが無駄のない設計になります。監視基盤の設計から計装、飽和アラートの継続運用までを内製で抱えきれない場合は、外部の伴走を得る選択もあるでしょう。当社のシステムの保守運用・内製化支援では、USEやGolden Signalsを起点にした監視設計と運用体制づくりの相談を受け付けています。

よくある質問

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

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

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

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

視点の向きが違います。USEはリソース側から詰まりを探す下からの手法、Golden Signalsはユーザー向けサービス全般を見る上からの枠組みです。Golden Signalsのサチュレーション（飽和）はUSEと重なり、両者は「サービスの症状はGolden Signals、その原因の資源飽和はUSE」という分担で組み合わせられます。

使用率と飽和はどう使い分ければよいですか？

使用率は「資源に余力があるか」、飽和は「今すでに待たされているか」を示します。使用率100%でも待ち行列が伸びていなければ問題は起きにくく、逆に使用率が中程度でも飽和が立てば体感は悪化します。判断は飽和を主、使用率を補助として下してください。

飽和は具体的に何を計測すればよいですか？

その資源で「捌けずに積まれた仕事の量」を測ります。CPUならランキュー長、メモリならスワップ発生量、ディスクなら平均待ち行列長が実務的な指標です。Linux 4.20系以降ならPSI（I/O・メモリ・CPUの停滞時間割合）を使うと、資源横断で飽和を統一的に追えます。

サーバーレス環境でもUSEメソッドは使えますか？

限定的に使えます。ホストの資源は基盤側に隠れて観測できないため、全資源のマトリクスは組めません。自分が上限を設定した資源（同時実行数・割り当てメモリ・コネクションプール）の飽和だけにUSEの考え方を適用し、ユーザー体験の検知はGolden Signalsに寄せる形が現実的です。

関連記事

• Golden Signals（4つのゴールデンシグナル）とは：USEを内包する、ユーザー向けサービスの監視枠組み
• メトリクス監視とは？仕組みと実装：USEの生指標を時系列で継続監視に乗せる基盤
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱：USE指標が効くメトリクス層の上位概念
• SREとは？サイト信頼性エンジニアリングの意味：USEによる原因究明が組み込まれる運用文脈