平均は速いのに、ときどき遅い。サイトの「たまに待たされる」は、なぜ消えない？
平均20ミリ秒と聞くと快適そう。でも、その平均を作った10回の中身は？ サーバーを増やすほど遅い一台の影響が広がる仕掛けを、小さな数字で追います。
この記事の目次
平均20ミリ秒。でも、最後の一回は110ミリ秒
お店の会計で、九人は10秒で済んだのに、一人だけ110秒待ったとします。平均は20秒。「平均20秒でご案内できます」と言われても、最後の人が受け取った体験はずいぶん違うでしょう。サイトの応答時間でも、似たことが起こります。
この記事の図では単位をミリ秒にして、10、10、10、10、10、10、10、10、10、110の十回を使います。平均20という数字は正しい。でも、その数字だけでは、たまに大きく待たされることが伝わりません。分布の遅い側へ伸びた部分を、テールと呼びます。
知りたいのは「平均が何秒か」だけでなく、「遅いとき、どのくらい待つ人がいるか」。この問いを加えると、性能の読み方が一段変わります。
同じ十回を、平均と分布で読む
平均 20ms ／ p95（nearest-rank）110ms。同じデータでも、遅い一回が伝わるかが変わります。
百台に頼むと、遅い一台を引きやすくなる
検索結果の画面を作るために、裏側の百台へ仕事を頼み、全部の返事を待つとしましょう。たいていの一台は速くても、百台のうち一台が遅ければ、画面全体が待つことになります。台数を増やしたのに、最後の一台が気になる。大きなサービスならではの悩みです。
Dean・Barroso氏らの2013年の論文「The Tail at Scale」は、この遅い側の応答が、大規模なサービスの体験へどう広がるかを論じています。処理を細かく分ける利点と、待ち時間のばらつきを受ける難しさが一緒に出てくるんですね。[1]
仮に、一台が遅れる確率を1%、それぞれ独立に遅れると置きます。百台のどれかが遅れる確率は、1から0.99の百乗を引いた約63.4%。これは説明用の計算です。実サービスでは共通の混雑や依存先もあるので、独立という仮定が崩れます。それでも、「一台では珍しい」が「画面では珍しくない」へ変わる理由を追えるでしょう。
たとえば、結果一覧の本体と、補助的なおすすめ欄を別の依頼で作る画面を考えてみます。おすすめが間に合わないときに本体まで待つのか、先に本体を出すのか。これは回線速度だけでなく、利用者に何を先に渡したいかの判断です。全部を待つ設計そのものが、待ち時間の意味を変えます。
同じ理由で、余分に依頼を送り、先に返った結果を使う工夫にも代償があります。待ち時間を減らせても、相手側の仕事量は増えるかもしれない。The Tail at Scaleが扱う対策を読むときにも、速くなった側だけでなく、追加した負荷や必要な条件を一緒に見ると、裏側の設計が立体的になります。
ここから「サーバーを増やさない方がいい」と結ぶと、話が飛びます。分担しなければ処理できない量もある。大事なのは、何台に頼んで、何件そろうまで待ち、間に合わないときは何を返すか、という設計です。途中の件数だけでなく、待ち合わせ方も性能に効いてきます。
回線を速くすれば、全部直るわけではない
遅れの居場所も一つではありません。DCTCPの研究は、データセンターの通信で、混雑の通知を使った制御を扱いました。Sriraman氏らの研究は、通信方式やネットワークの条件を変えて、遅い側の応答を調べています。転送の仕組みが待ち時間へ影響する、という側面です。[2][3]
一方、Hao氏らは大規模なストレージ環境で、遅い側の入出力を分析しています。通信が速くなっても、読み出し先が待っていれば最後の応答は遅いまま。CPU、ストレージ、通信、依存する別サービスを、同じ「サーバーが遅い」にまとめると、直す場所を外してしまいます。[4]
研究ごとに対象は違います。だから、どの方式が常に勝つかをこの記事の数字で決めるより、自分が待っている処理のどこで時間を使ったかを切り分ける。そのために、次はブラウザで一回の待ち時間を見てみましょう。
自分のブラウザで、一つの要求を見てみる
PCで自分が見ているページを開き、ブラウザの開発者ツールからNetworkを選びます。ページを一度だけ再読み込みし、文書の要求を一つ選択。Timingの欄に、接続の準備、最初の応答を待つ時間、受信などの内訳があれば見てください。表示名はブラウザで異なります。
「最初の応答待ちが長い」と「大きな画像の受信が長い」では、次に知りたいことが変わります。前者ならサーバーや途中の経路、後者なら転送量も候補になる。ただしブラウザの内訳だけで、サーバー内部のどの処理が原因かまでは決まりません。ここでは候補を減らせたら前進です。
次に同じページをもう一度開き、キャッシュが使われたかも確認します。条件が違う二回を、そのまま改善の証拠にしないこと。繰り返す場合も自分の通常の閲覧の範囲で行い、他人のサイトへ大量の要求を送る負荷試験へは進めません。
記録するなら「何を開いたか」「キャッシュの有無」「待った区間」「何回中の何回か」を一組に。平均だけで隠れていた一回を、自分の言葉で説明できるようになります。
研究の補足と、よくある疑問
p95とは何？
測った応答時間のうち95%が収まる位置を表す指標です。計算法はいくつかあります。この図は十個の値を小さい順に並べ、ceil(0.95×10)番目を取るnearest-rank方式なので110msです。平均や最大値と区別します。[1]
pingが速ければ、ページも速い？
pingの往復とHTTPの処理は測る範囲が違います。名前解決、接続、サーバーでの処理、画像の受信などを、実際の要求に沿って分けて観察します。[3]
出典と確認した範囲（4資料）
出典と、読み取れる範囲
原著の公開要旨・取得できた本文部分・研究レビューと、仕様を確認する公式資料を照合しています。対象と比較条件が違う結果を一つの効果へ合算せず、手元の操作例は編集上の説明例として区別します。確認範囲は資料ごとに示しています。
対象・方法：大規模な対話サービスで、遅延の変動と対処を整理。
主な結果：多数の処理を束ねると、まれな遅さが全体の待ち時間に影響する。
限界：Google等の大規模サービスの議論。記事の10要求・100分岐の数字は説明用の計算例。
確認した範囲
著者公開PDFの冒頭・関連部分を確認。全文精読・追試・統計の再計算は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：6,000サーバー規模のデータセンターの測定を起点とする通信制御の研究。
主な結果：低遅延と大きな通信量を同居させるためのキュー制御を検討。
限界：データセンター向けの方式。家庭の端末の遅さをDCTCPへ替える提案にはしない。
確認した範囲
Sciteの書誌・抄録の取得部分を照合。原著全文の精読や統計の再計算は未実施。 確認日：2026-10-29
Sciteにnew editionの関連通知（10.1145/1851275.1851192）あり。取得した通知は撤回・懸念通知ではありません。刊行版全履歴の監査は未実施。
対象・方法：TCP/IP・UDP/IP・RDMAの遅延の尾を分解する評価。
主な結果：ネットワーク層も遅延のばらつきへ関与することを検討。
限界：確認したarXiv版。プロトコルだけで全ての遅延が説明できるとはしない。
確認した範囲
原著の公開要旨を確認。本文全体の精読・実験の追試は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：45万超のディスク・4,000 SSDを87日間観察。
主な結果：同じRAID内の他ドライブより遅くなる時間を観測し、ストレージにも尾があると報告。
限界：企業ストレージのデータ。家庭用SSDの故障率や遅延頻度ではない。
確認した範囲
学会主催者の研究紹介・要旨・書誌を確認。本文全体の精読・追試は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
この記事は複数文献を照合した編集記事です。既存研究を照合し、結果と条件を紹介しています。研究が同じ参加者を含む可能性があるため、文献間の人数を足していません。本文の行動提案・未来のシナリオは編集上の整理です。
この記事から、次に気になる話へ。
「再起動したら直った」で終わっていい？原因に近づく、小さな障害テスト
動き出してほっとしたのに、翌日また止まった。そんなとき欲しいのは、次にも使える手掛かりです。大規模な障害研究から、一つだけ条件を変える調べ方を持ち帰ります。
エラーログがないのに、動かない。調べる人は、どこから読む？
ERRORで検索しても、困っている処理が出てこない。別の利用者のエラーを追っていないでしょうか。ログの量を増やす前に、一つの依頼を最後までたどってみます。
このページを開くために、ブラウザは何を取りに行った？
文章は見えるのに、画像だけ出ない。そんな画面の裏では、別々の要求が動いています。いつものブラウザで、その内訳を見てみませんか。