はじめに
「可用性 99.9% を目標にしています」。
この一言だけで運用品質を管理しようとすると、必ずつまずきます。
- 99.9% って月に何分ダウンしていいの？
- 障害が起きたとき、どこまでリリースを止めるべき？
- 「品質を上げろ」と「機能を早く出せ」のどちらを優先すればいい？
これらの問いに答えるのが SLO（Service Level Objective） と Error Budget の考え方です。
Google の SRE チームが実践してきた手法を、実務で使える形に整理します。
SLA・SLO・SLI の違いを整理する
3 つの用語は混同されがちですが、役割がまったく異なります。
| 用語 | 正式名称 | 役割 | 対象 |
|---|---|---|---|
| SLI | Service Level Indicator | 品質を測る指標 | エンジニアが観測 |
| SLO | Service Level Objective | SLI の目標値 | チームが設定・管理 |
| SLA | Service Level Agreement | SLO を元にした契約 | ユーザーや顧客と締結 |
具体例で整理すると次のとおりです。
SLI：過去 30 日間の HTTP リクエストの成功率 → 現在 99.92%
SLO：成功率を 99.9% 以上に保つ
SLA：99.9% を下回った場合は料金を返金する
SLO は SLA より少し厳しく設定するのが一般的です。
SLO を守ることで SLA 違反を防ぐバッファになります。
Error Budget とは
Error Budget（エラーバジェット）は「SLO を守りながら許容できる失敗の量」です。
Error Budget = 100% - SLO の目標値
SLO を 99.9% に設定した場合、エラーバジェットは 0.1% です。
30 日間に換算すると次のようになります。
| SLO | Error Budget | 30 日あたりの許容ダウンタイム |
|---|---|---|
| 99% | 1% | 約 7 時間 12 分 |
| 99.9% | 0.1% | 約 43 分 |
| 99.95% | 0.05% | 約 21 分 |
| 99.99% | 0.01% | 約 4 分 |
エラーバジェットは「どれだけ信頼性を犠牲にできるか」の上限です。
残高がある間は積極的にリリースや実験ができ、残高を使い果たしたら品質改善に集中する、という判断基準になります。
SLI の選び方
SLI は「ユーザー体験を正確に反映した指標」を選ぶことが重要です。
よく使われる 3 種類を紹介します。
可用性（Availability）
リクエストのうち成功したものの割合です。
最も一般的な SLI です。
可用性 SLI = 成功リクエスト数 ÷ 総リクエスト数
例：1,000 リクエスト中 999 件が 2xx → 99.9%
「成功」の定義を明確にすることが大切です。
500 エラーは失敗として数えるが、429（Rate Limit）はカウントしない、といった判断が必要です。
レイテンシ（Latency）
リクエストの応答時間です。
平均値ではなくパーセンタイル（p99 や p95 など）で測ります。
レイテンシ SLI = p99 レイテンシが 500ms 以下のリクエストの割合
例：1,000 件中 990 件が 500ms 以下 → 99%
平均値は外れ値に引きずられるため、「99% のユーザーが X ms 以内に応答を受け取る」という形で設定します。
エラー率（Error Rate）
5xx 系エラーの割合です。
可用性 SLI と似ていますが、「部分的な失敗」を捉えやすい特徴があります。
SLO の数値をどう決めるか
SLO の数値は「高ければ高いほど良い」ではありません。
ユーザーが気づく閾値から逆算するのが基本です。
たとえば、レイテンシが 200ms でも 300ms でもユーザーが体感的に違いを感じないなら、SLO を 200ms にしても意味はありません。
また、SLO を高くするほどエラーバジェットが少なくなり、リリースの頻度を下げる必要が生まれます。
| SLO が高すぎると… | SLO が低すぎると… |
|---|---|
| エラーバジェットが枯渇しやすい | 品質の低下に気づきにくい |
| 機能開発が止まる | ユーザー満足度が下がる |
| エンジニアが常に緊張状態 | SLA 違反リスクが上がる |
現状の実績を測定してから SLO を設定するのが現実的です。
いきなり 99.99% を掲げるよりも、現在の実態が 99.7% なら、まず 99.5% から始めて段階的に引き上げる方が健全です。
Error Budget ポリシー
エラーバジェットは数値を見るだけでなく、残量に応じてチームの行動を変えるルールを決めることで初めて機能します。
| Error Budget 残量 | アクション |
|---|---|
| 50% 以上 | 通常どおり。機能開発・リリースを継続 |
| 50% 未満 | 注意フェーズ。障害の根本原因分析を優先 |
| 10% 未満 | リリース凍結。信頼性改善作業に集中 |
| 0%（枯渇） | 緊急対応。新機能開発を停止し、すべての力を可用性回復に |
このポリシーをチームとして合意しておくことで、「もっとリリースを速くしろ」と「品質を落とすな」という対立を、エラーバジェットの残量という共通言語で解決できます。
Google Cloud の主要サービス SLA
SLO を設定するとき、依存するサービスの SLA が事実上の上限になるという点を忘れてはなりません。
どれほど高い目標を掲げても、利用するクラウドサービス自体の SLA を超えることはできないからです。
以下は Google Cloud の主要サービスの公式 SLA です。
| サービス | SLA | 備考 |
|---|---|---|
| Cloud Spanner | 99.999% | マルチリージョン構成 |
| Firestore | 99.999% / 99.99% | マルチリージョン / リージョナル |
| BigQuery | 99.99% | — |
| GKE（Google Kubernetes Engine） | 99.95% | — |
| Cloud Run | 99.95% | — |
| Cloud SQL | 99.95% | — |
| Cloud Run Functions | 99.95% | — |
SLO の上限は依存サービスの SLA
「99.99% の可用性を目指す」と決めても、Cloud Run（SLA 99.95%）を使っている時点で、理論上の上限は 99.95% です。
依存するサービスの SLA を確認してから SLO を設定するのが現実的なアプローチです。
複数サービスを組み合わせると可用性が下がる
複数のサービスを直列に組み合わせると、全体の可用性はそれぞれの積になります。
例：Cloud Run（99.95%）× Cloud SQL（99.95%）の組み合わせ
0.9995 × 0.9995 ≈ 0.999 = 99.9%
Cloud Run と Cloud SQL を使うアプリの可用性は、単純計算で 99.9% 程度になります。
これを踏まえると、SLO を 99.95% に設定しても達成は難しく、99.9% が現実的な目標値です。
こうした計算を事前に行っておくことで、「なぜこの SLO にしたのか」をチームや利害関係者に説明できる根拠になります。
まとめ：SLO 設計の 5 ステップ
- SLI を決める：ユーザー体験を最もよく反映する指標を選ぶ（可用性、レイテンシ、エラー率）
- 依存サービスの SLA を確認する：使うサービスの SLA を洗い出し、複数サービスの積で現実的な上限を計算する
- 現状を測定する：SLO を設定する前に、実績値を 4 週間以上計測する
- SLO を設定する：現状より少し厳しい値から始め、段階的に引き上げる
- Error Budget ポリシーを決める：残量に応じてチームが取るべきアクションをあらかじめ合意する
SLO と Error Budget は「品質を測る」だけでなく、開発速度と信頼性のバランスをチームで合意するための共通言語です。
数値目標を掲げるだけでなく、エラーバジェットの残量に応じてチームの優先度を変えるポリシーまで決めることで、初めて機能します。