性能と負荷対策

計算量とデータ構造では、自分が書いたコードが遅くなる理由を扱いました。 この章は、その外側——システム全体が、負荷の下でも動き続けるかという話です。

この2つは別の問題です。

計算量とデータ構造  1リクエストの処理が O(n²) だから遅い
この章   1リクエストは速いのに、同時に1000件来ると全部倒れる

サービスが落ちる時、原因の多くは後者です。

まず測る。平均を見ない

性能の議論は、数字が無いと始まりません。

そして、レイテンシは平均で見てはいけません。

1000件のリクエスト
  990件が 10ms
   10件が 5000ms
→ 平均 59ms（速そうに見える）
→ p99  5000ms（100人に1人が5秒待たされている）

ボトルネックを見つける

推測で直さない、というのはデバッグの技術・計算量とデータ構造と同じです。

1. どこで時間を使っているか（分散トレース・監視とオンコール）
   → サービス間のどこで待っているかが一目で分かる
2. そのサービスの中のどこか（プロファイル）
   → go tool pprof / Node の --prof
3. 資源のどれが限界か

資源を見る時は、USE の3つを揃えて見ると漏れません。

□ DB のクエリ待ち（データベースの INDEX・N+1）
□ 外部 API のレスポンス待ち
□ コネクションプールの枯渇 ← 後述。非常に多い
□ ロックの競合
□ ディスク I/O

負荷試験

本番で初めて負荷を知る、を避けるためのものです。

# k6 の例（シナリオを JS で書ける）
k6 run --vus 100 --duration 60s script.js
 
# もっと単純に、1エンドポイントを叩くだけなら
vegeta attack -rate=200 -duration=30s | vegeta report

やる時の注意点です。

□ 本番相当のデータ量で行う（100件のテーブルと1000万件では別物）
□ ウォームアップしてから測る（JIT・キャッシュ・接続確立の分を除く）
□ 段階的に負荷を上げ、「壊れ始める点」を探す
□ 壊れ方を見る（緩やかに遅くなるのか、ある点で急に全滅するのか）

良い壊れ方: 処理できない分を早く断る。処理できた分は正常に返る
悪い壊れ方: 全部を受け付けて全部が遅くなり、最終的に全滅する

キャッシュ

最も効果が大きく、最も事故が多い手段です。

どこに置くか

[ブラウザ] → [CDN] → [ロードバランサ] → [アプリ内メモリ] → [共有キャッシュ] → [DB]
   近い                                                                    遠い
   速い・安い                                                              遅い・正確

利用者に近いほど速く、安く、しかし更新が届きにくくなります。

□ 個人向けのレスポンスは Cache-Control: private, no-store
□ キャッシュキーにユーザー識別子を含める
□ 認証が必要なエンドポイントは、原則キャッシュしない

無効化 — キャッシュの本体はこちら

1. TTL で期限切れにする      最も単純。ズレる時間を許容できるかが判断基準
2. 更新時に明示的に消す      正確だが、消し忘れが起きる
3. 更新時に書き換える        正確だが、書き込みが重くなる

まず TTL を検討してください。 「5分古くても業務上問題ないか」を業務側に確認します。 問題ないなら、それが最も壊れにくい選択です。

   キャッシュ有効中: DB へのアクセス 0 件/秒
   期限切れの瞬間  : DB へのアクセス 5000 件/秒 ← DB が落ちる

・Redis を再起動した
・デプロイでアプリ内キャッシュが消えた
・キャッシュサーバーが障害で落ちた

コネクションプール — 見落とされがちな上限

DB への接続は高コストなので、あらかじめ数本張って使い回します。

アプリ 1インスタンス × プール 10本 × 5インスタンス = DB への最大接続 50

□ プールの使用数・待ち時間をメトリクスに出す（監視とオンコール）
□ 1リクエストで接続を長く保持しない（外部 API 呼び出しをトランザクション内に入れない）
□ スケールアウト時に、DB の最大接続数を超えないか確認する

過負荷への備え

ここからが、Amazon や Google の運用文化で最も重視されている領域です。

リトライは負荷を増やす

マイクロサービスの実務で扱ったとおり、素朴なリトライは障害を悪化させます。

サーバーが不調 → タイムアウト → 全クライアントが再送 → 負荷が2倍 → 完全に停止

指数バックオフ + ジッターが標準的な解です。

1回目: 100ms 待つ
2回目: 200ms 待つ      ← 指数的に伸ばす
3回目: 400ms 待つ
      + それぞれにランダムなばらつき（ジッター）を足す

