はじめに
本記事は、Brendan Gregg 著「詳解 システム・パフォーマンス 第2版」の書評・まとめです。
読み進める中でシステム性能分析に対する考え方が大きく変わりました。
SRE・インフラ・バックエンドなど、システムのパフォーマンスに関わる方全員に刺さる内容です。
本書の概要
本書は Netflix のパフォーマンスエンジニア Brendan Gregg 氏が著した、Linux システム全体の性能分析・チューニングを体系的に解説した書籍です。対象はアプリケーション層からカーネル、ハードウェアまで「メタルまでのフルスタック」。
全 16 章＋付録という大ボリュームで、以下のような構成になっています。
| パート | 章 | テーマ |
|---|---|---|
| 基礎 | 1〜4章 | イントロ・メソドロジ・OS・可観測性ツール |
| リソース別 | 5〜11章 | CPU・メモリ・FS・ディスク・ネットワーク・クラウド |
| 分析ツール | 12〜16章 | ベンチマーキング・perf・Ftrace・BPF・ケーススタディ |
印象に残った章と内容
1章 イントロダクション
冒頭から「パフォーマンスエンジニアリングとは何か」を丁寧に定義します。
性能分析の視点として ワークロード分析（入力側）と リソース分析（リソース側）という 2 つの立場が示されるだけで、実務の解像度がぐっと上がります。
「パフォーマンスは主観的になりがちだが、明確な目標を定義すれば客観化できる」
チームで性能改善に取り組む際の共通言語として非常に有用な視点です。
また Linux 60秒分析チェックリスト が紹介されており、そのまま使えます。
uptime
dmesg -T | tail
vmstat -SM 1
mpstat -P ALL 1
pidstat 1
iostat -sxz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
これを 60 秒以内に流すだけで「何が起きているか」の全体像をつかめるという考え方は、障害対応の実践でそのまま使えます。
2章 メソドロジ
本書の核心とも言える章で、著者が長年かけて体系化したパフォーマンス分析の方法論が詰まっています。
アンチメソッドへの言及
- 街灯アンチメソッド：知っているツールだけで「なんとなく」探す
- ランダム変更アンチメソッド：当てずっぽうで設定値を変えてみる
- 誰かのせいにするアンチメソッド：自分担当外と断定してたらい回し
「あるある」と感じる方も多いはずです。これらを明確にアンチパターンとして命名し、代替となる体系的メソドロジを提示するスタイルが非常に実践的です。
USEメソッド
著者が提唱する USE（Utilization, Saturation, Errors）メソッド は本書で最も広く参照されるフレームワークです。
すべてのリソースについて、使用率・飽和度・エラー をチェックする
CPU・メモリ・ディスク・ネットワークそれぞれにこの 3 指標を当てはめることで、ボトルネックを漏れなく洗い出せます。
| 指標 | 意味 | 例 |
|---|---|---|
| 使用率 | 一定期間内のビジー率 | CPU 90% |
| 飽和度 | 処理できない要求の待機量 | ランキュー長さ |
| エラー | エラーイベントの回数 | ディスクエラー 50件 |
REDメソッド
マイクロサービス向けには RED（Rate, Errors, Duration）メソッド も紹介されています。
USE がインフラ側の健全性を見るのに対し、RED はユーザー視点のサービス健全性を見ます。両者は補完関係にあります。
パフォーマンスマントラ
チューニングの優先順位として、以下の 6 ステップが「おまじない」として示されています。
- やらない（不要な処理を削る）
- 一度だけやる（キャッシュ）
- 頻度を下げる（ポーリング間隔を伸ばす）
- 遅延実行する（ライトバックキャッシュ等）
- 並列化する（シングル→マルチスレッド）
- 安価な方法で済ます（より速いハードウェアを買う）
上から順に効果が高いという優先順位付けが明快です。
待ち行列理論（M/D/1モデル）
使用率 60% を超えると応答時間が急速に悪化するという M/D/1 モデルの解説は、「なぜ使用率 80% のディスクがボトルネックになるのか」を直感的に理解させてくれます。「60%の法則」 として覚えておくだけで、性能設計の判断軸が変わります。
5〜11章 リソース別詳解
CPU・メモリ・ファイルシステム・ディスク・ネットワーク・クラウドと、リソースごとに 1 章ずつ割かれています。各章は以下の統一構成になっており、辞書として引きやすいのが特徴です。
用語定義 → アーキテクチャ → 方法論 → 可観測性ツール → チューニング
いくつか印象的な点を挙げます。
CPUとメモリ：L1〜L3 キャッシュのアクセスレイテンシを人間のスケールに変換したタイムスケール表が掲載されています。「メインメモリアクセスは約 100ns ≒ コーヒーを取りに行く時間」という感覚的な比較は、最適化の動機として分かりやすいです。
ファイルシステム：従来の分析ツールがディスクに着目しすぎてファイルシステムを見落としがちである、という問題提起から始まります。ディスクの前段にある FS 層のボトルネックを可視化することの重要性が強調されています。
クラウド：マルチテナント環境特有の「ノイジーネイバー問題」や、ゲスト側から物理リソースの実態が見えにくいという課題が整理されています。
13〜15章 perf / Ftrace / BPF
本書第 2 版の大きな特徴が BPF（eBPF）関連の充実した解説 です。
BPF はもともとパケットフィルタリング用のカーネル内仮想マシンでしたが、現在は Linux カーネルの動的トレーシング基盤として広く使われています。BCC（BPF Compiler Collection）や bpftrace というフロントエンドを通じて、実行中のカーネルやユーザー空間プログラムに対してカスタムの計測処理をほぼゼロオーバーヘッドで注入できます。
# execsnoop(8): 実行されたプロセスをリアルタイムで追跡（BCC/bpftrace ベース）
# execsnoop
# PCOMM PID PPID RET ARGS
# ssh 30656 20063 0 /usr/bin/ssh
# sshd 30657 1401 0 /usr/sbin/sshd -D -R
従来は「カーネルエンジニアがろうそくを持って暗い部屋を歩くような」分析しかできなかった領域が、BPF によって高解像度で観測できるようになりました。Linux の可観測性は第二世代に入ったと言えます。
16章 ケーススタディ
「ディスクが遅い」という報告から始まる実際の障害対応が、登場人物の思考過程を追う形で描かれます。USEメソッドで仮説→検証→絞り込みを繰り返し、最終的にメモリリークによるファイルシステムキャッシュの圧迫が原因だったと突き止める流れは、前章までの方法論の使い方を実感するのに最適です。
総評
本書が優れているのは、単なるコマンドリファレンスや「こうすれば速くなる」系のノウハウ集ではなく、なぜそのツールを使うのか・何を見るのか・どう解釈するのか という思考回路ごと伝えようとしている点です。
特定のリソース（CPU やディスク等）を深く調べたい場面で対応章を辞書的に参照する使い方も有効で、著者のウェブサイトや GitHub にも補足資料が豊富にあります。
パフォーマンス分析を「勘と経験」から「方法論と可観測性」に移行させる一冊として、エンジニアのラインナップに加えておく価値があります。