SLO
Service Level Objective ・ エスエルオー
サービスの信頼性目標を数値で定めたもの。SLIという指標で測り、運用判断の基準にする。
✦ 30秒で試す — 航海「どれくらい壊れてよいか」を、先に数字で決めておく改善案を実行すると、ユーザーが感じる失敗は？予想してみる概要
SLO（Service Level Objective、サービスレベル目標）は、「このサービスはどれくらい信頼できるべきか」を数値で定めた目標です。たとえば「直近30日間で、リクエストの99.9%が成功する」「95%のリクエストが300ミリ秒以内に応答する」のように、期間・指標・目標値の組で表現します。
ここで重要なのが SLI（Service Level Indicator、サービスレベル指標）との関係です。SLI は「実際に測る指標」、SLO は「その指標が満たすべき目標値」です。「リクエスト成功率」というメトリクスが SLI で、「それが99.9%以上であること」が SLO — 測るものと目指す水準を分けて考えるのが出発点です。SLO は単なる数値目標ではなく、アラートの閾値、リリース可否の判断、インフラ投資の優先度まで、運用のあらゆる意思決定の基準線として機能します。
「100%を目指さない」ことが SLO の思想の核心です。完璧な信頼性は原理的に不可能であるだけでなく、目指すこと自体が有害になり得ます。SLO はあえて「ここまで壊れてよい」という許容量を明示することで、信頼性と開発速度のバランスを設計可能にする道具です。
なぜ生まれたか
SLO という考え方が整理される以前、サービスの信頼性目標は「安定稼働に努める」「障害を起こさない」といった曖昧な言葉で語られていました。曖昧な目標は測定できず、測定できない目標は達成も判断もできません。障害が起きるたびに「どこまでやれば十分なのか」の基準がないまま、開発チームは「もっと速くリリースしたい」、運用チームは「もう変更を入れないでほしい」と綱引きを続ける — この対立を裁く客観的な物差しがなかったのです。
もうひとつの問題は「100%神話」でした。信頼性は高いほど良いという素朴な前提のもと、際限なくコストを注ぎ込んでも、ユーザーの体感はある水準を超えると変わりません。ユーザー自身のスマートフォンや Wi-Fi の信頼性が99.9%程度しかない世界では、サーバ側を99.999%にしても差は雑音に埋もれます。しかも信頼性は「9」をひとつ増やすごとにコストが桁で増えていきます。
Google の SRE はこの2つの問題に対して、「信頼性を明示的な数値目標として定義し、それを超える部分は開発速度に投資する」という解を与えました。SLI で測り、SLO で目標を定め、目標との差分をエラーバジェットとして運用に組み込む — この一連の体系の土台が SLO です。
詳細
SLI を選ぶ — 何を測れば「ユーザーの体験」になるか
SLO の質は SLI の選び方で決まります。良い SLI の条件は「ユーザーが体感する品質に近いこと」です。SLI はふつう「良いイベントの数 ÷ 有効なイベントの数」という比率で定義します。代表的なのは、可用性（リクエストのうち成功した割合）、レイテンシとスループット（一定時間内に応答した割合、処理できた量）、データの鮮度・正確性などです。比率にしておくと、0%〜100% の同じ物差しで目標を書け、後で述べるエラーバジェットもそのまま「残りの比率」として計算できます。逆に、CPU 使用率やメモリ使用量は監視には重要でも SLI には向きません。CPU が90%でもユーザー体験が良好なら問題はなく、CPU が10%でも応答が遅ければ問題だからです。
測定点もユーザーに近いほど正確になります。サーバ内部のログで測ると、ロードバランサより手前で落ちたリクエストが数えられません。可能ならロードバランサのログや、クライアント側の計測も組み合わせて「ユーザーから見た成功率」に近づけます。
SLI・SLO・SLA の三層関係
SLI・SLO と混同されやすいのが SLA です。SLA は顧客との「契約」であり、違反すると返金などの補償が発生します。三者の関係は「SLI で測り、SLO を内部目標として運用し、SLA はそれより緩い水準で外部に約束する」という三層構造で捉えると整理できます。
SLO を SLA より厳しく設定しておけば、SLO を割り込んだ時点で社内に警報が鳴り、契約違反（＝補償の発生）に至る前に手を打つ余裕が生まれます。SLO は「早期警戒線」、SLA は「防衛ライン」という関係です。
目標値の決め方と「9の数」
SLO の目標値は「現状の実績」と「ユーザーの期待」の両方から決めます。よく使われるのが可用性の「9の数」で、30日の窓なら、99%は約7時間12分、99.9%は約43分、99.99%は約4分20秒の停止を許容します。9がひとつ増えるたびに許容停止時間は10分の1になり、達成コストはおおむね桁で増えます。冗長化・多重化・自動フェイルオーバーと、スケーリングや分散システムの設計難度が段階的に上がり、人手の対応では間に合わなくなって自動検知・自動復旧が前提になっていくためです。
では、いくら払えば「十分」なのでしょうか。ここで効いてくるのが、ユーザーとサービスの間にある、自分では直せない部分です。ユーザーの体験は、端末・回線とサーバの両方が成功したときだけ成功します。独立に失敗すると考えれば、体感の成功率は両者の掛け算です。端末・回線が99.9%なら、サーバが99%のとき体感は約98.9%、99.9%で約99.8%、99.99%で約99.89%、99.999%でも約99.899%。サーバ側の失敗が減るほど、残る失敗のほとんどは端末・回線の側になり、体感は99.9%の床に張り付きます。一方で費用は桁で伸び続けます。4つ目、5つ目の9は、ユーザーが気づけない差にお金を払っていることになりかねません。
グラフの点を右へ動かして、サーバの9を増やしてみてください。サーバの帯から停止の網掛けが消えていく一方で、体感の帯には紫の網掛け（端末・回線の停止）が残り、曲線が床で平らになる様子が見えます。
グラフの金の点をつかんで右へ動かし、サーバの「9」を増やしてみてください。
帯は30日間。網掛け1本 ≒ 5分の停止（実寸では細すぎて見えないため太らせています）。体感の成功率は、端末・回線とサーバの両方が成功したときだけ成功する掛け算です。
「うちのサービスに本当に4つ目の9が必要か」を問い直すことが、SLO 設計の最初の仕事になります。逆に、決済や認証のように他の多くのサービスから呼ばれる基盤は、呼び出し側の目標を掛け算で削らないよう、利用者よりも一段高い目標を持つ必要があります。依存が増えると全体の稼働率が掛け算で下がる構造は、SLA の記事で詳しく扱います。
期間の取り方にも設計があります。「直近30日間のローリングウィンドウ」なら常に最新の実績を反映でき、「四半期ごと」のようなカレンダー単位の窓なら事業計画や報告と揃えやすい、といった使い分けです。ローリングウィンドウでは、大きな障害は30日後に窓から抜け落ちるまで数字に残り続けます。
運用への組み込み — SLO は決めて終わりではない
SLO は掲げるだけでは機能しません。実務では、SLO の残り許容量であるエラーバジェットを追跡し、消費ペース（バーンレート）に基づいてアラートを設定します。「エラー率が1%を超えた」という瞬間値ではなく、「このペースが続くと窓の終わりまでに SLO を割る」という予測でアラートを鳴らすことで、誤報を減らしつつ本当に危険な兆候を捉えられます。窓の長さの選び方は、エラーバジェットの記事で部品を動かしながら確かめられます。
典型的な落とし穴は4つあります。達成できて当然の緩すぎる SLO（何の判断にも使われない）、恒常的に未達の厳しすぎる SLO（警報が常態化して無視される）、ユーザー体験と乖離した SLI（数字は良いのに苦情が来る）、そして平均値で書いたレイテンシの SLO（一部のユーザーの極端な遅さが平均に埋もれる。レイテンシは「95%が300ミリ秒以内」のようにパーセンタイルで書きます）です。SLO は一度決めたら固定ではなく、実績とユーザーの声を見ながら定期的に見直す「生きた合意」として扱うのが健全な運用です。
試問
ユーザーの体験は、端末・回線とサーバの両方が動いているときだけ成功します。グラフの金の点を左右にドラッグすると、サーバの稼働率（「9」の数）が変わり、ユーザーから見た1か月の失敗の時間と、費用（稼働率99%のときを1とした相対値）が変わります。端末・回線の信頼性はユーザー側のもので、今は99.9%（それだけで月に約43分の失敗）です。
グラフの金の点をつかんで右へ動かし、サーバの「9」を増やしてみてください。
帯は30日間。網掛け1本 ≒ 5分の停止（実寸では細すぎて見えないため太らせています）。体感の成功率は、端末・回線とサーバの両方が成功したときだけ成功する掛け算です。