ジッターが無いと、全クライアントが同じタイミングで再送し、 波が同期して押し寄せます。ランダム化が本質です。

さらに、

□ リトライ回数の上限を決める（3回程度）
□ 多段のリトライを禁じる（各層でリトライすると 3×3×3 = 27倍になる）
□ リトライしてよいエラーか判定する（400 番台は再送しても無駄）

負荷制限（load shedding）

受け付けられない量が来たら、早く断る。

悪い: 全部受け付ける → 全部が遅くなる → 全員がタイムアウトする → 何も返せていない
良い: 処理できる分だけ受ける → 溢れた分は即座に 503 を返す
      → 受けた分は正常に返る

全滅させるくらいなら、一部を確実に成功させるほうが良いという考え方です。

// 単純だが有効: 同時実行数に上限を設ける
sem := make(chan struct{}, 100)
 
func handle(w http.ResponseWriter, r *http.Request) {
    select {
    case sem <- struct{}{}:
        defer func() { <-sem }()
        process(w, r)
    default:
        w.Header().Set("Retry-After", "1")
        http.Error(w, "混雑しています", http.StatusServiceUnavailable)
    }
}

if err := ctx.Err(); err != nil {
    return err   // 呼び出し元はもう待っていない
}

レート制限

こちらは公平性のための仕組みです。

負荷制限   自分を守る（全体の量を制限する）
レート制限 利用者ごとに上限を設ける（1人が全体を食い潰さないように）

トークンバケット方式が一般的で、429 Too Many Requests と Retry-After ヘッダで返します。

静的安定性

依存先が壊れても、現状のまま動き続けられるかという考え方です。

悪い: 設定を配信するサービスが落ちた → 全サービスが起動できなくなる
良い: 最後に取得した設定を保持しており、配信サービスが落ちても動き続ける

悪い: 認可サービスが落ちた → 全リクエストが失敗
良い: 直前の判定結果を短時間保持し、その間は動き続ける（安全側の判断で）

依存先の障害時に「新しいことはできないが、今の状態は維持できる」 —— これが静的安定性です。設計時に「この依存が落ちたら何が起きるか」を 1つずつ確認してください。

スケールさせる

垂直スケール（強いマシンに）  単純。ただし上限があり、停止を伴うことが多い
水平スケール（台数を増やす）  上限が緩い。ただし状態を持てない

水平スケールの前提は、アプリがステートレスであることです。

□ セッションをメモリに持たない（認証と認可の実装。共有ストアかトークンへ）
□ ローカルディスクにファイルを保存しない（オブジェクトストレージへ）
□ どのインスタンスに来ても同じ結果を返す

□ 分かっている波には、事前にスケールしておく
□ 起動を速くする（イメージを小さく、初期化を軽く）
□ 間に合わない分は、負荷制限で守る

実務の落とし穴まとめ

1. 平均レイテンシで判断 — p99 を見る。1ページ複数リクエストで確率は跳ね上がる
2. CPU 使用率だけ見る — 待ち時間は現れない。飽和度を見る
3. キャッシュキーに利用者を含めない — 他人の情報が配信される
4. TTL が全部同じ — 一斉に期限切れしてスタンピードが起きる
5. キャッシュ前提の容量設計 — キャッシュが消えた瞬間に落ちる
6. コネクションプールを監視していない — 「余裕なのに遅い」の定番
7. 各層でリトライ — 掛け算で増幅する
8. ジッターなしのリトライ — 波が同期して押し寄せる
9. 過負荷時に全部受け付ける — 全滅する。早く断るほうがよい
10. フォールバック経路を普段動かさない — いざという時に壊れている
11. オートスケールに頼り切る — 急な波には間に合わない

まとめ

• 性能は測ってから。平均ではなくパーセンタイル（p99）で見る
• ボトルネックは Utilization / Saturation / Errors を揃えて見る。 待ち時間は CPU に現れない
• 負荷試験では、限界値より壊れ方を見る
• キャッシュは無効化が本体。まず TTL、そして キャッシュが無くても動くかを必ず確認する
• コネクションプールの枯渇は「原因不明の遅さ」の定番。メトリクスに出す
• 過負荷対策は指数バックオフ + ジッター、負荷制限、レート制限、 そして静的安定性（依存先が落ちても現状維持で動く）
• リトライは1層だけ。フォールバックは普段から動かしていないなら入れない
• 水平スケールの前提はステートレス。オートスケールは急な波に間に合わない

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、第5部の最後として、 確率的にしか答えないもの——AI をサービスに組み込む話を扱います。