SLA / SLO / SLI

SLA / SLO / SLI とは

SRE (Site Reliability Engineering) の中核概念で、サービスの信頼性を定量的に管理するための 3 層の指標体系である。Google の SRE チームが体系化し、2016 年刊行の書籍「Site Reliability Engineering」(O'Reilly) で広く知られるようになった。同書は SLI を「提供しているサービス水準のある側面について、慎重に定義した定量的な尺度」と定め、SLO を 100% 満たし続けようとすることは非現実的で望ましくもない、と明言している。

指標	正式名称	定義	例
SLI	Service Level Indicator	信頼性を測定する具体的なメトリクス	リクエスト成功率、レイテンシ P99
SLO	Service Level Objective	SLI の目標値 (内部目標)	成功率 99.9%、P99 < 200ms
SLA	Service Level Agreement	顧客との契約上の保証	稼働率 99.95%、違反時は返金

3 つの関係

3 つは測定・目標・約束の順に積み上がる。下位が決まらないと上位は決められない。SLI を決めずに SLO を宣言すると、達成できたかどうかを誰も判定できない。

SLI (何を測るか) → SLO (どこまで目指すか) → SLA (何を約束するか)
  リクエスト成功率     99.9%                    99.95% (違反時10%返金)

SLO は SLA より厳しく設定する。SLO と SLA の差がバッファ (安全マージン) になる。ただし SLO を守れば契約違反を避けられると言い切れるのは、両者の測定方法と集計期間が揃っている場合だけだ。AWS の SLA は 5 分間隔ごとに可用性を出し、それを 1 か月分平均する方式で、秒単位の成功率で見ている自社の SLO とは分母が違う。契約側の定義を読んで、自分の計測をそちらに合わせておく。SLA なしで SLO だけを運用する組織も多い。社内サービスや初期段階のプロダクトでは、SLO のみで十分だ。

SLI の選び方

SLI は「ユーザーが体感する品質」を測定するメトリクスを選ぶ。サーバーの CPU 使用率やメモリ使用量は SLI に適さない。ユーザーにとって重要なのは「リクエストが成功したか」「応答が速かったか」だ。

サービス種別	推奨 SLI	測定方法
API サーバー	リクエスト成功率	5xx 以外のレスポンス / 全リクエスト
API サーバー	レイテンシ	P50, P99 のレスポンスタイム
バッチ処理	完了率	成功ジョブ / 全ジョブ
データパイプライン	鮮度	データの最終更新からの経過時間
ストレージ	耐久性	データ損失率

成功をどう数えるかは分母と分子の定義で決まる。Google の SRE ワークブックは、HTTP のステータスコードを基準に 5xx を SLO 違反として数え、それ以外は成功として扱う実装を示している。リダイレクトの 3xx やクライアント側の誤りである 4xx まで失敗に数えると、自分では直せない事象でエラーバジェットが減っていく。

エラーバジェット

SLO が 99.9% なら、30 日間で 0.1% (約 43 分) のダウンタイムが許容される。この「許容される失敗の量」がエラーバジェットだ。

月間エラーバジェット = 30日 × 24時間 × 60分 × (1 - SLO)

SLO 99.9%  → 43.2 分/月
SLO 99.95% → 21.6 分/月
SLO 99.99% → 4.3 分/月

ここでの「月」は 30 日換算だ。実際の請求サイクルは 28 日から 31 日まで変わるため、同じ SLO でも短い月と長い月では許容分数が 1 割ほど違う。SLA の判定期間に合わせて計算する。

エラーバジェットの運用ルールは明確にする。

• バジェットが残っている → 新機能のリリースを積極的に行う
• バジェットが枯渇 → リリースを凍結し、信頼性改善に集中する
• バジェットの消費速度が急上昇 → アラートを発火し、原因を調査する

この仕組みにより、「信頼性 vs 機能開発」のトレードオフが定量的に管理できる。開発チームと SRE チームの間で「もっと安定させろ」「もっと速くリリースしろ」という感情的な対立が解消される。

9 の数と実際のダウンタイム

「ナイン」の数が 1 つ増えるごとに、許容ダウンタイムは 10 分の 1 になる。

SLO	月間ダウンタイム (30 日換算)	年間ダウンタイム (365 日換算)	難易度
99% (ツーナイン)	7.2 時間	3.65 日	単一サーバーでも達成可能
99.9% (スリーナイン)	43.2 分	8.76 時間	冗長化が必要
99.95%	21.6 分	4.38 時間	マルチ AZ が必要
99.99% (フォーナイン)	4.3 分	52.6 分	自動フェイルオーバー必須
99.999% (ファイブナイン)	26 秒	5.26 分	マルチリージョン必須

99.99% と 99.999% の差は月間 4 分弱だが、達成に必要なアーキテクチャの複雑さとコストは桁違いに増える。ほとんどのサービスでは 99.9%〜99.95% が現実的な目標だ。

AWS サービスの SLA

AWS の主要サービスが公表している月間稼働率の保証水準は以下のとおり (2026 年 8 月時点)。自サービスの SLO を設定する際の参考になる。

• S3: 99.9% の可用性 (Standard)
• Lambda: 99.95% の可用性
• DynamoDB: 99.99% の可用性 (Standard)、99.999% (グローバルテーブル。リージョン内の全テーブルがグローバルテーブル構成で、可用性の問題が起きたときにフェイルオーバーを試みることが適用条件)
• CloudFront: 99.9% の可用性
• API Gateway: 99.95% の可用性

読み違えやすいのは、この数字が実測の可用性ではなく、下回ったら返金対象になる下限だという点だ。実測値は通常この水準より高いので、依存先の保証水準を上回る SLO を掲げること自体は不可能ではない。ただし上回るための仕組み (多重化・複数リージョン化・機能を落とした縮退運転) を自分で用意することになる。逆に、依存先の数字をそのまま自分の SLO に写すと、依存サービスが増えるほど計算上は届かなくなる。

よくある誤解

「SLO は高ければ高いほどよい」

SLO を 99.999% に設定すると、月間 26 秒しかダウンタイムが許されない。デプロイのたびにエラーバジェットが枯渇し、事実上リリースできなくなる。SLO はユーザーの期待に合わせて設定する。社内ツールに 99.999% は過剰だ。

「SLA = SLO」

SLA は契約であり、違反すると金銭的なペナルティが発生する。SLO は内部目標であり、違反してもペナルティはない (エラーバジェットの消費として扱う)。SLA は SLO より緩く設定し、バッファを持たせる。

SLO は一度決めて終わりにしない。苦情が来ていないのに毎月バジェットが余るなら目標が緩すぎるし、守れた月が一度もないなら現実の能力と合っていない。四半期ごとに実測値と照らして数字を動かす前提で運用する。