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

パフォーマンスチューニングで一番多い失敗は、計測せずに「たぶんここが遅い」と思った場所を直すことです。効果がなかったり、別の場所を悪化させたりします。大事なのは次の3つです。①目標をユーザー体験の数字（「注文APIのp99を300ms以下」など）で決める。②計測して、時間の大半を使っている場所（ボトルネック）を1つに絞る。③1回に1つだけ変えて、同じ条件で前後を比べる。

アムダールの法則のとおり、全体の時間のうち小さな割合しか占めない部分をいくら速くしても、全体はほとんど速くなりません。APMのトレースで「1リクエストの時間がどこに使われているか」の内訳を見て、一番大きいところから手をつけます。

6の「回帰を防ぐ」まで終わらせて、初めて改善が定着する。

全体の60%を占めるDBを半分にする方が、25%のアプリを2倍にするより効く。

レスポンス時間は、ほとんどが速く、一部がとても遅い、右に長い尻尾のある分布になります。平均値はこの尻尾に引っ張られつつも隠してしまうので、p50（中央値・普段の体験）、p95、p99（遅い側の体験）を見ます。p99が1秒なら、100回に1回は1秒以上待たされています。1人が1日に何十回もAPIを呼ぶなら、ほぼ全員が毎日その遅さを体験している計算です。

マイクロサービスで1回のリクエストが多くのサービスを並列に呼ぶと、テールレイテンシの増幅が起きます。それぞれのサービスでp99の遅さに当たる確率は1%でも、100個呼べばどれか1つに当たる確率は約63%になり、全体のレイテンシは一番遅いものに引きずられます。

計測の注意：平均値を何本も平均しても正しいp99は出ません。パーセンタイルはヒストグラムから計算します。また、負荷試験ツールが「前のリクエストが返ってから次を送る」作りだと、遅い時間帯のリクエストが少なく数えられ、実際より良い結果に見えることがあります（coordinated omission）。

平均150msでも、100人に1人は620ms以上待っている。

依存先が増えるほど、p99の対策が全体の速さを決める。

ORM（ActiveRecord、Django ORM、Hibernateなど）で関連データを使うと、意識しないうちに起きます。たとえば記事一覧を表示し、それぞれの記事の著者名を出すと、記事の数だけ著者を取りに行くクエリが流れます。1回1msでも、往復が100回あれば100msです。開発環境ではデータが少なくDBも同じマシンにあるので気づかず、本番で件数が増えてから表面化します。

# N+1：記事の数だけ users へのクエリが流れる（Rails）
posts = Post.limit(100)
posts.each { |post| puts post.user.name }

# 改善：関連をまとめて取得（2回のクエリで済む）
posts = Post.includes(:user).limit(100)
posts.each { |post| puts post.user.name }

N+1はDBだけでなく、外部APIやキャッシュ（Redisへの1件ずつのGET）でも起きます。ループの中でネットワーク越しの呼び出しをしていないかを確認し、まとめて取得する（RedisならMGETやパイプライン）ようにします。

クエリ1回は速くても、回数が多ければ往復の時間が積み重なる。

第7章「データベース」：アプリケーションとDB負荷

手順は、①スロークエリログやPerformance Insights、pg_stat_statementsで「合計時間（1回の時間×回数）」が大きいクエリを見つける、②EXPLAIN（実際に実行して測るならEXPLAIN ANALYZE）で実行計画を見る、③読む行数を減らすようにインデックスやクエリを変える、④同じデータ量で前後を比べる、の順です。1回は遅くないが回数がとても多いクエリが、合計では一番重いことがよくあります。

-- 遅い：日付に関数をかけているのでインデックスが使えない
SELECT id, total FROM orders WHERE DATE(created_at) = '2026-11-01';

-- 速い：範囲条件にすると created_at のインデックスが使える
SELECT id, total FROM orders
 WHERE created_at >= '2026-11-01' AND created_at < '2026-11-02';

本番の大きなテーブルにインデックスを追加するときは、作成中のロックと負荷に注意します。MySQLのオンラインDDLやPostgreSQLのCREATE INDEX CONCURRENTLYを使い、負荷の低い時間帯に実施します。

管理画面の深いページや、全件をページングで処理するバッチで効果が大きい。

必要な並列数はリトルの法則で見積もれます。「同時に処理中の数 ＝ 1秒あたりの件数 × 1件あたりの時間」です。たとえば毎秒200リクエストを平均50msで処理するなら、同時に処理中なのは約10件です。ここから、必要なスレッド数やDB接続数の目安が立ちます。処理が遅くなると同時に処理中の数が増え、スレッドや接続が足りなくなって、待ち行列がさらに伸びるという悪循環になります。

接続プールは、DBへの接続をあらかじめ作って使い回す仕組みです。接続を毎回作るのは重いので必須ですが、大きくしすぎるとDB側でコンテキストスイッチやロック競合が増えて、かえって遅くなります。HikariCPの資料では「コア数×2＋ディスク数」程度が出発点として紹介されています。スケールアウトすると「台数×プールサイズ」でDBへの接続数が増えるので、DBの上限を超えないように計算しておきます。

オートスケールの最大台数で計算しておかないと、負荷が高いときにDBが接続を拒否する。

キャッシュの平均レイテンシは「ヒット率×キャッシュの時間＋ミス率×元の時間」です。キャッシュ1ms、DB 50msなら、ヒット率90%で平均5.9ms、99%で1.5msと、最後の数％で数倍変わります。ヒット率は必ず監視し、下がったら原因（キーの設計、TTL、メモリ不足による追い出し）を調べます。

キャッシュ以外にも、事前計算（夜間バッチで集計しておく、マテリアライズドビュー）や、読み取りレプリカへの分散も、読み取りの負荷を下げる手段です。ただし、キャッシュは原因を隠すだけになりやすいので、遅い原因（N+1やインデックス不足）を直したうえで使うのが基本です。

90%から99%に上げると、平均の速さが4倍になる。

非同期化すると、利用者への応答は速くなりますが、「処理がまだ終わっていない」状態が生まれます。画面での見せ方、失敗時のリトライ、二重実行を防ぐ冪等性、キューの滞留の監視をセットで設計します。

利用者の待ち時間は2.6秒から0.13秒に。裏の処理量は変わらないので、ワーカーの能力は別に確保する。

プロファイラは、プログラムのどの関数がCPU時間やメモリを使っているかを測る道具です。結果はフレームグラフで見るのが一般的で、横幅が広い関数ほど時間を使っています。本番で常時、低い負荷で取り続ける継続的プロファイリング（Datadog、Pyroscopeなど）を入れておくと、遅くなったときに前後を比べられます。

横幅の広い塊を見つけ、その関数がなぜそんなに時間を使うのかを考える。

インフラで解決するのは最後の手段ではありませんが、原因を特定する前にお金で解決すると、根本原因が残り、コストも増えます。「どの資源が飽和しているか」をUSE法（使用率・飽和・エラー）で確認してから選びます。

第13章「コスト管理（FinOps）」：SREとコスト（FinOps）

ツールはk6、Locust、JMeter、Gatlingなどです。負荷をかける側のマシンが先に限界になっていないか、キャッシュが温まった状態か冷えた状態か、外部サービスに負荷をかけてしまわないか（モックにするか、相手と調整するか）にも注意します。結果からリトルの法則で必要な台数を見積もり、オートスケールの最大台数とDBの接続数の上限を決めます。

限界点の手前で運用し、そこに近づいたら増やす。限界点の位置は負荷試験でしか分からない。