パフォーマンスチューニング実技

ボトルネックの特定・Webサーバー設定・DBクエリ改善・キャッシュ戦略まで、アニメーション図解と仮想コンソール演習で体系的に学べます。

待機中

パフォーマンスチューニングとは

▶ 遅いリクエスト → ボトルネック特定 → 最適化 フロー(アニメーション)

遅いリクエスト p95 = 2400ms ボトルネック DB Seq Scan 最適化済み p95 = 45ms 計測 改善

レイテンシ (Latency)

リクエスト送信からレスポンス受信までの時間。ユーザーが「遅い」と感じる直接的な指標です。

スループット (Throughput)

単位時間あたりの処理量(req/s)。システムの容量とスケール性を測る指標。

TTFB (Time To First Byte)

最初の1バイトが届くまでの時間。サーバー処理時間+ネットワーク遅延の合計。

テイル遅延 (p95/p99)

遅い側5%/1%のレスポンス時間。平均値では見えない劣化を捉える重要指標。

ボトルネックの特定方法

▶ レイヤー別ボトルネック探索(アニメーション)

Browser CDN Load Balancer App Server Database Storage
ツール計測対象危険ライン確認のポイント
top / htop CPU使用率 80%以上が持続 プロセスごとのCPU消費を確認。sysCPUが高ければカーネル側、userが高ければアプリ側。
free -m / vmstat メモリ使用量 swap使用量が増加 available が少なくswapが増え始めたらメモリ不足。OOMキラー発動の前兆。
iostat -x 1 ディスクI/O await > 20ms, %util > 90% ディスク応答時間と使用率。DB書き込みが重いときに顕著。
ss -tlnp / netstat ネットワーク接続 TIME_WAIT大量蓄積 接続数と状態を確認。keepalive未設定だと接続の生成/破棄コストが高い。
curl -w '%{time_total}' レスポンス時間 TTFB > 500ms 外部から見た応答時間。内部計測と乖離があればネットワーク/プロキシに原因。

Webサーバのチューニング

▶ 同時接続処理 — チューニング前後比較(アニメーション)

Before workers=1 conn=512 待機/失敗多発 After workers=4 conn=2048 並列処理 → 失敗0

Nginx worker_connections

同時接続数の上限を引き上げ。workerプロセス数 × connectionsが最大同時接続。

Before

512 (デフォルト)

After

1024-4096

Gunicorn workers

CPU数に合わせてワーカーを増やし、並列処理能力を向上。メモリとのバランスに注意。

Before

1 worker

After

2×CPU+1

gzip圧縮

転送量を60-80%削減。CPU負荷は微増だがネットワーク改善が大きい。

Before

無効

After

text/html, application/json, css, js

keepalive

TCP接続を再利用して接続確立コスト(3-way handshake)を削減。

Before

無効

After

keepalive_timeout 75s

静的ファイルキャッシュ

ブラウザキャッシュにより2回目以降のロードが劇的に高速化。

Before

毎回転送

After

expires 30d + Cache-Control

データベースチューニング

▶ Seq Scan vs Index Scan — クエリ実行パス比較(アニメーション)

クエリ SELECT * Seq Scan 12ms 全件走査 Index Scan 0.2ms ピンポイント 遅いパス (No Index) 速いパス (Index) 結果返却

EXPLAIN ANALYZE

クエリの実行計画を確認。Seq Scan(全件走査)がボトルネックになっていないかチェック。

インデックス設計

WHERE/JOIN/ORDER BYに使うカラムにインデックスを作成。複合インデックスの順序に注意。

コネクションプーリング

pgbouncer等で接続を再利用。毎回新規接続だとオーバーヘッドが大きい(特にSSL時)。

N+1クエリ解消

select_related/prefetch_related(Django)で関連データを一括取得。100回のクエリが1-2回に。

スロークエリログ

log_min_duration_statement = 200ms で遅いクエリを自動記録。改善対象の発見に必須。

キャッシュ戦略

▶ キャッシュ HIT / MISS フロー(アニメーション)

Request Cache Check HIT ✓ 即返却 8ms MISS ✗ DBへ 340ms Database
レイヤーツールTTL目安効果
ブラウザキャッシュ Cache-Control, ETag 静的: 30日, API: 0 最も高速。サーバーへのリクエスト自体が発生しない。
CDNキャッシュ Cloudflare, CloudFront 1時間〜1日 世界中のエッジでレスポンスを返却。オリジンサーバー負荷を大幅削減。
アプリケーションキャッシュ Redis, Memcached 60秒〜5分 DB問い合わせ結果をメモリに保持。読み取り多い画面で効果大。
DBクエリキャッシュ pg_stat_statements クエリプラン 実行計画のキャッシュでプランニングコストを削減。

仮想コンソール演習

演習を選び、次のコマンド実行を押すと疑似ログが流れます。数値の変化を確認してください。

この演習の目的

待機中

成功の判定基準

    改善・次のステップ