# 定常性モデル ## 定義 定常性モデル（Stationarity-based Reliability Model）とは、信頼性の 3 次元（可用性・パフォーマンス・正確性）それぞれに**定常性仮定**を付与し、その仮定からの逸脱を信頼性劣化のシグナルとして検知する数理的枠組みである (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]])。 Narayan Desai（Google Cloud SRE）が SREcon21 で提唱した。従来の「Goldilocks Reliability」（SLI に固定閾値を設定する 2 バケットアプローチ）に対するアンチテーゼとして位置づけられる。 ### 3 次元への定常性仮定の付与 | 次元 | 定義 | 定常性仮定 | |---|---|---| | 可用性 | サービスが必要なときに存在する | エラーは時空間的に独立同分布（i.i.d.） | | パフォーマンス | 仕事が効果的に処理される | 長時間窓にわたってパフォーマンスが一定 | | 正確性 | 期待どおりの結果を産出する | バグを除いて同一入力から同一出力 | 定常性の違反（＝仮定からの逸脱）を時系列として観測することで、閾値監視では不可視だった信頼性現象が浮かび上がる。 ### Goldilocks Reliability との対比 **Goldilocks Reliability** は以下の 4 つの荷重仮定を暗黙的に前提とする (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]]): 1. **「ちょうどいい」が有意**: メトリクスが許容域という概念を有意に使えるほど分布しており、答えが定式化できる 2. **答えが 1 つ**: 顧客・ワークロード差異が存在しない 3. **問いが既知**: 個別 Goldilocks メトリクスは狭い窓しか持たず、「知らないことを知らない」 4. **答えが変化しない**: 閾値は性能変化・依存関係変化に高感度で誤誘導を引き起こす 定常性モデルはこれらの仮定への依存を回避し、**「どの仮定が崩れたか」自体を信号とする**。 ## 定常性が露出する信頼性現象 定常性仮定からの逸脱を検知することで、従来の閾値監視では不可視だった以下の現象が観測可能になる (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]]): - 準臨界パフォーマンスシフト（critical な閾値には達しない劣化） - ゆっくり進行するインシデント（slow-building reliability incidents） - パフォーマンス退行 - サブシステム障害 - プロビジョニング問題 - 隔離障害（Isolation failures） - 顧客の痛みの直接検知 ## 階層的診断への応用 定常性違反を階層的に分解することで根本原因を識別できる。Desai が示した例: 「スロークエリ割合」全体の定常性違反（e2e レイテンシ上昇）→ 「理由別スロークエリ割合」で IO Time が原因と特定 (Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]])。 この階層的診断により以下の能力が生まれる: - De Novo インパクトアセスメント（発生前の影響予測） - 先回り型信頼性介入（Proactive reliability interventions） - 環境不安定性の定量計測 - データ駆動的な信頼性投資の優先化 ## 定常性の技術的定義と計測手法 口頭説明（transcript l.235–284）で補足された実装詳細: - **定常性の定義**: 「分布が時間にわたって固定されたままである性質」——ユーザーが直感的に期待する「昨日と今日と明日が同じ」という要求に対応する。 - **計測手法**: 「特定イベントの相対尤度を評価し、その時間窓平均を観測する」。ワークロードをリクエストの集合として捉え、各パフォーマンス計測値をその尤度でスコアリングし、窓平均の逸脱を検知する。 - **キャリブレーション不要（calibration-free）**: 閾値設定のための人間判断が不要。履歴データのみで動作し、「通常あり得ないイベントが集中する」ことが経験的に問題の確実な指標となる。 ## 横断的知見 - **2σ手法は定常性モデルのパフォーマンス次元を正規分布 z スコアで具体化した実装形である**: 2021 年の Beyond Goldilocks Reliability で「パフォーマンスの定常性仮定 = 長時間窓にわたってパフォーマンスが一定」と提唱し、2022 年の Principled Performance Analytics で「コホート単位で正規分布ベースラインを構築し z ≥ 2 のワークロード割合で IID 仮説を検定する」という具体的な計算手順が与えられた。概念提唱（2021）→ 数理実装（2022）という 2 年連続の連作。(Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]], [[@2022__SREcon22Americas__Principled Performance Analytics]]) - **定常性モデルは SLO/SLI とは直交する概念である**: Goldilocks Reliability は SLI の閾値設定問題として SLO フレームワークに含まれうるが、定常性モデルは信頼性の「あるべき状態」を仮定として陽に記述し、その違反を信号にする点でアプローチが根本的に異なる。SLO は「どこを超えたらアウトか」を定義し、定常性モデルは「通常どうあるべきか」を定義する（2 ソース以上での比較検証が必要）。(Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]]) - **閾値監視が 2 バケットヒストグラムへの情報圧縮であるという批判は Hartmann（2019）のパーセンタイル集約不能問題と同じ問題意識から発している**: Desai は「閾値を通すと 2 つの 64 ビット整数しか残らず、元の豊かなデータから大幅に情報量が失われる。閾値が間違っていれば完全な情報損失」と論じた。Hartmann の「p95 の時間平均は全体の p95 と一致しない」批判と合わせると、閾値・パーセンタイル双方に「点推定によるデータ圧縮」という根本的限界があることが見えてくる。定常性モデルは分布全体の尤度を使うことでこれを回避する。(Source: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]], [[@2019__SREcon19 EMEA__Latency SLOs Done Right]]) - **PerfScout は「固定閾値からの逸脱を定常性で置き換える」設計思想を性能テストのワークロード制御へ適用した工学実装である**: [[PerfScout]] 論文([[@2026__ICSE-SEIP__PerfScout - An Adaptive Workload Generator in Software Performance Testing]], ICSE-SEIP '26)は、TPS(スループット)の直近ウィンドウに ADF テスト・KPSS テストを同時実施し、両者がともに非定常を示す間は同一負荷でのテストを継続、定常と判定された時点で初めて次の同時実行数フェーズへワークロードを進める。Desai の「パフォーマンスの定常性仮定 = 長時間窓にわたってパフォーマンスが一定」という定義そのものを、負荷テストの「次のワークロードレベルへ進めてよいか」という意思決定条件として直接運用に落とし込んだ点が特徴である。SLI 監視文脈(Google Cloud SRE)から性能テスト文脈(Huawei Cloud、産業デプロイ 9 か月)へと、定常性仮定の応用領域が広がったことを示す実例である。(Source: [[@2026__ICSE-SEIP__PerfScout - An Adaptive Workload Generator in Software Performance Testing]]) - **PerfScout は定常性判定を単一検定でなく 2 検定の併用で頑健化しており、Desai が未回答のままにした「どの確率モデルを使うか」への一つの答えを与える**: PerfScout のアブレーション実験(Table 5)は、ADF 単独・KPSS 単独・PP テスト単独・スロープ法のいずれも HM(調和平均)が最大 0.614 低下することを示し、ADF(自己回帰モデルによる単位根検定)と KPSS(線形トレンドからの逸脱検定)の併用が、いずれか単独使用時の限界(ノイズ感受性・特定の分布仮定への依存)を相互補完することを実証した。定常性モデルが「相対尤度の時間窓平均」としか述べていなかった計測手法に対し、具体的な統計検定の組み合わせとその定量的な有効性を提示する後続の工学的実装例となる。(Source: [[@2026__ICSE-SEIP__PerfScout - An Adaptive Workload Generator in Software Performance Testing]]) ## 未解決の問い - 2σ手法では正規分布近似が前提だが、パフォーマンスメトリクスがログ正規・重裾分布に従う場合の対処は。適合度チェックの自動化は実装されているか（2022 年発表で未回答）。 - 定常性仮定が成立する時間スケールはサービス種別によってどう異なるか。日次・週次の周期性があるシステムに i.i.d. 仮定は適用できるか。 - 「定常性の違反」を定量的に検知するための統計的手法（e.g. 変化点検知、異常検知）との関係はどう整理されるか。定常性モデルは AIOps の異常検知フレームワークと同型か。 - パフォーマンスの「長時間窓で一定」という仮定の時間窓をどう設定するか（サービスのライフサイクル・デプロイ頻度に依存するか）。 - Desai は「相対尤度の時間窓平均」を計測するとだけ述べ、具体的な確率モデル（パラメトリック/ノンパラメトリック、カーネル推定等）を開示していない。どの手法が実装の中核か。 - 定常性モデルを本番運用している事例は Google（Kraken チーム）以外に報告されているか。 - 「解釈モデル → 予測モデル」への移行（Desai transcript）は具体的にどのような形で実現されるか。定常性違反の時系列から障害発生を予測するというアプローチはどの程度実現可能か。 - PerfScout の定常性判定は TPS(スループット)のみを対象とし、応答時間・エラー率は別モジュール(SPOT・報酬関数)で扱う。可用性・正確性次元の定常性仮定([[@2021__SREcon21__Beyond-Goldilocks-Reliability]] の 3 次元定義)は性能テスト文脈でどう対応づけられるか、あるいは対応づけが不要な理由があるのか。 - ADF/KPSS の併用による定常性判定(PerfScout)と、2σ手法の正規分布ベースライン検定(Principled Performance Analytics)は、いずれも「パフォーマンスが安定しているか」を判定する点で同型の問題を扱うが、前者は時系列の単位根・トレンド検定、後者は分布形状の z スコア検定という異なる統計的枠組みに立つ。両者はどのような条件下で使い分けるべきか、あるいは統合可能か(2 ソース以上での比較検証が必要)。 ## 関連 - ソース: [[@2021__SREcon21__Beyond-Goldilocks-Reliability]] / [[@2019__SREcon19 EMEA__Latency SLOs Done Right]] / [[@2022__SREcon22Americas__Principled Performance Analytics]] / [[@2026__ICSE-SEIP__PerfScout - An Adaptive Workload Generator in Software Performance Testing]] - 登壇者: [[Narayan Desai]] / [[Brent Bryan]]（Google） - 著者: [[Yongqian Sun]] / [[Shenglin Zhang]] / [[Dan Pei]]（PerfScout） - 概念: [[サービスレベル目標]] / [[SREの工学化]] / [[ソフトウェア信頼性工学]] - 関連プロダクト: [[PerfScout]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2021__SREcon21__Beyond-Goldilocks-Reliability]]（Goldilocks Reliability 批判・定常性モデルの 3 次元定義・階層的診断事例） - [[@2022__SREcon22Americas__Principled Performance Analytics]]（2σ手法として数理実装・GCP 本番適用・18 時間先行検知の実証） - [[@2026__ICSE-SEIP__PerfScout - An Adaptive Workload Generator in Software Performance Testing]]（ADF/KPSS による局所定常性判定を性能テストのワークロード制御に適用した工学実装。Huawei Cloud 本番デプロイ）