平均は何の意味もない

• 新しいキャッシュ層のデプロイ後、平均レイテンシは112msから122msへ悪化した一方、中央値は99msから54msへ改善し、p99は309msから678msへ悪化しており、単一の統計値だけでは成否を判断しにくい
• デプロイ後、レイテンシ分布は1つの山から2つの山へ分かれ、累積分布関数（CDF） を重ねて見ると、およそ140msを境に速いリクエストは改善し、遅いリクエストは悪化している
• パーセンタイルごとの変化量を示す シフト関数 と、日別のリッジラインプロット・ヒートマップは、改善とリグレッションの大きさ、およびデプロイ率が0%から100%へ高まる間に遅いリクエスト群が大きくなっていく過程を示している
• データをキャッシュ結果とレスポンスサイズで分けると、小さなレスポンスの キャッシュヒット は速くなり、大きなレスポンスのキャッシュミスは追加ホップのため遅くなって、二峰性の分布が生まれた原因を確認できた
• 平均や特定のパーセンタイル1つだけを選ぶと、互いに正反対の判断すら正当化できてしまうため、分布全体とサブグループ をあわせて見ることで、キャッシュ最大オブジェクトサイズの拡大や大きなレスポンスの分割といった対策につなげられる

---

本番環境では見えなかった性能改善

• lld に関する性能改善はベンチマークでは現れたが、実際の本番ダッシュボードではデータノイズのため明確な変化を見つけにくかった
• ビルド速度は コールドキャッシュ、増分ビルド、ローカル・リモート実行、システム状態、ワークロードなど多くの変数によって大きく変わりうる
• 累積分布関数（CDF）でビルド性能を評価した事例をきっかけに、1枚の図や1つの統計値ではなく、複数の方法でデータそのものを見る必要が出てきた
• すべての例は固定シードを使った1つの 合成データセット から生成されており、完全なスクリプト には nix-shell shebang が含まれ、Nix 環境で各図をそのまま再現できる
• ストーリー用のデータとチャート生成には AI が活用された

平均では失敗に見えたキャッシュデプロイ

• Webサービスのリクエストレイテンシを減らすために新しいキャッシュ層を1週間デプロイしたが、平均レイテンシは 112msから122ms へ9%増加した
• 平均だけを見れば、変更をロールバックして障害対応と事後分析を始めるべきリグレッションだと判断しやすい

1つのデータが生んだ4つの判断

• デプロイ前後の統計は異なる方向を指している
  • 平均: 112ms → 122ms、9%悪化
  • p50 中央値: 99ms → 54ms、46%改善
  • p95: 224ms → 454ms、103%悪化
  • p99: 309ms → 678ms、119%悪化
• 平均は軽微なリグレッションを示すが、中央値では一般的なリクエストがほぼ2倍速くなり、p99では最悪のリクエストが2倍以上遅くなった深刻な問題が見える
• 同じデータから計算した 平均と中央値 が逆方向を指すため、自分の判断を裏づける統計だけを選びやすい

分布の形が明かした2つのリクエスト群

• 密度グラフでは、デプロイ前の分布は 1つの山 だったが、デプロイ後は2つの山に分かれた
• この形は統計値どうしの矛盾を説明するが、密度グラフにも制約がある
  • 形は選んだ 平滑化パラメータ によって変わる
  • 2つの分布の塗りつぶし領域が重なると読みにくい
  • 2つの集団の存在は見えるが、中央値のようなパーセンタイル位置をすぐ把握しにくい

CDFで全パーセンタイルを比較する

• 累積分布関数（CDF）は各レイテンシ x に対して、xミリ秒以下で完了したリクエストの割合 を示す
• デプロイ前後のCDFを1つのチャートに重ねると、全リクエスト群で各パーセンタイルがどう動いたかを確認できる
• デプロイ後の曲線は140ms未満の区間で左へ移動し、以前より多くのリクエストが速くなった一方、140ms以降ではより多くのリクエストが遅くなっている
• 2つの曲線が交差するおよそ 140ms が、変更の効果が改善から悪化へ切り替わる境界である
• 2つのCDFが交差するなら、効果の方向は選んだパーセンタイルによって変わるため、どの単一パーセンタイルでも変化全体を要約できない

パーセンタイルごとの変化量を測る

• CDFは各区間が速くなったか遅くなったかを示すが、変化量そのものは直接示さない
• シフト関数（shift function） は各パーセンタイル p で、デプロイ後レイテンシとデプロイ前レイテンシの差を計算する
  • 0未満は改善した区間
  • 0より上は遅くなった区間
• これにより、分布の各地点で変化の方向だけでなく 大きさ まで確認できる

デプロイの進行とともに大きくなったリグレッション

• 新しいキャッシュ層は1週間かけてトラフィックの0%から100%まで段階的に拡大され、デプロイ前後の2時点だけを比較すると途中の変化を見落としてしまう
• 日別分布を積み上げた リッジラインプロット（ridgeline） では、デプロイが進むにつれて速いリクエストの主峰が左へ移動し、遅いリクエストの第2の峰が右側に現れる
• 中央値が下がる一方で、遅いリクエストの数とレイテンシは静かに増加する
• レイテンシはおおむね対数正規分布になるため、x軸には 対数スケール を使う
  • 線形軸では速いリクエストの峰が高く立ち上がり、遅いリクエストは薄く広がってしまい、2つの峰を同時に読み取りにくい
• 日別の列とレイテンシごとのトラフィック量を色で表した ヒートマップ でも、新しいリクエスト群がうっすら現れる
• 1週間全体を1つの集計値にまとめると、異なる7日分の日次分布と変化の傾向が失われる

キャッシュヒットとミスに分解した二峰性分布

• 実際の lld 分析では、バイナリサイズ、たとえば 50MiB超かどうか でデータを分けてはじめて、レイテンシの二峰性分布を確認できた
• 合成事例の新しい層では、リクエストはキャッシュで処理される ヒット（hit） と、バックエンドへ渡されて追加ホップを通るミス（miss）に分かれる
• デプロイ後リクエストのCDFをキャッシュ結果ごとに分けると、各集団は再び1つの峰を持つ
  • キャッシュヒットは従来のベースラインより左へ移動し、より速くなる
  • キャッシュミスは追加ホップのコストのため、はるか右側に位置する

レスポンスサイズから見つかった原因と対策

• キャッシュミスは動作メカニズムにすぎず、どのリクエストがなぜミスを起こすのか把握するには レスポンスサイズ もあわせて見る必要がある
• キャッシュは小さくて頻繁に使われるオブジェクトを保持するが、大きなオブジェクトは追い出されるか、最初から入らない
• レイテンシとレスポンスサイズの関係を、キャッシュヒット・ミスの色分けと各軸の密度分布を組み合わせた 結合グラフ（jointplot） で見ると、2つの集団がはっきり現れる
  • 小さなレスポンス・低レイテンシの集団はキャッシュヒット
  • 大きなレスポンス・高レイテンシの集団はキャッシュミス
• レイテンシの二峰性分布はレスポンスサイズ分布の二峰性に由来しており、キャッシュの最大オブジェクトサイズを増やすか、大きなレスポンスを分割する ことで対処できる

1つのグラフを超えて分布全体を見る

• 単一のパネルやグラフだけでは全体像を捉えるのに不十分で、場合によっては誤った判断を招きうる
• 同じデータを複数の方法で見ることで、分布の形、パーセンタイルごとの効果、時間による変化、サブグループと原因をあわせて理解できる
• とくに CDF は、複数のリクエスト群を比較しながら分布全体を1つのチャートに収めるのに有用である