# Principled Performance Analytics Narayan Desai・Brent Bryan（Google Cloud SRE）が SREcon22 Americas（2022-03-16）で発表。SLO の根本的限界を論じ、ワークロードのコホート分割と正規分布 z スコアを使った較正不要の性能分析手法「2σ手法（2σ Technique）」を提示する。[[@2021__SREcon21__Beyond-Goldilocks-Reliability|2021 年の "Beyond Goldilocks Reliability"]] で提唱した[[定常性モデル]]の具体的な実装形として位置づけられる。 ## 概要 「サービスは機能しているか？」という問いに答えるためには、可用性・パフォーマンス・正確性の 3 次元が必要だ。しかし SLO ベースの可用性監視はエラーを単純な「良/悪」に圧縮するため、エラー認識の曖昧さ・バグ・較正誤差という構造的問題を抱える。SLO は「エラーが何かを人間が決め続ける」ゲシュタルト的プロセスに依存しており、本質的に実現不可能だと著者らは主張する。代替として、ワークロードの Intent を近似するコホート分割と正規分布 z スコアによる定常性検定——「2σ手法」——を示す。 ## 主要メッセージ - SLO は「エラーの認識」を前提とするが、エラー認識自体が曖昧で維持コストが高く、過少/過剰計上が構造的に起きる（p.9）。 - 顧客が気にするのは「一貫性（consistency）」であり、特定の絶対しきい値ではない。同じワークロードに対してサービスが毎回同じように動くことを期待する（p.14）。 - 信頼性は顧客とサービス提供者の**共有特性**であり、エンドツーエンドの再構成が不可欠（p.37）。 - 分散システムはワークロード間の脱相関（decorrelation）を引き起こすが、これを**測定**できる（p.37）。 - 2σ手法の出力は較正不要かつコホート間で結合可能な「データ積木」であり、多様な分析クエリへの再利用が可能（p.38）。 ## 視覚的に重要な図表 **p.4 信頼性の 3 次元** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-004.png]] 可用性（堅牢な建物）・パフォーマンス（走るチーター）・正確性（ダーツ的中）の 3 軸で信頼性を定義する。 **p.7 実践における信頼性 — 何が機能しないか** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-007.png]] 可用性（✓ 失敗リクエスト数、✗ 4xx vs 5xx / デッドライン / 不正リクエスト / リトライによる誤誘導）、パフォーマンス（✓ P99 レイテンシ SLO・プローバー、✗ ワークロード依存 / プローバーの狭さ）、正確性（✓ 統合テスト・ゴールデンデータセット、✗ 非適応的カバレッジ）の限界を列挙する。 **p.9 エラーは浅いデータ** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-009.png]] トルストイの「アンナ・カレーニナ」の引用で「幸せな家族はどれも似ているが、不幸な家族はそれぞれ独自の不幸を抱える」と SLO の問題を比喩。エラー / 全体 という分数で表現される SLO は、エラー認識が曖昧・バグ由来・較正誤差・定期メンテなしという 4 つの問題から「浅いデータ」にとどまることを示す。 **p.22 近似がレバレッジを生む — z スコア式** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-022.png]] 正規分布近似とベースライン資格除外の 2 仮定から、z スコアが尤度の代理指標となり、z スコアが標準正規分布に従うこと・コホート間で結合可能であること・ベースライン計算が embarrassingly parallelizable であることが導かれる。z = (観測値 − ベースライン平均) / ベースライン標準偏差。 **p.27 2σ手法の完全パイプライン** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-027.png]] 「Model」フェーズ（履歴データ → コホート分割 → ベースライン計算 → コホートメトリクス DB）と「Measure」フェーズ（現在データ → z スコア計算 → z スコア監視）の全体像。各色（黄・赤・緑・青）は別コホートを示す。 **p.29 バックテスト — SLO vs 2σ 検知の比較** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-029.png]] 上段：可用性ベースの SLO グラフ（14:00-15:00、90% SLO ターゲットに対し 14:15 頃から深刻な可用性低下）。下段：レイテンシ >2σ の割合（1:15-3:00 PM）——14:00 以前の 2:15 PM 頃にセル "jv" で最大 75-80% 超の急上昇が先行して現れており、SLO より早く問題を捉えている。 **p.31 障害の感度の高い検知 — 18 時間** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-031.png]] 「Percent Slow Queries Total Time」（Apr 25–27, 2021）。2σ 検知（左の赤棒 = Apr 26 午前 6 時頃）から従来モニタリングによる第 2 アラート（右の赤棒 = Apr 27 深夜）まで **18 時間**の先行優位を示す。 **p.32 根本原因の絞り込み — 階層的診断** ![[_attachments/sre22amer-desai-principled-performance-analytics/page-032.png]] 左ツリー：Total Time → Queue Time + Execution Time → I/O Time へと分解。右グラフ：「Percent of Slow Queries By Reason」（Mar 7–14, 2021）で Total Time（青）と I/O Time（赤）がほぼ同時に 75-100% 水準へ急上昇しており、I/O が原因であると即座に特定できる。 ## 2σ手法の詳細 ### 仮説と手順 **仮説**: 「自己相似ワークロードは一貫したパフォーマンスを持つはずである（Self-Similar Workloads Should Have Consistent Performance）」(p.21) 手順: 1. **コホート分割**: ワークロード特徴量で Intent を近似し、類似クエリをコホートに束ねる。 2. **ベースライン構築**: 各コホートの過去パフォーマンスを正規分布で近似。 3. **z スコア計算**: 現在観測値の z スコアを各コホートのベースラインで計算。 4. **集約監視**: 窓内で z ≥ 2 となるワークロードの割合を監視。通常は 2-5%。**10% 超 → 警戒**。 ### FAQ（p.28）への口頭回答（transcript l.459-490 より） 1. **パフォーマンスメトリクスは実際に正規分布に従うか？** → 従わない。「ログ正規分布の方が有意に良く機能する」。ただしログ正規でも任意のパラメトリック分布でも経験的分布でも同じプロセスが成立する。 2. **近似の妥当性確認は？** → **KS テスト（Kolmogorov-Smirnov stat test）**で分布の適合度を確認。バイモーダルや極めて広い分散を持つコホートは除外（baseline qualification）。 3. **コホート定義は？** → 複雑なクラスタリングアルゴリズムから始めたが、**3〜5 特徴量のクロス積**で十分に機能することが判明。試行錯誤はあるが、「似た Intent のワークロードをまとめる」という基本方針で実用上は問題ない。 4. **シングルトン（出現頻度の低いワークロード）は？** → **対象外設計**。シングルトンは「過去に見たことがない → 通常どのくらいかかるか不明」なため検知対象外。過去に見た繰り返しワークロードに集中する。カバレッジ 3-4% でも有意なシグナルが得られる実装例がある。シングルトンが多すぎる場合はコホートの特徴量選択が不適切なサイン。 ## 概念・実体への接続 - 2021 年発表との連続性: [[定常性モデル]] — 本トークはその具体的実装として [[2σ手法]] を提示する。 - SLO の根本的限界: [[サービスレベル目標]] - 登壇者: [[Narayan Desai]] / [[Brent Bryan]] - 所属: [[Google]] ## 口頭説明・補足（transcript より） - **2σ を選んだ理由**: 物理実験（3σ/5σ）より感度優先。「システムが間違いなく壊れたとき」より「悪化し始めたとき」に検知したいため（transcript l.521-534）。 - **偽陽性率**: 9 ヶ月の本番稼働で偽陽性 1 件のみ。それ以外はすべて、掘り下げると実際の問題が存在した（l.498-501）。 - **ウォールーム事例**: 顧客苦情より 1.5 日前に 2σ アラートのみに基づいて 10 人のウォールームを招集・問題解決（l.721-725）。 - **感度向上の比喩**: 「感度を上げると太平洋岸北西部で岩をひっくり返すようなもの——クモが次々と出てくる（つまり今まで見えなかった性能イベントが続々見えてくる）」（l.624）。 - **分散システムの目的**: 「コンポーネント間の脱相関（decorrelation）を生み出すこと」——相関が生じたときが問題のサイン（l.636-660）。 - **Excursion（逸脱）という用語**: "incident" に「顧客が気づいたときのみ」「対応があるときのみ」等の社会的制約が付くため、パフォーマンスが期待から外れた区間を "excursion" と呼ぶ（l.609-614）。曲線下面積で重大度を定量化し、逸脱をランク付けできる。 - **結論の言葉**: "SLOs can't work. We aren't going to be able to solve our reliability problems by analyzing our systems using SLOs." / "Performance data is so much better than availability data, and it'll tell you 95% of the same things."（l.709-736） ## 限界・不確実点 - p.34（予期しない相関の計測）グラフの縦軸単位・相関閾値 0.08 の決め方は transcript でも未言及。 - p.35（コホート A/B テスト）の X 軸ラベルが読み取れず詳細不明。