SRE 実践 #1 SLI・SLO 設計 — 何を測り、いくつの 9 を約束するか

SRE と DevOps の違いで SRE の核心は「信頼性を数字で契約すること」だと整理し、SLI・SLO・SLA の区別で 3 つの用語を整理しました。このシリーズはその次の問いに答えます。では、実際にどうやるのか? 第 1 回はすべての出発点である SLI と SLO の設計プロセスです。概念は知っていても「うちのサービスの SLO を決めろ」という業務の前で詰まるポイントを、順番にほぐしていきます。

出発点はダッシュボードではなくユーザージャーニーです #

いちばんよくある間違いは、すでに収集しているメトリクスの一覧(CPU、メモリ、スレッド数)から SLI を選ぶことです。CPU 使用率 90% はユーザーにとって何の意味もありません。ユーザーが感じるのは「チェックアウトができるか」「検索結果が速く出るか」です。

だから設計はクリティカルユーザージャーニー(CUJ, Critical User Journey)を列挙するところから始めます。EC サイトならこうなります。

1. 商品検索 → 結果表示
2. 商品ページの閲覧
3. カートに入れる → 決済完了

ジャーニーごとに「これが動かないと、ユーザーはサービスが壊れたと感じるか?」を問うて優先順位を付けます。決済は無条件で上位、最近見た商品ウィジェットは下位です。SLO は上位のジャーニーから、最初は 2〜3 個だけ作ります。最初から数十個作ると、誰も見ないドキュメントになります。

良い SLI は比率です — good events / total events #

ジャーニーを選んだら、その状態を表す指標、SLI を定義します。実務で検証されてきた形はひとつに収束しています。全イベントに占める良いイベントの比率です。

比率の形が良い理由は 3 つあります。0〜100% に正規化されて SLO と直結し、トラフィック規模と無関係に比較でき、エラーバジェットの計算が自然につながります。

レイテンシで注意する点をひとつ。「平均応答時間 300ms」は SLI に使いません。平均は少数の非常に遅いリクエストを覆い隠します。「300ms 以内に処理されたリクエストの比率 99%」のようにしきい値 + 比率で定義すれば、遅いテールがそのまま見えます。パーセンタイル(p99)での管理も、同じ問題意識の別表現です。

どこで測るか — 測定ポイントのトレードオフ #

同じ SLI でも測定位置によって値が変わります。

• サーバー(アプリケーション)測定: 実装は簡単ですが、サーバーに届かなかった失敗(DNS、ネットワーク、ロードバランサー障害)が抜けます。実際より良く見えます。
• ロードバランサー測定: サーバーダウンまで捕捉でき、実装コストも低く、実務のデフォルトとして最もバランスが良いです。
• クライアント(RUM)測定: ユーザーが実際に体験したものに最も近いですが、ユーザーの端末やネットワークの問題まで混ざり込み、こちらで制御できないノイズが大きくなります。

原則はこうです。できるだけユーザーに近いところで測る。ただし自分たちが制御できる範囲の中で。 多くのチームにとって答えはロードバランサーのログで、余力ができたらクライアント測定を補助指標として足します。

SLO の数値 — 願望ではなく現在の性能から出発します #

「いくつの 9 にするか」を会議室で決めるのは順序が逆です。正しい順序はこうです。

1. 現在の性能を測ります。 直近 4 週間の実際の SLI が 99.94% なら、それが出発点です。
2. ユーザーの期待と突き合わせます。 今の性能でユーザーの不満がないなら、現在の性能の近く(99.9%)が合理的な SLO です。不満があるなら目標を上げ、改善の作業を計画します。
3. コストを確認します。 9 をひとつ増やすたびにコストは掛け算で増えます。99.99% は月 4 分の障害しか許さない水準で、人がページを受けて対応するだけで数分かかります。このレベルからは自動復旧の設計が前提になり、その投資がこのサービスに見合うのかを問わなければなりません。

覚えておく文はひとつです。SLO はマーケティングの数字ではなく運用の約束です。 守れない 99.99% より守られる 99.9% のほうが、チームにもユーザーにも良い。そして 100% はどんなサービスにも正しい目標ではありません。100% を目標にした瞬間、すべての変更が敵になり、デプロイは止まります。

測定ウィンドウ — ローリング 4 週間がデフォルトです #

SLO は期間とセットで定義します。「28 日ローリングウィンドウで 99.9%」のように書きます。

• ローリングウィンドウは常に直近 N 日を見ます。障害の影響がウィンドウから徐々に抜けていくので、運用感覚とよく合います。4 週間(28 日)が事実上の標準です。曜日パターンをちょうど 4 回含むため、30 日より安定します。
• カレンダーウィンドウは四半期・月単位でリセットされます。契約(SLA)や報告には合いますが、リセットの瞬間にバジェットが突然回復する不自然さがあります。

社内運用はローリング 28 日、対外報告は四半期、と二本立てにするチームが多いです。

SLO 仕様書に書くこと #

設計の結果は 1 ページのドキュメントに残します。最低限の項目は次のとおりです。

• SLI の定義: 良いイベントと全イベントの正確な定義、測定位置(どのログ、どのメトリクス)、除外条件(ヘルスチェックのトラフィック、ボットなど)
• SLO の目標とウィンドウ: 99.9% / ローリング 28 日
• オーナーとステークホルダー: この SLO が壊れたとき誰が動くのか
• エラーバジェットポリシーへのリンク: バジェットが尽きたら何をすると合意したか(次回のテーマです)
• 見直しの周期: 最低でも年 1 回、またはサービスの性質が変わったとき

除外条件を明記することが特に重要です。「計画メンテナンスは含むのか」「クライアント起因(4xx)は分母に入れるのか」といった問いを、障害の真っ最中に初めて議論することになったら手遅れです。

まとめ #

• SLI はメトリクス一覧ではなく、クリティカルユーザージャーニー(CUJ)から出発します。最初は上位ジャーニー 2〜3 個だけ SLO を作ります。
• 良い SLI は good/total の比率です。レイテンシは平均ではなく「しきい値以内の比率」で定義します。
• 測定はユーザーに近く、ただし制御可能な範囲で。実務のデフォルトはロードバランサーです。
• SLO の数値は現在の性能から出発し、ユーザーの期待とコストに突き合わせて決めます。100% は目標ではありません。
• ウィンドウはローリング 28 日が基本で、定義・除外条件・オーナーをドキュメントに残します。
• 次回はこの SLO から生まれるエラーバジェットを実際に運用する方法、ポリシーとバーンレートです。