Performance optimization

パフォーマンス最適化

目的

計測に基づいて真のボトルネックを特定し、最小限の変更で性能目標を達成する。 推測による場当たり的な改修を排除し、施策の効果を定量的に検証する。

使うタイミング

• レスポンスタイム・スループット・エラーレートが[[non-functional-requirements]]で定めた目標値を下回るとき
• 本番でスロークエリ・タイムアウト・OOMが頻発しているとき
• リリース前に想定ピーク負荷への耐性を確認したいとき
• コードレビューや[[refactoring]]の際に性能リグレッションの懸念が生じたとき

鉄則

1. 推測するな、計測せよ — 「たぶんここが遅い」で改修しない。必ずプロファイラ・APMのデータを根拠にする
2. 目標なき最適化はしない — [[non-functional-requirements]]で合意した数値目標(例: p95 < 200ms)が起点。目標達成後は止める
3. 早すぎる最適化は諸悪の根源 — まず動くものを作り、遅い場所だけ直す
4. 1施策ずつ適用して前後比較 — 複数施策を同時に当てると効果の切り分けができなくなる
5. 本番相当の環境・データ量で計測 — 開発環境の少量データでは性能問題は再現しない
6. 平均でなくパーセンタイルで見る — p50だけでなくp95/p99を必ず確認する

進め方

1. 目標の確認 — [[non-functional-requirements]]から計測対象のKPI(レイテンシ/スループット/エラーレート)と目標値を確認する
2. 計測環境の整備 — 本番相当のデータ量・負荷を再現できる環境を用意する
3. ベースライン計測 — プロファイラ・APM・負荷テストツールで現状を数値化する(p50/p95/p99を記録)
4. ボトルネック特定 — フレームグラフ・スロークエリログ・EXPLAINの結果から最大のボトルネックを1つ特定する
5. 施策の立案と優先順位付け — 改善インパクト・実装コスト・リスクで施策を並べる
6. 1施策を実装 — 最優先の施策を実装する([[implementation]]参照)
7. 再計測・前後比較 — 同条件で再計測し、ベースラインと比較する
8. 目標達成の判定 — 達成なら終了。未達なら次のボトルネックへ戻る
9. 負荷テスト(リリース前) — 想定ピークの2〜3倍で限界スループットと限界レイテンシを把握する
10. 改善レポートの作成 — 下記テンプレートで成果を記録する

定番ボトルネックと定石

ボトルネック	計測手段	定石
N+1クエリ	スロークエリログ・APMのクエリトレース	eager loading(JOIN / includes / prefetch)
インデックス不足	EXPLAIN / EXPLAIN ANALYZE	適切なインデックスを追加([[database-design]]参照)
大きなペイロード	Network タブ・APM	ページネーション・フィールド絞り込み・gzip圧縮
画像の肥大化	Lighthouse・Network タブ	WebP/AVIF変換・遅延読み込み・CDN配信
フロントの不要な再レンダリング	React Profiler・ブラウザ Performance タブ	メモ化(memo/useMemo/useCallback)・仮想スクロール
同期I/Oの直列実行	プロファイラ・トレース	並列化(Promise.all等)・非同期化
毎回同じ重い計算	プロファイラ・APM	キャッシュ導入(階層・TTL・無効化戦略とセットで)
コネクションプール枯渇	DBモニタリング・APM	プールサイズ調整・コネクション保持時間の見直し
メモリリーク	ヒープスナップショット	オブジェクト参照の解放・イベントリスナーの削除

キャッシュ設計の注意点

キャッシュは「最後の手段」ではなく「副作用が最大の手段」として扱う。

• 階層を整理してから導入: ブラウザ → CDN → アプリ(インメモリ/Redis) → DB(クエリキャッシュ)
• 無効化戦略を先に決める("キャッシュの無効化は計算機科学の二大難問")。更新時パージ・TTL・バージョニングのどれを使うか明示する
• TTLの根拠を記録する(「なんとなく5分」は不可)
• キャッシュヒット率・ミス率を[[monitoring-operations]]で観測する

