# 2σ手法 ## 定義 2σ手法（2σ Technique）とは、ワークロードを Intent ごとにコホートに分割し、各コホートのパフォーマンスを正規分布で近似してベースラインを構築し、現在の観測値の z スコアが 2σ を超えるワークロードの**割合**を監視することで、較正不要・コホート間結合可能な形で性能劣化を検知する手法である (Source: [[@2022__SREcon22Americas__Principled Performance Analytics]])。 Narayan Desai・Brent Bryan（Google Cloud SRE）が SREcon22 Americas（2022-03-16）で発表。2021 年の[[定常性モデル]]の具体的実装として位置づけられ、GCP Data Analytics プロダクト（BigQuery など）の本番監視への適用事例が示された。 ## 基本仮説 > **自己相似ワークロードは一貫したパフォーマンスを持つはずである（Self-Similar Workloads Should Have Consistent Performance）** 同じ「意図（Intent）」を持つクエリ群（同じ SQL パターン・同じデータセット規模など）は、安定したシステムでは繰り返し類似したパフォーマンスを示す。この IID（独立同分布）仮説からの逸脱を検知することが 2σ手法の目的である。 ## パイプライン ``` Model フェーズ: 履歴データ → コホート分割 → ベースライン計算 → コホートメトリクス DB Measure フェーズ: 現在データ → z スコア計算 ← コホートメトリクス DB ↓ z スコア監視（割合 > 10% → 警戒） ``` ### Step 1: コホート分割 ワークロードの特徴量（クエリパターン、テーブル数、フィルタ条件、データ量など）で Intent を近似し、類似ワークロードをコホートに束ねる。コホート分割自体はシステム設計の知識が必要であり、自動化と人間判断の組み合わせとなる。 ### Step 2: ベースライン構築 各コホートの過去パフォーマンス分布をパラメトリック分布で近似する。スライドでは正規分布を例示しているが、実装では**ログ正規分布の方が有意に良く機能する**（transcript）。任意のパラメトリック分布・経験的分布も同じプロセスで使用可能。 適合度は **KS テスト（Kolmogorov-Smirnov 検定）** で確認し、不適合コホート（バイモーダル・広分散のもの）は除外する（baseline qualification）。ベースライン計算は embarrassingly parallelizable であり、コホート数に対してスケールしやすい。 ### Step 3: z スコアの計算と集約監視 $z = \frac{\text{obs. workload} - \text{baseline mean}}{\text{baseline std}}$ 各ワークロードの z スコアを計算し、窓内で z ≥ 2 となるワークロードの**割合**を時系列で監視する。 - 正常時: 2-5% のワークロードが z ≥ 2σ（正規分布の性質から自然に生じる裾） - **10% 超: 警戒**（システムが期待挙動から逸脱している可能性が高い） **重要**: 検知は「個々のワークロードが遅いか」ではなく「遅いワークロードの**割合**が増えたか」に基づく。これによりワークロード数の変動や外れ値に頑健になる。 ## z スコアが calibration-free かつ combinable である理由 正規分布近似の下で: - z スコアは**尤度の代理指標**となる（z が大きいほど「通常あり得ない」） - 標準化された z スコアは**コホート間で比較・結合可能**（単位が揃う） - ベースラインの平均・標準偏差だけがパラメータであり、人間が設定する**較正閾値が不要** ## 主要なアプリケーション ### 1. 感度の高い障害検知 従来の可用性 SLO より **18 時間先行** して障害を検知した事例あり（Apr 25-27, 2021）。可用性が落ちる前にパフォーマンス劣化が始まるため、性能分布の変化を先に捉えられる。 ### 2. 階層的診断（根本原因の絞り込み） z スコアを「Total Time」「Queue Time」「Execution Time」「I/O Time」などの指標に対して並行して計算し、どの階層で劣化が起きているかを即座に特定できる。例: 全体スロークエリ割合の急上昇 → I/O Time のスロークエリ割合が同時に急上昇 → I/O 系の障害と判定。 ### 3. 逸脱影響評価（Excursion Impact Assessment） 「どのコホートが・いつから・どの程度劣化していたか」を、z スコア超過ワークロードの割合の積分として定量化できる。SLO のエラーバジェット消費という形ではなく、影響したワークロード数×劣化期間として表現。 ### 4. 予期しない相関の計測 本来独立であるべきサブシステム間でワークロードパフォーマンスが相関し始めたとき（隔離障害）、相関係数の時系列として検知できる。Aug 6-10, 2021 の実データで閾値 0.08 を超えるスパイクと実際の障害が対応していた。 ### 5. 近似コホート A/B テスト コホート間の z スコア分布を比較することで、インフラ変更・設定変更・ソフトウェアバージョンが特定コホートのパフォーマンスに与えた影響を統計的に評価できる。 ## SLO との比較 | 観点 | SLO（可用性ベース）| 2σ手法 | |---|---|---| | エラー定義 | 必要（曖昧で維持コスト高） | 不要（z スコアで代替） | | 較正 | 人間が閾値を設定・維持 | 履歴データから自動生成 | | 信号の粒度 | バイナリ（良/悪） | 連続（z スコア分布） | | コホート対応 | 困難（ワークロード混合） | コホート単位で計算 | | 結合可能性 | スタック困難 | z スコアは跨コホートで結合可能 | | 顧客視点 | 間接的（エラー率） | 直接的（一貫性の欠如） | 著者の主張: 「エラー認識は人間判断のゲシュタルトであり、SLO はその未認識問題から実現不可能（not feasible）」。これは SLO を全否定するものではなく、**2σ手法によるデータ積木が SLO の基盤を強化・補完する**という立場である。 ## 横断的知見 - **2σ手法は 2021 年の定常性モデル（IID 仮説）の数理実装である**: Desai は 2021 年に「ワークロードパフォーマンスが IID であるという仮定と、その仮定からの逸脱を検知する」という定常性モデルの概念を提示した。本 2022 年発表はその仮定を正規分布 z スコアで具体化した実装編として読める。概念提唱（Beyond Goldilocks）→ 具体的実装（Principled Performance Analytics）という 2 年連続の連作。(Source: [[@2022__SREcon22Americas__Principled Performance Analytics]], [[@2021__SREcon21__Beyond-Goldilocks-Reliability]]) ## 未解決の問い - **【transcript で回答済み】正規分布に従わない場合**: ログ正規分布の方が実際には有意に良く機能する。任意のパラメトリック分布・経験的分布も使用可能。KS テストで適合度を検証し、不適合コホートは除外（baseline qualification）（transcript l.460-469）。 - **【transcript で回答済み】コホート定義**: 3〜5 特徴量のクロス積で十分。複雑なクラスタリングから始めたが不要と判明。シングルトンが多すぎる場合は特徴量選択が不適切なサイン（l.470-490）。 - **【transcript で回答済み】シングルトン処理**: 対象外設計。繰り返しワークロードに特化。カバレッジ 3-4% でも有意なシグナル取得可能（l.476-490）。 - 10% という警戒閾値の根拠・調整方法は transcript でも未説明。サービス種別・ワークロード多様性によって変わるか不明。 - 予期しない相関（p.34）の相関閾値 0.08 の決め方は未説明。 - BigQuery 以外のサービス（ステートレス Web サービス、ストリーム処理など）への適用可否・事例。 - 「18 時間先行検知」は当該インシデント固有か一般化可能か。transcript では「数百の事例がある」と述べているが（l.560）、すべてで同程度の先行が見られるかは不明。 ## 関連 - ソース: [[@2022__SREcon22Americas__Principled Performance Analytics]] - 前提概念: [[定常性モデル]] / [[サービスレベル目標]] - 関連概念: [[異常検知]] / [[HPCワークロード特性化]] - 登壇者: [[Narayan Desai]] / [[Brent Bryan]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2022__SREcon22Americas__Principled Performance Analytics]]（2σ手法の全体設計・数理的根拠・5 つのアプリケーション・SLO との比較）