SLO・SLI・エラーバジェット
サービスレベルを数値で管理するSLI・SLOと、リリースの許容リスクを表すエラーバジェットの考え方を学ぶ
SLA・SLO・SLIの違い
この3つの略語は混同されがちですが、それぞれ役割が異なります。
SLI (Service Level Indicator, 実測指標)
実際に計測される数値そのもの。例: 成功したリクエストの割合、p99レイテンシ
SLO (Service Level Objective, 内部目標)
SLIに対してチームが定める内部の目標値。例: 「成功率を30日間で99.9%以上に保つ」
SLA (Service Level Agreement, 対外的な契約)
顧客との契約であり、違反すると返金などのペナルティを伴うことが多い。通常SLOより緩い基準を設定する
混同しないための整理
SLIは「測るもの」、SLOは「チームの目標」、SLAは「顧客との約束」です。 SLAはSLOより緩めに設定し、SLO違反がSLA違反に直結しないよう余裕を持たせるのが一般的です。
良いSLIの選び方
SLIは「ユーザー体験を代表する指標」であることが重要です。代表的な定義方法は有効なイベントのうち、良いイベントが占める割合として表す方法です。
SLI = 良いイベント数 / 有効なイベント数
例: 可用性のSLI
良いイベント = ステータスコードが5xx以外のレスポンス
有効なイベント = クライアントのネットワーク切断など計測対象外を除いた全リクエスト
例: レイテンシのSLI
良いイベント = 300ms以内に応答できたリクエスト
有効なイベント = タイムアウト設定内で処理された全リクエストエラーバジェットという考え方
SLOを99.9%と定めた場合、残りの0.1%はエラーバジェット(許容できる失敗の予算)として扱えます。100%を目指さず、あえて許容範囲を明示することで、 「信頼性を上げすぎて開発速度を犠牲にする」ことと「機能追加を優先して信頼性を犠牲にする」ことの バランスを、数値に基づいて意思決定できるようになります。
エラーバジェット = 100% - SLO
例: SLO = 99.9%(30日間) の場合
エラーバジェット = 0.1%
30日 = 43,200分 なので、許容ダウンタイムは約43.2分意思決定への活用
バジェットが十分残っていれば、多少リスクのある新機能のリリースやインフラの変更を積極的に進めます。 バジェットの消費が速い、あるいは枯渇が近い場合は、新機能のリリースを一時的に抑制し、 信頼性向上のための作業を優先するといった判断ができます。
バジェット枯渇時の運用(バーンレート)
エラーバジェットが「どれくらいの速さで消費されているか」をバーンレート(消費速度)と呼びます。 通常より速いペースで消費されている場合は、月末を待たずに早期にアラートを出すことで、 バジェットを使い切ってしまう前に対応できます。
# バーンレートアラートの考え方(概念)
alert: ErrorBudgetBurnRateHigh
condition: 直近1時間のエラー率が、30日バジェットを
6時間以内に使い切るペースで消費されている
action: オンコール担当に即時通知し、リリースを一時凍結ポイント
- SLIは実測値、SLOは内部目標、SLAは対外的な契約と役割を区別する
- SLIはユーザー体験を代表する「良いイベント÷有効なイベント」で定義するのが基本
- エラーバジェットは「100% - SLO」で、リリース可否などの意思決定に使う予算
- バーンレートを監視し、消費が速い時は早期にリリースを抑制する判断につなげる
確認クイズ
1 / 3SLI・SLO・SLAの関係として正しい説明はどれか？