テールレイテンシ — 平均は嘘をつく
要点
- 平均応答時間が良好でも、ごく一部の遅い応答（テールレイテンシ）が利用者体験を損なうことがある。
- 多数のサービスを束ねるほど、どこか一つが遅い確率が積み上がり、全体の遅延として表面化する。
- DeanとBarrosoの「The Tail at Scale」は、この現象と対処法を体系的に論じた。
- 監視すべきは平均ではなく、95パーセンタイルや99パーセンタイルといった裾の値である。
応答時間の平均が100ミリ秒だと聞けば、十分に速いと感じるだろう。だがその数字は、ときに最も重要なことを隠している。平均が良好でも、百回に一回だけ2秒かかるなら、頻繁に使う人ほどその「たまの遅さ」に必ず出くわす。平均は嘘をつくわけではないが、肝心なことを語らない。テールレイテンシ——応答時間の分布の裾——こそ、体験を左右する。
裾が体験を決める
応答時間は一定ではなく、分布する。ほとんどは速く返るが、ガベージコレクションの一時停止、ディスクの混雑、ネットワークの揺らぎといった要因で、ときおり遅い応答が混じる。平均はこの裾を薄めてしまう。だから運用の現場では、平均ではなく95パーセンタイルや99パーセンタイル——「遅いほうから数えて上位5%、1%」の値——を見る。利用者が体感するのは、たいてい平均ではなくこの裾だからだ。
一回のページ表示で何度もサーバーを呼ぶサービスでは、なおさらだ。一度の操作が裏で十回問い合わせをすれば、そのうち最も遅い一回が、体感の待ち時間を決める。速い九回は、遅い一回に隠れてしまう。
規模が裾を増幅する
DeanとBarrosoが2013年にCommunications of the ACMで発表した「The Tail at Scale」は、この問題が規模とともに深刻化する仕組みを明快に示した。論文が挙げる例はわかりやすい。あるリクエストを処理するのに100台のサーバーへ問い合わせ、各サーバーが1%の確率で1秒以上かかるとする。このとき、少なくとも一台が遅い確率は、1から0.99の100乗を引いた値——約63%に達する。
個々のサーバーでは稀な遅さが、束ねた瞬間にほぼ常態になる。各部品が「99%速い」のに、全体は半分以上の確率で遅い。これは直感に反するが、確率の積み上がりとしては当然の帰結だ。規模を増すほど、テールは消えるどころか前面に出てくる。経路を可視化する必要が高まるのは、まさにこの増幅のためだ。
裾とどう付き合うか
同論文は対処法も論じている。たとえば、同じ問い合わせを少し遅れて二重に投げ、先に返ってきたほうを使う「ヘッジドリクエスト」。遅い一台を待ち続ける代わりに、別の経路から答えを得る発想だ。これは余分な負荷と引き換えに、裾を短くする。
もっとも、裾は完全には消せない。物理的な揺らぎや一時的な混雑をゼロにはできないからだ。だから目標は「裾をなくす」ことではなく「裾を許容範囲に抑える」ことになる。完璧を目指すより、99パーセンタイルがいくつ以下なら良しとするかを決め、そこを守る。割り切りの設計である。
平均の向こうを見る
テールレイテンシが教えるのは、システムの健全さを一つの代表値で測ることの危うさだ。平均が改善しても、裾が悪化していれば、体験はむしろ劣化する。逆に、平均が少し悪くても、裾が安定していれば、利用者の不満は減る。見るべき数字を取り違えれば、改善のつもりが体験の悪化を招く。
背景で動くシステムの多くは、平均では「問題なし」に見える。だが利用者の記憶に残るのは、たまに訪れる長い待ち時間のほうだ。平均は全体の傾向を語るが、個々の体験を語らない。分布の裾に目を向けること——それは、数字の見栄えではなく、実際にそこにいる人の体験を測ろうとする姿勢そのものである。
出典
- Dean and Barroso「The Tail at Scale」（Communications of the ACM, 2013年）
- 同論文におけるパーセンタイル評価とヘッジドリクエストの議論