サービスレベル目標 - yuuk1's Digital Garden

## 定義サービスレベル目標（SLO）とは、サービスの信頼性・性能に関する定量的な目標値である。SLI（サービスレベル指標）を計測し、SLO を満たすか否かを判定する。SLA（サービスレベル合意）は SLO に違反時の帰結（返金等）を付した契約上の約束であり、SLO + 帰結 = SLA と定式化される (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。「ナイン」表現（99.9%、99.99% 等）はクラウドの可用性を要約する事実上の標準だが、Mogul+Wilkes は「ナインだけでは不十分」と論じ、短時間断続障害と長時間大規模障害の区別・グレースフルデグラデーションの記述・ビジネス的重要日の重み付けができないと指摘する (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 ## 三つの要件と既存指標の限界 Hauer+ は「良い可用性メトリクスは**有意義性**（ユーザー体験を捉える）・**比例性**（変化に比例する）・**実用性**（原因の洞察を与える）の三要件を同時に満たすべき」と定式化した (Source: [[@2020__NSDI__Meaningful Availability]])。既存指標の限界: - **成功率**（成功リクエスト数 / 総リクエスト数）: 最活発ユーザーに最大 1,000 倍偏り、障害中のユーザー行動変化（リクエスト断念）で実際の影響を過少評価する (Source: [[@2020__NSDI__Meaningful Availability]])。 - **インシデント比**（稼働分 / 総分）: 任意の「インシデント」しきい値に依存し、大規模分散システムは「完全に停止」も「完全に稼働」もほぼないため不適切 (Source: [[@2020__NSDI__Meaningful Availability]])。 - **合成プローブ**: ユーザーの実際のワークロードを代表しない (Source: [[@2020__NSDI__Meaningful Availability]])。 ## ウィンドウ付きユーザーアップタイム Hauer+ が Google G Suite で評価・本番展開した新指標 (Source: [[@2020__NSDI__Meaningful Availability]]): 1. **ユーザーアップタイム**: 各ユーザーの細粒度リクエストログからアップ分・ダウン分を算出し、全ユーザーの均等加重平均で集約する。カットオフ（99 パーセンタイル到着間隔、Gmail では 30 分）を設け非活性期間を除外することで有意義性と比例性を同時に実現する。 2. **ウィンドウ付き拡張**: 1 分から四半期まですべてのウィンドウサイズで同時に最悪可用性を算出し、MCR（Maximum Contiguous Ratio）曲線として可視化する。曲線上の「膝」の位置で短時間断続障害と長時間大規模障害を区別でき、実用性を担保する。 ## SLE/CBE によるリスク明示的分担 Mogul+Wilkes は SLO 定義の困難さを統計学的意思決定（仮説検定・サンプリング・推論手法選択）との同型性として捉え、「法律家的思考から統計家的思考への転換」を提唱する (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]): - **SLE（サービスレベル期待）**: プロバイダが通常条件下で顧客に期待させる挙動。結果保証ではなく期待管理。 - **CBE（顧客挙動期待）**: プロバイダが SLE を満たすために前提とする顧客側の挙動。統計多重化に伴う不確実性を SLO 枠組みに内在化させるための仕組み。 - 「SLOgician」という専門職の必要性——統計家と同様の謙虚さ（不確実性下での限界認識）が不可欠と論じる。 ## 可用性への「セキュリティ的思考」 Mogul+ は大規模インフラストラクチャの可用性にはセキュリティと同様の「敵対的思考」が必要と主張する (Source: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]): - スレットモデリング: 障害の脅威モデルを明示化する。 - 深層防御: 単一のメカニズムに依存しない。 - フェイル・スタティック: 依存先が停止しても直前の状態で継続動作する（セキュリティの「デフォルト拒否」に相当）。 - Wheel of Misfortune: SRE のインシデント訓練をペネトレーションテストの類似と位置づける。 - 素朴なサブシステム SLO 分解（確率の積算等）は依存関係の相関を見落とし誤りを生む。 ## SLO 拡散（高レベル→低レベル分解） Sedlak+ はマイクロサービスパイプラインにおいて高レベル SLO（応答時間・顧客満足度等）を自動的に低レベル SLO とパラメータ割り当てへ分解する 3 ステップ方法論を提案する (Source: [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]]): 1. マイクロサービスパイプラインのベイズネットワークモデル化。 2. 条件付き依存関係に基づく SLO 制約伝播。 3. 矛盾検知と自律的解決。評価では複数パイプラインで SLO 達成率 83〜100% を達成し、許容範囲パラメータ λ の過度な厳格化と SLO 間のコンフリクトが充足率を急激に低下させるリスクを定量化した。 ## カーボン認識 SLO 管理 CASCA はマイクロサービスアーキテクチャ原則に基づき、コンピューティングコンティニュアム環境でプロバイダのプライバシーを保護しながら SLO を充足するプラットフォームを実装する (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。EMMa マイクロサービスを通じてカーボンフットプリントを報酬関数に組み込み、SLO 充足とサステナビリティの両立を図る。宣言的設定管理（設定ファイル修正 + コンテナ再起動）は命令的手法比で約 53.7 秒の短縮を実現し、SLO の動的変更コストを低減する。 ## 横断的知見 - **SRE Book が SLI/SLO/SLA の実践的定義を最初に体系化した**: SLI を定量的サービス計測、SLO を SLI の目標値、SLA を帰結付き契約と 3 段階で定義し、「パーセンタイルを使え、平均は使うな」「測りやすさでなくユーザー優先度でメトリクスを選べ」「完璧を求めるな、エラーバジェットを維持せよ」の 3 原則を提示した。Mogul+ (2017/2019) の測定論、Hauer+ (2020) の指標設計はこの実践的基盤の上に構築されている (Source: [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 - **メトリクスの進化に 10 年の系譜がある**: Mogul+ (2017) が可用性定義の困難さを提起 → Mogul+Wilkes (2019) が SLE/CBE で期待管理への転換を提唱 → Hauer+ (2020) がウィンドウ付きユーザーアップタイムで三要件を同時に満たす指標を G Suite 本番で実証。3 本を並べると「何を測るべきか」→「どう約束すべきか」→「どう測るか」の 3 段階が見え、指標設計はいまだ探索段階にある (Source: [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]], [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]], [[@2020__NSDI__Meaningful Availability]])。 - **高レベル SLO の自動分解と可用性指標は相補的**: Hauer+ のウィンドウ付きユーザーアップタイムが「何が起きたか」を測り、Sedlak+ の拡散方法論が「何を設定すべきか」を決める。前者は事後的な計測、後者は事前的な制約伝播であり、両者をフィードバックループで結ぶことで SLO 管理の閉ループが構成できる (Source: [[@2020__NSDI__Meaningful Availability]], [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]])。 - **SLO とサステナビリティの緊張関係が浮上**: CASCA は FPS SLO 充足率ではカーボン非認識の貪欲方式（90.6%）に劣る（RLDS: 85.2%）が、カーボンフットプリントでは最良（72.4 vs 74.9 mgCO₂/分）。性能 SLO とサステナビリティ SLO のトレードオフは AIOps の既存 4 段タクソノミ（検知→箇所特定→RCA→緩和）に「コスト/持続可能性」という第 5 の軸を加える可能性がある (Source: [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]])。 - **「法律家から統計家へ」の転換は AIOps エージェントの保証契約設計に直結する**: [[エージェント運用安全性]] の assurance contract / verification wall の語彙と、SLE/CBE のリスク分担枠組みは「契約 = 期待 + 帰結」という点で同型であり、agentic SRE の安全仕様（[[Transactional No-Regression]]）に SLE/CBE 的な双方向期待管理を載せることが自然な拡張方向だ (Source: [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]])。 - **SLA は「設計段階で組み込む制約」として 2007 年に位置づけられていた**: Hamilton は SLA を可用性メトリクスの議論以前に、サービス設計の酸性試験（acid test）として定義した——「任意のサーバをいつでもワークロードのドレインなしに停止でき、かつ SLA を満たせるか」。Mogul+ (2017/2019) が SLO/SLE の測定・約束の難しさを論じたのに対し、Hamilton (2007) は SLA を同期冗長と自動フェイルオーバの設計判断の帰結として扱う。測定の精緻化（Hauer+ 2020）と設計段階での SLA 組み込み（Hamilton 2007）は相補的な視座である (Source: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]], [[@2020__NSDI__Meaningful Availability]])。 ## 未解決の問い - ウィンドウ付きユーザーアップタイムは Google G Suite（プロダクティビティスイート）で評価されたが、マイクロサービスベースのクラウドインフラ（IaaS/PaaS）に直接適用可能か。IaaS ではユーザーの「リクエスト」を定義すること自体が困難では。 - SLO 拡散のベイズネットワークモデルは静的なパイプライン構造を前提とするが、動的にスケーリングするマイクロサービス環境でのリアルタイム更新は実現可能か。 - SLE/CBE 枠組みは概念的提案にとどまり、実装・評価は未着手。実際のクラウドプロバイダでの採用事例は報告されていない。 - CASCA のカーボン認識 SLO は小規模テストベッド（5 マイクロサービス）での評価にとどまり、大規模本番での有効性は未検証。 - 可用性への「セキュリティ的思考」の有用性は定性的に論じられているが、その適用がどの程度可用性改善に寄与するかの定量的評価は存在しない。 ## 関連 - ソース: [[@2007__LISA__On Designing and Deploying Internet-Scale Services]] / [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]] / [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]] / [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] / [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] / [[@2020__NSDI__Meaningful Availability]] / [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] / [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]] - エンティティ: [[Jeffrey C. Mogul]] / [[John Wilkes]] / [[Tamás Hauer]] / [[Google]] / [[Boris Sedlak]] / [[Schahram Dustdar]] / [[CASCA]] / [[SRE Book]] / [[Ben Treynor Sloss]] - 概念: [[AIOps]] / [[agentic SRE]] / [[エージェント運用安全性]] / [[Transactional No-Regression]] / [[インシデント管理]] / [[エラーバジェット]] - 関連 MOC: [[structures/SRE - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - [[@2007__LISA__On Designing and Deploying Internet-Scale Services]]（Overall Application Design: SLA を同期冗長設計の酸性試験として位置づけ） - [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - [[@2020__NSDI__Meaningful Availability]] - [[@2024__SOSE__Diffusing High-level SLO in Microservice Pipelines]] - [[@2026__arXiv__A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management]] - [[@2016__OReilly__SRE Book - Chapter 3 Embracing Risk]](エラーバジェットの体系的定義、100% 可用性の非追求) - [[@2016__OReilly__SRE Book - Chapter 4 Service Level Objectives]](SLI/SLO/SLA の実践的定義、パーセンタイル原則、エラーバジェット運用)