# USE メソッド ## 定義 USE メソッド(Utilization, Saturation, Errors)は、Brendan Gregg が考案したシステムパフォーマンス調査のための観察型メソドロジであり、「すべてのリソースについて、使用率・飽和度・エラーをチェックする」という一文に要約される。ここでの用語は次のように定義される。使用率はインターバル中にリソースが要求処理でビジー状態だった時間の割合(メインメモリ等の容量リソースでは能力ベースの割合)、飽和度は処理できずキューイングされている要求の度合い、エラーはエラーイベントの回数である。ツールを起点にする「ツールメソッド」とは対照的に、USE メソッドはシステムリソース(CPU・メモリ・ネットワークインターフェイス・ストレージデバイス・アクセラレータ・コントローラ・インターコネクト等)を起点に反復し、答えるべき問いのリストを先に完全化してからツールを探す。チェックの順序はエラー→飽和度→使用率で、エラーがもっとも客観的で解釈しやすいために最初に弾き出す。指標が見つからない問いは Known-Unknowns として記録し、パフォーマンスアナリストにとって有用な情報とする。USE メソッドはハードウェアリソースだけでなく、ミューテックスロック・スレッドプール・プロセス数・ファイルディスクリプタ数などのソフトウェアリソース、cgroup 等によるクラウド/コンテナのリソースコントロールにも適用できる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.9) USE メソッドをソフトウェアリソースに応用する場合、アプリケーションの内部コンポーネントを示す機能ダイアグラムがあれば、個々のソフトウェアリソースについて使用率・飽和度・エラーの指標を取り、意味があるかどうかを検討するとよい。たとえば要求を管理するキューとワーカースレッドのプールを持つアプリケーションでは、使用率(一定期間中に要求処理でビジー状態になっているスレッド数の平均の割合)・飽和度(期間中における要求キュー長の平均)・エラー(拒否・失敗した要求の数)の3指標を定義できる。ファイルディスクリプタのような有限リソースでも同様に、使用率(上限に対する使用中の割合)・飽和度(OSのふるまいに依存。ファイルディスクリプタ待ちでブロックされるスレッド数など)・エラー(EFILEの"Too many open files"のようなアロケーションエラー)として定義できる。このプロセスをアプリケーションのコンポーネントごとに繰り返し、意味のない指標を外していくことで、他のメソドロジに移る前の簡単なチェックリストが作れる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] §5.4.4) 6章はハードウェアリソースであるCPUへのUSEメソッド適用例を示す。個々のCPUについて、使用率(アイドルスレッド以外を実行していた時間の割合)・飽和度(on-CPU待ちでキューイングされている実行可能スレッドの割合)・エラー(ECC等の修正可能エラーの増加によりCPUがオフラインになる場合を含む)をチェックする。エラーがもっとも簡単に解釈できるため最初にチェックするという2章の原則どおり、CPUでもまずECCエラー等をチェックしてからスケーラビリティの問題([[スケジューラレイテンシ]])に進む。クラウド環境のようにCPUクォータ(リソースコントロール)が設定されている場合は、物理的な使用率だけでなく設定された限界に対する使用率も計測すべきであり、物理CPUが100%に達する前にクォータを使い切って予想より早く飽和が起きることがある。GPU等のアクセラレータも同様の3指標でチェックできる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.2) 7章はメインメモリへのUSEメソッド適用例を示す。システム全体で、使用率(物理メモリと仮想メモリの両方について、使われているメモリとフリー状態のメモリの割合)・飽和度(ページスキャン・ページング・スワッピング・OOMキラーによる強制終了の度合い)・エラー(ソフトウェア起因のメモリアロケーション失敗やOOMキラー、ハードウェア起因のECCエラー)をチェックする。飽和の継続がメモリ問題の兆候であるため、まず飽和度から確認することが推奨される。物理メモリの使用率はツールが参照されていないファイルシステムキャッシュページをどう扱うかで表示が変わるため、ドキュメントの確認が必要である。オーバーコミットしていないシステムでは仮想メモリの使用率チェックも必要になる。著者は、メモリ問題の解決には「パフォーマンスモニタリング→USEメソッド→使用形態の特性の把握」の順序を推奨している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.4.2) 9章はディスクデバイスとディスクコントローラという2種類のハードウェアリソースへのUSEメソッド適用例を示す。ディスクデバイスでは、使用率(ビジー状態だった時間の割合)・飽和度(I/Oがキューで待機している度合い)・エラー(デバイスエラー。S.M.A.R.T.データ等)をこの順にチェックする(ただし実務ではエラー→飽和度→使用率のチェック順序が推奨される)。仮想ディスクでは物理ディスクの実態を反映しない使用率が報告される場合がある点に注意が必要である。ディスクコントローラでは、使用率が時間ベースではなく現在値の最大値に対する割合(スループット・稼働率)で定義される点がディスクデバイスと異なり、iostat(1)のようなツールがディスクごとの値しか出さない場合は同一コントローラ配下のディスクを合算してコントローラの値を求める必要がある。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] §9.5.2) 12章はUSEメソッドを診断メソドロジとしてではなく、ベンチマーキングの過程で使うと述べる。ベンチマーク実行中にUSEメソッドを適用すれば、何らかのコンポーネント(ハードウェアかソフトウェア)の使用率が100%に達しているか、システムが限界に達していないかを確実に見つけられるとされる。CPUプロファイリングのケーススタディでは、新システムのディスクスループット低下調査でまずUSEメソッドを適用しディスクがビジー状態でないことを確認したうえで、システム時間(カーネル内)のCPU使用を手がかりにフレームグラフへと分析を進め、`zfs_zone_io_throttle()`というI/Oスロットリング機構がボトルネックだったことを特定している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.3.1, §12.3.4) 16章は、Netflix のマイクロサービスが VM からコンテナへの移行で3、4倍高速化した事案の実務調査で、60秒チェックリストの直後にUSEメソッドを適用した。`uptime`・`mpstat` によりロードアベレージとCPU使用率・アイドル時間を比較し、VM ホスト(48 CPU、ロードアベレージ85、アイドル2%)がCPU飽和状態にある一方、コンテナホスト(64 CPU、ロードアベレージ18、アイドル78%)は余裕があるという結論をこの段階で得た。この結果は「CPUがボトルネックだ」という仮説の入口にすぎず、著者はその後PMC・ソフトウェアイベント・トレーシングという3種の異なる粒度のツールでさらに深掘りしている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.3) ## 横断的知見 - 2章はUSEメソッドを「ミューテックスロック・スレッドプール・ファイルディスクリプタ数などのソフトウェアリソースにも適用できる」と一般論として述べるにとどまるが、5章はワーカースレッドプールとファイルディスクリプタという2つの具体例で使用率・飽和度・エラーの3指標を実際に定義しており、抽象的な適用可能性の主張が具体的なチェックリスト作成手順として裏づけられている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]]) - 5章のワーカースレッドプール例(使用率=ビジースレッド比率、飽和度=要求キュー長)は、[[アプリケーション並行実行モデル]]で説明されるサービススレッドプール・CPUスレッドプール・SEDAのいずれのモデルにもそのまま適用できる汎用的なチェックリストであり、並行実行モデルの選択とUSEメソッドによる健全性チェックが独立した関心事として組み合わせられることを示す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]]) - 5章のソフトウェアリソース(スレッドプール・ファイルディスクリプタ)と6章のハードウェアリソース(CPU)は、どちらも「使用率→飽和度→エラー」という同じ3指標の型を保ったまま、飽和度の定義だけがリソースの性質に応じて変わる(キュー長 対 ランキュー待ちスレッド数)。USEメソッドの一般性は、飽和度という抽象概念を各リソースの具体的なキューイング機構にマッピングし直す作業として現れる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.2) - CPU(6章)とメモリ(7章)はどちらもハードウェアリソースだが、飽和度チェックの優先順位が異なる。CPUの3指標(使用率→飽和度→エラー)はエラー先出しの一般原則どおりに並ぶ一方、メモリの解説では「飽和の継続はメモリに問題がある兆候なのでまず飽和度をチェックしよう」と、2章の一般原則(エラー→飽和度→使用率)より飽和度を先に置く実務的な順序が明示される。これは、メモリではページング・スワッピング・OOMキラーという飽和の兆候がエラーより先に観測しやすく実務上のシグナル価値が高いためと考えられ、USEメソッドのチェック順序はリソースの特性に応じて2章の一般原則から逸脱してよいことを示す一例になっている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.9, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.4.2) - メモリの使用率(7章)は「ファイルシステムキャッシュを未使用として扱ってよいか」という解釈の分かれ目を持つ。これはCPU・スレッドプール(5, 6章)の使用率が単純な「ビジー時間の割合」で定義されるのと対照的で、容量リソース(メインメモリ)は稼働リソース(CPU・スレッド)と違い、USEメソッドの「使用率」の定義自体がツールのメモリ会計方針に依存するという注意点を示している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.4.2, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.2) - ディスクデバイス(9章)は仮想ディスクの使用率が物理ディスクの実態から乖離しうる点で、メモリ(7章)のファイルシステムキャッシュ会計問題と同じ構造の注意点を持つ。どちらも「OSが報告する使用率」と「リソースの実際のビジー状態」の間にツール・抽象化レイヤ由来のギャップが生じることを示しており、USEメソッドの「使用率」は常にどの抽象化レイヤで計測されたかを確認する必要がある。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.4.2, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] §9.3.9.1) - ディスクコントローラ(9章)の使用率は時間ベースではなくスループット/稼働率の現在値対上限値の割合で定義され、CPU・メモリ・ディスクデバイスの「ビジー時間の割合」という時間ベース定義から外れる例外である。USEメソッドの使用率定義は「時間ベース」が既定だが、上限が明確なリソース(帯域・オペレーション数)では「容量ベース」に切り替わることを9章が明示しており、[[待ち行列理論]]のM/D/1モデルが暗黙に仮定する時間ベース使用率とは異なる計測軸になりうる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] §9.5.2.2) - 2〜9章がUSEメソッドを「本番環境で発生した問題の診断」の文脈で説明するのに対し、12章はベンチマーキング(意図的に負荷をかける実験)の文脈でUSEメソッドを援用する点で適用場面が異なる。しかし12章のZFS I/Oスロットリング特定事例(ディスクがビジーでないことをUSEメソッドで確認してからCPUプロファイリングへ進む)は、6章のCPU適用例と同じ「まず飽和度・使用率でリソースを絞り込み、次に詳細分析へ進む」という手順をそのまま踏襲しており、USEメソッドが診断とベンチマーク分析という異なる目的の間で同一の手順として転用可能であることを示す。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.2, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.3.1, §12.3.4) - 16章の実務適用は、USEメソッドが単独で結論を出すツールではなく「絞り込みの最初の一段」として機能することを示す。`mpstat`によるCPU使用率・アイドル時間の比較だけではVMの方が負荷が高いことしかわからず、VMのロードアベレージが高い根本理由(IPC低下・LLCヒット率低下・高頻度コンテキストスイッチ)はPMCとトレーシングを追加してはじめて判明した。これは6章がCPUへのUSEメソッド適用を「まずエラー・飽和度・使用率をチェックしてからスケジューラレイテンシ等の詳細分析に進む」と説明する構造と一致し、USEメソッドの出力(ボトルネックのあるリソースの特定)と、そのリソースがなぜボトルネックなのかという原因究明は別の分析ステップであることを、実際の障害調査事例が具体的に裏づけている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.2, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.3-16.1.7) ## 未解決の問い - USE メソッドと RED メソッドを同時に運用する場合、両者の指標をひとつのダッシュボードでどう統合し、どちらの兆候を優先的にドリルダウンの起点とすべきか。 - ハードウェアキャッシュのように「使用率が高いほど望ましい」リソースを USE メソッドのチェックリストから除外する境界線は、どのような基準で機械的に判定できるか。 - Netflix の「99パーセンタイルと平均の差を飽和度の近似として使う」という代替指標は、他のマイクロサービス環境やレイテンシ分布の性質(単峰/二峰)が異なる環境でもどの程度妥当か。 - ディスクコントローラのような容量ベース使用率(スループット/稼働率の上限に対する割合)を持つリソースは、CPU・メモリのような時間ベース使用率のリソースと比べてUSEメソッドのチェックリストをどう体系的に区別すべきか。9章は個別の例外として示すのみで、一般化した分類基準は与えていない。 ## 関連 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] — USE メソッドの原典解説(§2.5.9)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] — ワーカースレッドプール・ファイルディスクリプタへの適用例(§5.4.4)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] — CPU/GPUへの適用例(§6.5.2)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] — メインメモリへの適用例(§7.4.2)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] — ディスクデバイス・ディスクコントローラへの適用例(§9.5.2)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] — ベンチマーキング過程でのUSEメソッド適用とZFS I/Oスロットリング特定事例(§12.3.3.1, §12.3.4)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] — Netflix コンテナ移行の実務調査でのUSEメソッド適用例(§16.1.3)。 - [[ベンチマーキング]] — USEメソッドを併用してベンチマークの制約要因(限界)を特定するメソドロジ。 - [[RED メソッド]] — サービス指向の補完メソドロジ。 - [[Brendan Gregg]] — USE メソッドの考案者。 - [[Netflix]] — Atlas による USE 指標の実運用例。 - [[アプリケーション並行実行モデル]] — USE メソッドの適用対象となるスレッドプールモデル。 - [[CPU利用率]] / [[スケジューラレイテンシ]] — CPUへの適用で参照する使用率・飽和度の詳細概念。 - [[仮想メモリとページング]] / [[Linuxメモリ回収]] — メモリへの適用で参照する飽和度指標(ページング・スワッピング・OOMキラー)の詳細概念。 ## 出典 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.9 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] §5.4.4(USE メソッドのソフトウェアリソースへの適用) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.2(USE メソッドのCPU/GPUへの適用) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.4.2(USE メソッドのメインメモリへの適用) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] §9.5.2(USE メソッドのディスクデバイス・コントローラへの適用) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.3.1, §12.3.4(USE メソッドのベンチマーキングへの適用) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.3(Netflix コンテナ移行調査での実務適用)