成果物テンプレート

# 性能改善レポート

## 目標
- 対象: [エンドポイント / 機能名]
- KPI: p95 レスポンスタイム < Xms、スループット > Y rps、エラーレート < Z%

## 計測条件
- 環境: [本番 / ステージング / ローカル]
- データ量: [件数・サイズ]
- 負荷条件: [同時ユーザー数・RPS・テストツール(k6等)]

## ボトルネック一覧

| # | 内容 | 根拠 | 推定インパクト |
|---|------|------|----------------|
| 1 | N+1クエリ (UserController#index) | スロークエリログ: 1リクエストあたり51クエリ | 大 |
| 2 | ... | ... | ... |

## 実施した施策

| # | 施策 | 変更箇所 |
|---|------|---------|
| 1 | User.includes(:posts) に変更 | app/controllers/users_controller.rb |

## 前後比較

| 指標 | 改善前 | 改善後 | 変化率 |
|------|--------|--------|--------|
| p50  | 320ms  | 45ms   | -86%   |
| p95  | 980ms  | 120ms  | -88%   |
| p99  | 2100ms | 310ms  | -85%   |
| エラーレート | 2.1% | 0.0% | - |

## 目標達成判定
- [x] p95 < 200ms → 120ms で達成

## 残課題
- キャッシュ導入(優先度: 低、次スプリントで検討)

チェックリスト

• 性能目標(p95/p99の数値)が[[non-functional-requirements]]に記載されている
• 本番相当のデータ量・環境でベースラインを計測した
• p50だけでなくp95・p99を記録した
• 最大のボトルネックを1つ特定し、根拠(ログ・プロファイル)を残した
• 施策は1つずつ適用し、前後の数値を比較した
• キャッシュを導入する場合、無効化戦略とTTLの根拠を記録した
• 想定ピーク負荷での負荷テストを実施した
• 目標達成後に最適化を停止した
• 改善レポートをレビュー可能な状態で残した

アンチパターン

• 推測ドリブンの改修: 計測せず「たぶんここが遅い」でコードを変更する
• 複数施策の同時適用: 効果の切り分けができなくなり、悪化した施策を特定できない
• 無効化戦略なしのキャッシュ: 古いデータが表示され続けるバグの温床になる
• 開発環境での計測: 少量データでは本番のN+1やフルスキャンが再現しない
• 平均値のみ監視: 外れ値に苦しむユーザーを見落とす
• 目標達成後も最適化を続ける: 可読性・保守性のコストが増大する
• ミクロ最適化への執着: ループ1つのマイクロ秒短縮より、N+1の解消やインデックス追加の方が桁違いに効く

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当
司令塔(メインモデル)	性能目標の確認・ボトルネック候補の優先順位付け・施策採否の判断・レポートの取りまとめ
Opus相当	複雑なボトルネック分析(トレース解析・クエリ実行計画の解釈)・アーキテクチャレベルの改善設計(キャッシュ階層設計・非同期化戦略)
Sonnet相当	計測スクリプトの実装・個別施策の実装([[implementation]])・前後比較表の作成
Haiku相当	メトリクスの収集・スロークエリログの抽出・APMダッシュボードのスクリーンショット取得・定型レポートの整形

関連スキル

• [[non-functional-requirements]] — 性能目標の定義元。目標値なき最適化はしない
• [[database-design]] — インデックス設計・クエリ最適化の詳細
• [[monitoring-operations]] — 本番の継続的な性能監視・アラート設定
• [[refactoring]] — 可読性と性能のトレードオフを判断する際の参考
• [[testing]] — 負荷テストのシナリオ設計・CI組み込み
• [[architecture-design]] — キャッシュ階層・非同期化など構造的改善の設計
• [[code-review]] — 性能リグレッションの早期検出
• [[cicd-deployment]] — 性能テストのパイプライン組み込み