イベントベースSLO - yuuk1's Digital Garden

# イベントベース SLO ## 定義 SLO の集計方式には大きく 2 種類ある。**時間スライス（Time Slice）方式**は一定時間区間ごとに「良い区間か悪い区間か」を二値判定し、良い区間の割合を SLI とする。**イベントベース（Event-based）方式**は個々のリクエスト（イベント）を単位として「全リクエストのうち良いリクエストの割合」を SLI とする。 $SLI_{event} = \frac{Good\ Events_{TW}}{Total\ Events_{TW}} \times 100$ $SLI_{time\_slice} = \frac{Good\ Minutes}{Total\ Minutes} \times 100$ ### 時間スライス方式の問題：すべての分は等価でない時間スライス方式は「分」を票として扱う。ピーク時（例: 1 分間に 1,000 リクエスト）も深夜（例: 1 分間に 10 リクエスト）も 1 票として扱うため、ユーザー影響の大きさが反映されない。(Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) **具体例**（p.10）: 99.95 SLO、95% 閾値設定の場合、以下 6 分のデータを考える。 | 分 | Good | Total | SLI | 判定 | |---|---|---|---|---| | 1 | 98 | 100 | 98% | 良 | | 2 | 90 | 100 | 90% | 良 | | 3 | 1 | 100 | 1% | **悪** | | 4 | 9 | 10 | 90% | 良 | | 5 | 95 | 100 | 95% | 良 | | 6 | 98 | 100 | 98% | 良 | SLI_time_slice = 4/6 = **66%**（SLO 違反）。ただし Minute 3 の 99 件の悪いリクエストは「5% のエラーがエラーバジェットに届かない」閾値の外側に吸収されてしまう場合がある。反対に、Minute 4 では Total:10 と少量のトラフィックで 90% の SLI がエラーバジェットに大きく響く場合がある。 ### イベントベース方式の優位性同じデータをイベントベースで集計すると、ピーク時の大量エラーがリクエスト数比で正確に反映される。結果として **EBR（エラーバジェット残高）の変動がインシデントの深刻度と比例**する。Capital One の実例（p.19）では "Badder Incident" で 18.1%↓、"Baddest Incident" で 36.6%↓ となり、障害規模との相関が視認できた。時間スライス方式で同じデータを見ると "Badder Incident 0%↓"・"Baddest Incident 400%↓" という逆転現象が生じた（p.15）。 Capital One チームはこの 2 つのグラフに固有の呼称を与えている（口頭説明）: - **"L グラフ"**: 時間スライス EBR のグラフ。急落後に横ばいとなる L 字形が特徴で、インシデントの深刻度差がほとんど反映されない。 - **"money chart"（お金になるグラフ）**: イベントベース EBR のグラフ。インシデントとの相関が分かりやすく、SLO の価値を経営層・ステークホルダーに説明する際の「売り物」になる。 ### 数式（付録）時間窓 TW における完全な計算式（Source: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]] p.38）: $SLI_{TW} = \frac{Good\ Events_{TW}}{Total\ Events_{TW}} \times 100$ $EB\ Max_{TW} = (1 - Objective) \times Total\ Events_{TW}$ $EB\ Current_{TW} = EB\ Max - Bad\ Events_{TW}$ $\%EB\ Remaining\ (EBR\%) = \frac{EB_{Current-TW}}{EB_{Max-TW}} \times 100$ 目標 %EBR から Objective を逆算するデフォルト SLO 式（「何 % にすればいいか分からない」チーム向け）: $SLO_{default} = \left(\frac{bad}{(EB\%-1) \times Total} + 1\right) \times 100$ ## 横断的知見 - **時間スライスはトラフィックが平坦なシステムでは問題が出にくい**: バースト性の低いシステムでは両方式の差は小さい。問題が顕在化するのはトラフィックが周期的・季節的に大きく変動するシステムや、ピーク時に集中的に障害が起きるシステムである。 - **イベントベース集計はサンプリングと相性が良い**: トラフィックが多く全リクエストを計測しにくい場合、一定割合のサンプルからイベントベース SLI を算出できる。時間スライスでサンプリングすると分単位の判定精度が下がりやすい。 - **非同期パイプラインではイベントの「最終状態」のみを Valid Events として扱うことが重要**: eBay の実装（SREcon25 Americas）では、非同期イベントは SUCCESS・ABANDONED・RETRY の 3 状態を取るが、RETRY は過渡状態であり Valid Events から除外する。Valid Events = SUCCESS | ABANDONED のみ。これにより、再試行中のイベントが SLI を二重カウントする問題を回避できる。Capital One のイベントベース SLO における「リトライの二重カウント問題」（上記未解決の問い）の実践的な回答として機能する。(Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]], [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) - **非同期パイプラインのレイテンシ SLI は HTTP の応答時間とは異なり「累積ホップ時間」で定義される**: eBay の実装では Producer → Queue 待ち → Consumer 処理 → Retry Queue 待ち → 再処理の全時間を Prometheus histogram に累積し、end-to-end レイテンシ SLI とした（合計 60ms の例: 10+10+10+30ms）。HTTP サービスの `response_time` と異なり、非同期では複数ホップにまたがる時刻スタンプ差分を記録する計装設計が必要になる。(Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]]) - **教科書レベルの言説がイベントベース SLI を「推奨されるデフォルト」として明示的に位置づけた**: Capital One の実証(時間スライスは深刻度と乖離し、イベントベースは比例する)を踏まえ、*Observability Engineering* 第 2 版第 11 章は時間ベース SLI(例: 5 分ウィンドウごとの p99 レイテンシ)とイベントベース SLI(例: ローリング時間窓中の good event 比率)を対比し、「イベントベース指標のほうがより信頼性が高く粒度の細かい方法だ」として推奨する。理由の詳細は次章(第 12 章)に譲るとしつつ、章内の SLI 設計例(チェックアウトの成功判定を `IF(qualifier, AND(success, latency))` で表現)は個々のイベント単位の判定として書かれており、時間スライス集計を前提としていない。本 concept が Capital One の 1 事例(SREcon23 Americas)から積み上げてきた知見が、SRE 実務コミュニティを超えて O'Reilly の標準的教科書の推奨事項として確立されたことを示す一次証拠となる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]], [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]])。 - **第12章は「なぜイベントベースが優れるか」を厳格な SLO(4ナイン以上)における評価粒度の遅延として定量化し、第11章の推奨を根拠づける**: 第11章がイベントベース SLI を「推奨されるデフォルト」と位置づけたのに対し、第12章はその理由を具体的な数値で示す。時系列(1分粒度)評価では、94%のリクエストが300ミリ秒未満でも「1分全体」が不良と判定され、4.38分/月のエラーバジェットの25%を一度に失う。Amazon CloudWatch の無料枠デフォルトである5分間隔評価では、たった1回の評価失敗でSLO違反になりうる。イベントベースでは同じ状況で6%のリクエストのみがバジェットから差し引かれる。この対比は、Capital One(SREcon23 Americas)の「時間スライスはインシデント深刻度と乖離する」という実測結果を、より根本的な「評価単位の粒度がエラーバジェット計算の精度を決める」という原理として一般化するものである (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]], [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]])。 - **イベントデータは事前集計データと異なり、SLI/SLO基準の変更後に生データへ遡って再計算(バックフィル)できる**: 第12章は、イベントデータからSLO値を事前計算・最適化することは常に可能だが、逆に事前集計済みの時系列データからイベント単位のデータへ遡ることはできないと指摘する。これは Capital One の「イベントベース化は集計後のSLO精度を改善する」という主張に、「SLI/SLOの定義変更に対する回顧的な検証可能性」という別の利点を追加する。時間スライス方式では、SLI定義を変更した場合、変更後の効果を確認するには数か月新規データを待つ必要があるが、イベントベースでは既存データへの遡及適用で即座に検証できる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 - **顧客向けLLM製品のレイテンシSLOにも「良い/悪い」イベント集計が転用され、閾値は動的ベースラインとして設定される**: これまでの Sources は主にバックエンドの可用性・エラー率(Capital One の障害重大度分析、非同期パイプラインの成功/放棄判定)を対象にしてきたが、[[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]](Fin/Intercom)は同じ「イベント単位で良い/悪いを判定する」設計を、LLMベースのカスタマーサポートエージェントのレイテンシ("time to first token")へ適用する。ここでの「良いイベント」は固定の閾値ではなく**動的に確立したベースラインより高速な対話**であり、モデル可用性のノイズ(プロバイダ障害・日次季節性・容量不足)を理由に固定閾値アラームを明示的に避けている。時間スライスでなくイベントベースを選ぶ動機も、Capital One の「ピーク時のバースト障害が時間スライスでは希釈される」問題とは異なり、「個々の対話のレイテンシ体験をそのまま単位として扱いたい」という顧客体験志向にある。7日間のコンプライアンス率(84.8%)という長期トレンドを見ることで一過性のスパイクを無視する運用も、Capital One の「money chart」と同様に、短期ノイズを除いた深刻度評価を志向する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]], [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]]) - **データパイプラインの「完全性」SLO は、リクエストの成功/失敗ではなくデータ項目の到着/欠損を単位とする、ドメインの異なるイベントベース集計の一例である**: これまでの Sources はいずれもリクエスト/対話単位の可用性・レイテンシ・成功判定を「イベント」としてきたが、[[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]]が示すサンプル SLO「取り込みの間にカウントされたイベントの99.9%が取り込みから15分以内に正常に処理され、保存される」は、データパイプラインが受け取った**データレコードそのもの**を個々のイベントとして数える。これは本 concept が積み上げてきた「Good Events / Total Events」という比率構造をそのまま流用しつつ、対象を「リクエストの成否」から「データ項目の到達・処理完了」へ拡張したものであり、eBay の非同期パイプライン(SREcon25 Americas)が SUCCESS/ABANDONED/RETRY という状態遷移でイベントを分類したのと同様に、データ完全性の文脈でも「一定時間内に処理・保存が完了した項目」を Good Event、遅延到着や欠損を Bad Event として扱うことでイベントベース集計が成立する。時間スライス方式では「その分にデータが何件欠けたか」という粒度を捉えにくく、Capital One が指摘した「バーストするトラフィックの希釈」と同型の問題が、データ完全性の文脈でも起こりうることを示唆する(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] §11.3.2.2, [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 - **Schlossnagle(2018)は Capital One(2023)の 5 年前に、同じ「時間スライス対イベントベース」の対立を「時間量方式対トランザクション方式」という別名の下で論理的に導出し、両者を折衷する第 3 の方式まで提案していた**: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] の「時間量(time quantum)方式」は本 concept の時間スライス方式と、「トランザクション方式」はイベントベース方式と、それぞれ同じ集計構造を指す。Schlossnagle は 1 日 1 億件・99.9% 稼働時間という思考実験で、失敗が均等分散する場合(成功率 99.998%)と 30 分間の利用ウィンドウに集中する場合(認識される稼働時間 96.666%)とで顧客体験がまったく異なるにもかかわらず、時間量方式はどちらでも同じ「1,440 件中 1,440 件が良」という判定を返しうると指摘し、Koss・Goins(SREcon23 Americas)が実測で示した「時間スライスはインシデント深刻度と乖離する」現象を、実データなしに導出していた。さらに Schlossnagle はトランザクション方式単独の欠陥(ネットワーク越しに試行件数を計測できない)を指摘したうえで、「計測不能な時間量は障害とみなす」という妥協で両者を折衷する「クォンタイルズ・オーバー・クォンタムズ」方式を提案しており、これは本 concept が単一ソースからは持たない第 3 の集計方式にあたる。ただし Schlossnagle はこの折衷方式を SLA の文脈で提示しており、「Valid Events からの RETRY 除外」(eBay)のようなイベント単位の精緻化までは踏み込んでいない (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] §21.2, [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]])。 ## 未解決の問い - クォンタイルズ・オーバー・クォンタムズ方式(時間量+トランザクションの折衷)は、時間スライス方式・イベントベース方式のどちらとも異なる第 3 の集計方式である。Capital One の実測(L グラフ対 money chart)をこの折衷方式に適用した場合、時間スライス方式とイベントベース方式のどちらの挙動に近づくか、あるいは両者の中間的な特性を示すかは、本 concept の現ソース群では検証されていない。 - Finの事例は「動的に確立したベースライン」を良い/悪いの判定基準にしているが、このベースラインの再計算頻度・手法(移動平均か、モデル/機能変更ごとの再ベースライン化か)は本ソースに明示されていない。動的ベースラインの設計はCapital Oneの固定Objective(例: 99.95%)とどう整合させるべきか。 - データ完全性 SLO(Hidalgo ch.11)にも Capital One 流の時間スライス対イベントベースの比較(L グラフ対 money chart)を適用した場合、同様の乖離が実測されるか。本ソースは概念上の類似を示すのみで、データ完全性ドメインでの定量的な検証は行っていない。 - 時間スライス方式が採用されてきた歴史的経緯は何か（計装コストの問題か、Prometheus の recording rule の影響か）。 - ~~イベントベース方式ではリトライが二重カウントされる問題をどう扱うか~~ → **解決済み**: 非同期パイプラインでは RETRY を Valid Events から除外し、最終状態 SUCCESS | ABANDONED のみを集計対象とする（eBay 実装 / SREcon25 Americas）。 - Polling Period（最細粒度の集計区間）と Sampling Window（Burn Rate 計算用の区間）の設計ガイドライン（p.37）の実践的な選び方。transcript によると Capital One チームも「時間の単位について長時間議論した」と述べており、定番ガイドラインはまだ確立していないと思われる。 - 非同期パイプラインで Prometheus histogram の `le` ラベルをレイテンシ SLI に使う際、バケット境界の設計（10000ms, +Inf 以外のバケット粒度）はどう決めるか。 ## 関連 - 概念: [[サービスレベル目標]] / [[エラーバジェット]] / [[SLI-SLO段階的導入]] - ソース: [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] / [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]] - 人物: [[Michael Goins]] / [[Troy Koss]] / [[Theo Schlossnagle]] - 組織: [[Capital One]] / [[Honeycomb.io]] / [[Fin]] / [[Intercom]] / [[Circonus]] ## 出典 - [[@2023__SREcon23Americas__Not-All-Minutes-Are-Equal]] - [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]] - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 11 データの信頼性]] - [[@2021__OReillyJapan__SREの探求 - Chapter 21 サービスレベル目標の技法と科学]](時間量方式・トランザクション方式・クォンタイルズ・オーバー・クォンタムズという折衷方式、§21.2)