「うちのサービス、可用性は何パーセントを目指せばいいですか」と聞かれて、即答できる人は多くないはずです。
SRE の教科書はこの問いに、まず何を測るかを決め、次に落としてよい量を決めるという順番で答えます。
その道具が SLI と SLO です。
筆者も SRE を目指して学んでいる途中なので、Google の SRE 本と SRE Workbook という一次情報をたどりながら、この 2 つの言葉を整理しました。
SLI と SLO を分けて持てば、「99.9% と 99.99% のどちらを選ぶか」を感覚ではなく数字で議論できるようになるはず。
SLI は「測り方」、SLO は「目標値」
まずは言葉の整理から。
SLI（Service Level Indicator）は、提供しているサービスの水準を注意深く定義した定量的な指標です。
Google の SRE 本では、レイテンシ・エラー率・スループット・可用性などが代表例として挙げられています。
SLO（Service Level Objective）は、その SLI に対して設定する目標値、または目標の範囲を指す言葉。
「リクエストの 99.9% が 300ms 以内に返る」と書けば、前半の「300ms 以内に返るリクエストの割合」が SLI で、後半の 99.9% が SLO という関係ですね。
似た言葉に SLA（Service Level Agreement）がありますが、こちらは SLO を守れなかったときの結果まで含んだ利用者との契約なので、性質が違うのです。
SRE Workbook はさらに踏み込んで、SLI は「良いイベントの数 ÷ 有効なイベントの総数」という比率で表すことを勧めています。
0% から 100% の範囲に収まるので直感的に読めますし、後で説明するエラーバジェットの計算がそのまま成り立つのが利点。
リクエスト駆動のサービスなら可用性・レイテンシ・品質、データパイプラインなら鮮度・正確性・カバレッジ、といった具合に、サービスの型ごとに測るべき SLI の種類も整理されています。
100% を目指してはいけない理由
ここが SLO の考え方でいちばん腑に落ちにくく、そしていちばん大事なところです。
SRE 本は、SLO が 100% 守られることを求めるのは非現実的であるだけでなく、望ましくもないと言い切っています。
完璧を求めると、新機能を出すたびに慎重になりすぎて開発が止まり、残りの信頼性を得るための投資も跳ね上がるためです。
そこで出てくるのがエラーバジェットという発想。
SRE Workbook の定義は単純で、エラーバジェットは 100% から SLO を引いた残りになります。
SLO が 99.9% で月に 300 万リクエストを捌くなら、3,000 件までは失敗してよい、と数えられるわけです。
この「失敗してよい量」があるからこそ、リリースを進めるか止めるかを感情ではなく残高で決められるようになります。
予算が残っていれば攻めてよく、使い切ったら安定化に切り替える。
開発側と運用側の綱引きを、同じ数字を見て判断する仕組みに変えるのがエラーバジェットの役割です。
SLO を決めるときの 5 つの注意
SRE 本には、目標値を選ぶときの指針がいくつか挙げられています。
筆者が特に重要だと感じたものを 5 つに絞りました。
- 今の実測値をそのまま目標にしない（無理な水準を「前例」として固定してしまう）
- 集計方法は単純に保つ（複雑な指標は変化の理由が読めなくなる）
- 「絶対」を避ける（無限にスケールする・常に利用可能、といった要求は資源を食いつぶす）
- SLO の数は必要最小限にする（判断に使われない SLO は捨てる）
- 最初は緩めに置いて、あとから締める（厳しすぎる目標を後で緩めるより現実的）
なかでも 1 つ目は、測れるようになった途端に「今の数字を守れ」と言われがちなので、事前にチームで合意しておきたい点です。
SLO は約束であって、現状の写しではありません。
利用者が何をもって「使えている」と感じるかから逆算して置く、という順番を崩さないのがコツでしょう。
最初の一歩は「仕様」と「実装」を分けること
実際に SLI を決めようとすると、「何で測るか」の議論が先に始まりがちです。
SRE Workbook は、SLI の仕様（利用者にとって何が大事か）と実装（どのデータでどう測るか）を分けて考えるよう勧めています。
たとえば仕様が「トップページが速く表示されること」なら、実装はロードバランサのログでも、クライアント側の計測でも、外部からの定期アクセスでも構いません。
実装ごとに品質やカバレッジ、工数のトレードオフがあるので、仕様を先に固めてから比べると迷いが減ります。
この考え方は、SRE と DevOps の関係を整理した記事で触れた「運用の課題をエンジニアリングで解く」姿勢そのものでした。
DevOps が「壁を壊す」文化の話だとすれば、SLI と SLO はその壁の代わりに置く共通の物差しです。
最後に
SLI は「何を測るか」、SLO は「どこまでを約束するか」、エラーバジェットは「その約束の裏返しとして、どれだけ失敗してよいか」。
この 3 つを一組で押さえると、「可用性は何パーセントを目指すか」という問いが、利用者の体験から逆算して決める設計の問題に変わります。
筆者もまだ学んでいる途中ですが、エラーバジェットを使い切ったときに何を止めるのかという運用そのものは、続きの記事で掘り下げました。
「99.9%」と「99.99%」で運用がどれだけ変わるかは、稼働率の桁を並べた記事で整理しています。
参考: Service Level Objectives – Site Reliability Engineering／Implementing SLOs – The Site Reliability Workbook
以上です。
コメントを残す