応答時間の平均は985ミリ秒でした。ところが1000件に1件は11359ミリ秒かかっています。
さらに、1分ごとの平均を先に取ると最大が41705ミリ秒から1784ミリ秒に化けます。遅い件が消えます。
裾の重い応答時間を10万件作って測りました。平均と分位点では見えるものが違います。
レイテンシ監視で何を見るべきかを、実際に走らせて測りました。中央値800ミリ秒で裾の重い分布を10万件作っています。
100件に1件は、外部の詰まりで4倍から10倍に遅れるようにしました。実際の業務処理でよくある形です。
const pct = (sorted, p) => sorted[Math.min(sorted.length - 1, Math.floor((sorted.length * p) / 100))]; const sorted = [...lat].sort((a, b) => a - b); const mean = lat.reduce((a, b) => a + b, 0) / N;
見方 値 平均 985ミリ秒 p50 805ミリ秒 p90 1664ミリ秒 p95 2085ミリ秒 p99 3698ミリ秒 p99.9 11359ミリ秒 最大 41705ミリ秒 平均より遅い件数: 35,846件（35.8%）
上の表を見てください。平均は985ミリ秒ですが、1000件に1件は11359ミリ秒かかっています。11倍です。
中央値は805ミリ秒で、平均の985ミリ秒より低くなっています。少数の桁違いに遅い件が平均を引き上げているためです。
結果として平均より遅い件が35.8%もあります。平均を基準に「半分はこれより速い」と読むと外れます。
この形は昔から指摘されています。Googleの資料も平均100ミリ秒の水準で毎秒1000件を捌くとき、1%の要求が5秒かかることは容易に起こりうると述べています。
1%といえば、毎秒1000件なら1秒あたり10件です。少数ではありません。
平均の裏に、桁の違う遅さがある。
If you run a web service with an average latency of 100 ms at 1,000 requests per second, 1% of requests might easily take 5 seconds.原文Google SRE Book「Monitoring Distributed Systems」 この内容の有効期限2027-02-18
応答時間を測って見張ります。監視で最初に見る4つの指標のうちの1つとして位置づけられています。
レイテンシ監視は、応答時間を測って見張る取り組みです。利用者が待っている時間そのものを扱います。
Googleの資料は、監視の4つの黄金信号は、応答時間・流量・失敗・飽和である。利用者向けの仕組みで4つしか測れないなら、この4つに絞れとしています。
応答時間はその1つ目です。失敗していなくても、遅ければ使えません。
分位点を出すには、元の分布が要ります。Googleの資料も遅い平均と、極端に遅い裾を見分ける最も簡単な方法は、応答時間の区間ごとに要求数を数えることだとしています。
4番目は見落としがちです。失敗した要求は速く返ります。混ぜて集計すると、障害中に応答時間が改善したように見えます。
応答時間は、詰まりの前ぶれとしても使えます。同じ資料は応答時間の増加はしばしば飽和の先行指標であり、短い窓での99パーセンタイルの測定が飽和のごく早い合図になるとしています。
つまりp99は、いま困っている人の数であると同時に、これから起きることの合図でもあります。
応答時間は種を固定した乱数で作っています。実際のシステムを測ったものではありません。ここで見せているのは、裾の重い分布で平均と分位点がどれだけ離れるかという関係です。自分の環境では、まず区間ごとの件数を記録するところから始めてください。
The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.原文Google SRE Book「Monitoring Distributed Systems」 この内容の有効期限2027-02-18
1分ごとの平均を記録してから分位点を出すと、遅い件がならされます。順番を間違えると数字が化けます。
レイテンシ監視でよくある事故が、先に平均してから分位点を出すことです。実際に走らせて確かめました。
集計の仕方 p95 p99 最大 1件ずつ見る 2085ミリ秒 3698ミリ秒 41705ミリ秒 60件ずつ平均してから 1188ミリ秒 1363ミリ秒 1784ミリ秒 600件ずつ平均してから 1044ミリ秒 1110ミリ秒 1115ミリ秒
上の表を見てください。最大が41705ミリ秒から1784ミリ秒になりました。23分の1です。
60件の平均を取ると、1件の遅さが60件で割られます。40秒かかった1件も、他の59件と混ぜれば1秒足らずの上乗せにしかなりません。
600件ずつにすると、さらに平らになります。p95・p99・最大の差がほとんどなくなりました。
分位点は元の1件ずつの値から出す必要があります。集計するなら、平均ではなく区間ごとの件数を持ちます。
Googleの資料が挙げている方法もこれです。応答時間の区間ごとに要求数を集める形なら、あとから分位点を出せます。
先に平均していると、一部の利用者だけが遅い状態に気づけません。全体の平均は動かないためです。
苦情が来てから調べても、記録にはその遅さが残っていません。記録の取り方が、調べられる範囲を決めます。応答時間の目標そのものの決め方はSLO/SLIの記事で扱います。
平均してから分位点を出すと、桁が変わる。
The simplest way to differentiate between a slow average and a very slow "tail" of requests is to collect request counts bucketed by latencies原文Google SRE Book「Monitoring Distributed Systems」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る