## 概要 SREcon19 Americas での Fred Moyer (Circonus Developer Evangelist) の発表。「レイテンシを平均して SLO を計算する」という一般的な実践の数学的誤りを示し、ログデータ・リクエストカウンタ・ヒストグラムの 3 手法でのレイテンシ SLO 正しい計算法を解説する。ヒストグラムとして [[Circonus]] が開発したログリニアヒストグラム `libcircllhist` を推奨する。(Source: スライド全50ページ) 同タイトル "Latency SLOs Done Right" の発表は SREcon19 EMEA でも [[Heinrich Hartmann]] (Circonus CSO) が行っており、内容は同社の共通知見を異なる登壇者が展開したものと見られる (Source: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]])。 ## 主要メッセージ - パーセンタイルの平均化は「使えばわかる誤り」ではなく「見た目は動くが数字が嘘をつく」という害ある誤り (p.16-21) - 正しいレイテンシ SLO の実装には「分布全体を期間・ノードをまたいで保持する」ことが必要 (p.26-40) - ヒストグラムの 3 大利点: 空間効率・マージ可能性・任意しきい値への後付け対応 (p.43) - 課題: TSDBでの(スパース符号化・HDR)ヒストグラムの完全サポートは IRONdb 以外まだ不十分 (p.49) ## 視覚的に重要な図表 **p.7 レイテンシ精度への問い** ![[_attachments/srecon19americas-moyer-latency-slos/page-007-accuracy-question.png]] "How accurate would your answer be?" ― 10% / 20% / 50% / 200% ERROR の 4 択を示す。誤差が一桁違う可能性を最初に突きつけるフック。 **p.16 パーセンタイル平均化の誤り(数式)** ![[_attachments/srecon19americas-moyer-latency-slos/page-016-common-mistake-formula.png]] `p95(W1 ∪ W2) != (p95(W1) + p95(W2))/2` を宣言。「対称なら問題なし、非対称なら問題を隠す」。 **p.20 具体例: ~200% の誤差** ![[_attachments/srecon19americas-moyer-latency-slos/page-020-200pct-error-example.png]] p95(W1)=220ms, p95(W2)=650ms の 2 ノード合算: 実際の p95 は 230ms だが、2 ノードの p95 を平均すると 430ms ≒ 約 200% の誤差。 **p.35 ヒストグラムの概念図** ![[_attachments/srecon19americas-moyer-latency-slos/page-035-histogram-intro.png]] モード・中央値 q(0.5)・平均・q(0.9)・q(1) の位置関係を示す。"AKA distributions / Sample counts in bins/buckets / Gil Tene's hdrhistogram.org" として紹介。 **p.39 マージ可能性** ![[_attachments/srecon19americas-moyer-latency-slos/page-039-mergeability.png]] `h(A ∪ B) = h(A) ∪ h(B)` ― ビン境界が同一であれば空間(ノード横断)・時間(ウィンドウ横断)の両方向にマージできる。 **p.49 結論** ![[_attachments/srecon19americas-moyer-latency-slos/page-049-conclusions.png]] 1. パーセンタイル平均化は誘惑的だが誤り / 2. カウンタまたはヒストグラムで正しく計算せよ / 3. ヒストグラムが最も柔軟だが実装は libcircllhist・hdrhistogram の数ライブラリのみ / 4. TSDB のスパース/HDR ヒストグラムサポートは IRONdb 以外まだ不十分。 ## ロック不在でした (transcript なし) 音声・動画・transcript は取得していない。 ## 3 手法の詳細 ### 手法 1: ログデータ (p.24–28) - Apache ログに `%{msec}t` でミリ秒を記録: 1 行 ~100 バイト、1000 万リクエスト ≒ 1 GB - 解析パイプライン: HDFS、ElasticSearch/Splunk、`ssh -- grep ... | awk ... > 550 ... | wc -l` - SLI 計算手順: 時間窓のサンプル抽出 → 値でソート → 上位 5% カウントを探す → それが p95 - SLO 判定手順: 1 年を 1,000 スライスに分割 → 各スライスで SLI を計算 → 999 スライス以上で p95 SLI を満たせば 99.9% SLO 達成 - Pros: 計装が容易、精度が高い、OSS 自作も可能 - Cons: 高コスト(ログ分析ソリューションの価格)、サンプリングは精度を歪める、遅い、スケール困難 ### 手法 2: リクエストカウンタ (p.30–33) - 公式: `% success = 100 - (#failed_reqs / #total_reqs) * 100` - Prometheus の累積 `<=` ヒストグラムと同概念 - 具体例: SLO=90% of reqs < 30ms、bad 2,262 / total 60,124 → `100-(2262/60124)*100=96.2%` → SLO 達成 - Pros: 実装が単純、高性能、スケール可能、正確 - Cons: SLO しきい値を先に固定する必要があり後から変更困難、他しきい値への過去遡及が不可能 ### 手法 3: ヒストグラム (p.35–48) - ヒストグラムの種類: 線形・近似・固定ビン・累積・ログリニアの 5 種 - ログリニアヒストグラム: 2 有効桁の 10 進浮動小数点数をビンとして網羅(10^{+/-128}) - ビン例: ... 320, 330, 340 ... / 10, 11, 12, 13 ... / 0.0000010, 0.0000011 ... - 実装: github.com/circonus-labs/libcircllhist (C), github.com/circonus-labs/circonusllhist (Go) - 任意しきい値での SLO 計算: ビンを最小から走査 → しきい値に達するまでのビンのカウントを合計 → 完了 - マージ可能性: ビン境界が同一であれば `h(A ∪ B) = h(A) ∪ h(B)` が成立し、空間・時間の両方向に集約できる - Pros: 空間効率 (HDR: ~300バイト/ヒストグラム、ログ比 10 倍効率的)、任意しきい値、マージ可能 (HDR: ノード横断集約)、高性能 (nsオーダー挿入、μs オーダーパーセンタイル計算)、誤差有界 (ビンサイズの半分)、複数 OSS ライブラリあり - Cons: 他の手法より数学が複雑、最悪ケースで <<5% の精度損失 ## 概念・実体への接続 - [[Fred Moyer]] (登壇者) / [[Circonus]] (所属組織) - [[サービスレベル目標]] / [[ヒストグラムメトリクス]] - 関連発表: [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] (同タイトル、Heinrich Hartmann、SREcon19 EMEA) ## 限界・不確実点 - transcript なし。口頭での補足説明・Q&A の内容は不明。 - p.17-18 のグラフ (time series with spike) は軸ラベルが小さく具体的な数値が読み取れない。 - IRONdb 以外の TSDB での HDR ヒストグラムサポート状況は 2019 年時点の言及であり、現在は改善している可能性がある。