SLI・SLO・SLA の区別 — 指標から目標、契約まで

SLI、SLO、SLA は一文字違いでまとめて扱われがちですが、三つは層の違う概念です。一行で分けると、SLI は測定値、SLO は内部の目標、SLA は外部との契約です。前回、SRE の出発点は信頼性の定量化だと言いましたが、その定量化がまさにこの三層で成り立ちます。この記事は定義の羅列ではなく「自分のサービスに実際に決めていく順序」で進めます。

SLI — 何を測るか #

SLI(Service Level Indicator)はサービスレベルを表す測定値です。重要なのは「ユーザーが体感するもの」を測るという点です。CPU 使用率はユーザーが体感しないので SLI ではありません(運用指標です)。ユーザーが体感するのは、リクエストが成功したか、どれだけ速かったかです。

実務では SLI は大半を比率で定義します。「良いイベント ÷ 全イベント」の形です。

• 可用性 SLI: 成功応答(5xx でない応答)÷ 全リクエスト
• レイテンシ SLI: 300ms 以内に応答したリクエスト ÷ 全リクエスト
• 品質・整合性 SLI: エラーなく処理されたジョブ ÷ 全ジョブ(バッチ・パイプライン)

レイテンシを「平均応答時間」ではなく「しきい値内に収まったリクエストの比率」で定義するのがコツです。平均は多数の速いリクエストが少数の遅い体験を隠しますが、比率の方式は「ユーザーの何 % が良い体験をしたか」を直接語ってくれます。測定位置も決める必要があります。サーバーログ基準か、ロードバランサー基準か、実際のクライアント基準かで、同じサービスの SLI が変わります。可能ならユーザーに近い側(ロードバランサーより外側)をおすすめします。

SLI は 2〜3 個で十分です。指標を 10 個 SLI として宣言すると、どれも目標として機能しなくなります。

SLO — どの水準を約束するか(内部用) #

SLO(Service Level Objective)は SLI に目標値を付けたものです。「可用性 SLI ≥ 99.9%(30 日区間)」のように、指標 + 目標 + 測定区間のセットです。

数値を決める現実的な方法は、上から降ろすのではなく下から積み上げることです。

1. まず現在の性能を測ります。 直近 1〜2 か月の SLI が事実上の現在の水準です。
2. ユーザーとビジネスが要求する下限を確認します。 このサービスが月に何分止まると実際に問題になるのか?
3. 現在の水準と要求の下限の間で、守れる値から始めます。 最初から攻めた目標を掲げると、初月から違反状態で始まって制度そのものが形骸化します。

ここで「ナイン(9)」の感覚が必要です。許容ダウンタイムに換算すると、目標の重さが見えます。

ナインを一つ上げるたびに、コストはおおよそ桁違いに跳ね上がります。そして 100% は目標になり得ません。ユーザーの回線やクラウドの下限より高い信頼性は、ユーザーには区別すらできません。この「残しておいた失敗の枠」が、次回扱うエラーバジェットになります。

SLA — 破れば賠償する外部との契約 #

SLA(Service Level Agreement)は顧客との契約です。水準を破るとクレジット・返金のような賠償が伴う法的な文書で、だから数字を決める主体もエンジニアリングではなくビジネス・法務になります。

実務のルールは一つです。SLA は SLO より緩く置きます。 内部目標(SLO)99.95%、外部契約(SLA)99.9% のように層を作れば、SLO 違反が即座に賠償の事故にならず、対応するバッファが生まれます。SLO をそのまま SLA として売るのは、バッファなしに目標を契約にしてしまう間違いです。クラウド事業者の SLA(賠償条件の付いた 99.9% 台)が彼らの内部目標より緩い値なのも同じ構造です。

逆から読む方法もあります。外部サービスの SLA は「それを下回ればお金を返す」という意味であって、「その水準が保証される」という意味ではありません。依存するサービスの SLA が自分たちの SLO より低いなら、自分たちの SLO はその依存だけですでに危ういのです。直列に依存するコンポーネントの可用性は掛け算で下がる(99.9% が二つ直列なら 99.8%)ことまで計算に入れる必要があります。

三層を一列に並べる #

注文 API を例に三層を埋めるとこうなります。

• SLI: 5xx でない応答の比率(可用性)、500ms 以内の応答の比率(レイテンシ)— ロードバランサー基準
• SLO: 30 日区間で可用性 99.9%、レイテンシ 99%(内部目標、ダッシュボードとアラートの基準)
• SLA: 月の可用性 99.5% 未達でクレジット賠償(顧客契約、ビジネスが決定)

よくある間違い三つも書いておきます。ユーザーが体感しない指標(CPU、ノード数)を SLI にすること、測定なしに SLO の数字から宣言すること、SLO と SLA を同じ値に置くことです。

まとめ #

• SLI は測定値、SLO は内部の目標、SLA は賠償の掛かった外部との契約です。層が違います。
• SLI はユーザーが体感するものを「良いイベントの比率」で定義し、2〜3 個に絞ります。レイテンシも平均ではなくしきい値内の比率で取ります。
• SLO は現在の実測とビジネスの下限の間で、守れる値から始めます。ナイン一つでコストは桁違いに跳ね上がります。
• SLA は SLO より緩く置いてバッファを作り、依存サービスの SLA は掛け算で自分たちの目標を削ることを計算に入れます。
• 100% は目標ではありません。残しておいた失敗の枠を予算として使う方法が、次回のエラーバジェットです。