アーキテクチャ: ファンアウトはテールレイテンシを中央値にする
1% の確率で遅いバックエンドでも、100 本にファンアウトすると約 63% のリクエストが「遅い1本」に当たる。hedge・ファンアウト上限・呼び出しごとの期限で抑える。
使う場面
検索・集約・マイクロサービス呼び出しで、1リクエストが多数の下流を待つ構成。平均は速くても p99 だけ悪化する典型パターン。
やり方
概算: 各呼び出しが独立に確率 \(p\) で「遅い」なら、\(n\) 本のうち少なくとも1本が遅い確率は \(1-(1-p)^n\)。\(p=0.01,\ n=100\) なら約 0.63。
対策の組み合わせ:
- 呼び出しごとの期限 — 全体の予算を下流に均等配分せず、1本が予算を食い尽くさないようにする（関連: リトライは「1 リクエストごとの回数」だけでなく全体の予算で制限する（full jitter と組み合わせる） があればそちらも）。
- ファンアウト上限 — 一度に待つ本数を減らす（バッチや階層化）。
- Hedge request — p95 を過ぎても返ってこない呼び出しに対し、別レプリカへ二重発信し、先に返った方を使う（余分な負荷とのトレードオフ）。
注意点
- Hedge は負荷を増やす。常時二重発信ではなく「遅いときだけ」にする。
- 依存が同じ障害ドメインだと hedge しても同じように遅い。
- クライアント側のタイムアウトとサーバー側の処理キャンセルが連携していないと、打ち切ったあとも下流が動き続ける。