詳解システム・パフォーマンス - 第16章：ケーススタディ

なぜ16章を最初に読むのか

著者 Brendan Gregg は「16章から読み始めることを推奨する」と明言している。

理由：方法論（ch02）を先に学ぶより、実際の問題解決プロセスを体感してから方法論を学んだほうが、概念が腑に落ちる。

実例：「赤いクジラ」問題

状況

顧客サーバーから「定期的な遅延スパイク」の報告
数分ごとにレスポンスタイムが急上昇する

調査の流れ（USEメソッドの実践）

① 問題ステートメントの明確化

まず「問題は何か」を具体化する。曖昧な報告を数値に落とす。

- 遅延スパイクの発生頻度は？ → 約5分ごと
- スパイク時のレイテンシは？ → 通常 5ms → スパイク時 500ms
- 影響範囲は？ → 特定のサーバー1台

② 既存チケット・ログからの仮説立案

サポートチケットや過去のインシデントを検索し、仮説を立てる。

仮説候補：
- バックグラウンドジョブが定期実行されている？
- GCが走っている？
- ディスク書き込みが発生している？

③ USE法で体系的に調査

リソースごとに U・S・E を確認する。

# CPU: 使用率確認
mpstat -P ALL 1 10
# → CPU は正常範囲

# メモリ: スワップ確認
vmstat 1 10
# → si/so は 0 = スワッピングなし

# ディスク: I/O確認
iostat -xz 1 10
# → 5分ごとに %util が急上昇！ → ディスク書き込みが発生

④ 原因の絞り込み

ディスク I/O にフォーカスして原因特定。

# どのプロセスがディスク書き込みをしているか
pidstat -d 1 10
# → redis-server が定期的に大量書き込み

# Redis の設定を確認
grep -i save /etc/redis/redis.conf
# → save 300 1 （300秒ごとにスナップショット）

⑤ 原因特定と解決

Redis の RDB スナップショット（BGSAVE）が5分ごとに実行され、ディスクに大量書き込みが発生していた。

解決策：

Redis の save 設定を調整（頻度を下げるか、AOF に切り替え）
データ量が多い場合はスナップショットが重くなるため、SSD への移行も検討

パフォーマンスエンジニアの思考プロセス

基本サイクル

仮説立案
  ↓
観測（コマンドで確認）
  ↓
絞り込み（関係ないリソースを除外）
  ↓
次の仮説
  ↓
根本原因特定

重要な原則

「なぜ」を繰り返す（5 Whys）

遅延が発生している
  ↓ なぜ？
ディスクI/Oが詰まっている
  ↓ なぜ？
Redisが大量書き込みをしている
  ↓ なぜ？
RDB スナップショットが走っている
  ↓ なぜ（今まで問題なかったのに）？
データ量が増えてスナップショットサイズが大きくなった
  ↓ なぜ気づかなかった？
監視で write バイト数を見ていなかった
→ 根本原因：監視項目の不足

やってはいけないこと

アンチパターン	問題
憶測で設定変更する	原因を特定せず「多分これかも」で変更 → 効果不明で別の問題が起きる
一つのツールだけ見る	`top` だけ見てCPUは正常と判断 → ディスクI/Oが原因だった
早期に結論を出す	最初の仮説が正しいと思い込む
本番で試行錯誤する	観測だけなら安全だが、変更は慎重に

観測 vs 変更

パフォーマンス調査の基本姿勢：まず観測、変更は最後

観測フェーズ（安全）
├── vmstat, iostat, mpstat → リソース統計
├── pidstat → プロセス単位
├── perf stat → CPU カウンタ
└── bpftrace → 動的トレース

    ↓ 原因が特定できたら

変更フェーズ（慎重に）
├── 設定ファイルの変更
├── プロセスの再起動
└── カーネルパラメータのチューニング

チェックリスト：本番障害対応

□ 問題を数値で定義する（どのメトリクスが、どれくらい悪いか）
□ 直近の変更を確認する（デプロイ・設定変更・負荷増加）
□ 60秒診断を実行する（uptime → dmesg → vmstat → iostat → top）
□ USE法でリソースを一つずつ確認する
□ 犯人プロセスを特定する（pidstat -d, pidstat -r）
□ ドリルダウンする（perf, strace, bpftrace）
□ 根本原因を文章で説明できるか確認する
□ 再発防止の監視を追加する