ストーリー
田
田中VPoE
SRE組織のミッションを定義した。素晴らしい。だが「信頼性を向上させる」と言っても、測れないものは改善できない。ここからは信頼性の定量化に入る
あなた
SLI/SLOですね。名前は聞いたことがありますが、SLAとの違いがいまいち…
あ
田
田中VPoE
いい。その混乱は多くの組織で起きている。SLA、SLO、SLI — この3つの関係を正しく理解することが、エラーバジェットポリシーの土台になる
あなた
3つの概念を明確に区別できるようにします
あ
田
田中VPoE
加えて、「何を測るか」の選び方が最も重要だ。間違ったSLIを選ぶと、数値上は問題ないのにユーザーは不満、という悲惨な状態になる
SLA・SLO・SLIの関係
3つの概念
| 概念 | 正式名 | 定義 | 対象 |
|---|---|---|---|
| SLI | Service Level Indicator | サービスの信頼性を測定する指標 | エンジニアリングチーム |
| SLO | Service Level Objective | SLIに対する目標値 | エンジニアリング + ビジネス |
| SLA | Service Level Agreement | 顧客との契約上の保証値 | ビジネス + 法務 + 顧客 |
関係の構造
SLI（何を測るか）
↓ 目標値を設定
SLO（どの水準を目指すか）
↓ 外部への約束として公開
SLA（破ったらどうなるか）
例:
SLI: API応答時間の99パーセンタイル
SLO: 99パーセンタイルが500ms以下であること、月間99.9%
SLA: 月間可用性99.9%を保証、違反時はクレジット返還重要な関係
| ルール | 説明 |
|---|---|
| SLO > SLA | SLOはSLAより厳しく設定する（バッファ） |
| SLI → SLO | まずSLIを決め、次にSLOを設定する |
| SLO ≠ 100% | 100%のSLOは間違い。コストが無限大になる |
SLIの設計
SLIの4つのカテゴリ
| カテゴリ | 説明 | 代表的なSLI |
|---|---|---|
| 可用性（Availability） | サービスが利用可能か | 成功リクエスト数 / 総リクエスト数 |
| レイテンシ（Latency） | 応答の速さ | リクエストの99パーセンタイル応答時間 |
| スループット（Throughput） | 処理能力 | 1秒あたりの処理リクエスト数 |
| 正確性（Correctness） | 結果の正しさ | 正しい結果を返したリクエスト / 総リクエスト |
サービスタイプ別の推奨SLI
| サービスタイプ | 最重要SLI | 次に重要なSLI |
|---|---|---|
| ユーザー向けWebアプリ | 可用性 + レイテンシ | スループット |
| API | 可用性 + レイテンシ | 正確性 |
| データパイプライン | 正確性 + 鮮度（Freshness） | スループット |
| ストレージシステム | 可用性 + 耐久性 | レイテンシ |
良いSLIの条件
| 条件 | 良い例 | 悪い例 |
|---|---|---|
| ユーザー体験を反映 | ページ読み込み完了まで2秒以内の割合 | サーバーCPU使用率 |
| 測定可能 | HTTPステータス200の割合 | 「ユーザー満足度」 |
| シンプル | 成功リクエスト / 総リクエスト | 5つの指標の加重平均 |
| 比率で表現 | 99パーセンタイル ≤ 500ms の割合 | 平均応答時間 |
平均値は嘘をつく。99パーセンタイルの応答時間が10秒でも、平均が200msなら「平均200ms」と報告される。SLIには必ずパーセンタイルを使う。
SLOの設計
SLO設定のプロセス
1. ユーザーの期待を理解する
└── ユーザーインタビュー、サポート問い合わせ分析
2. 現状のパフォーマンスを計測する（ベースライン）
└── 過去30日のSLIデータを収集
3. ビジネス要件を確認する
└── 既存SLA、競合サービスの水準
4. SLO値を設定する
└── 現実的かつ意味のある目標値
5. エラーバジェットを計算する
└── 100% - SLO = エラーバジェット
6. 運用して調整する
└── 四半期ごとにSLOの妥当性をレビューSLOの具体例
| サービス | SLI | SLO | エラーバジェット（30日） |
|---|---|---|---|
| Webアプリ | 可用性 | 99.9% | 43.2分のダウンタイム |
| Webアプリ | レイテンシ | P99 ≤ 500ms（99.5%） | 0.5%のリクエストが超過可能 |
| 決済API | 可用性 | 99.99% | 4.32分のダウンタイム |
| 検索API | レイテンシ | P99 ≤ 200ms（99%） | 1%のリクエストが超過可能 |
| データパイプライン | 鮮度 | データ遅延 ≤ 5分（99.9%） | 月43.2分の遅延許容 |
可用性の9の数
| SLO | ダウンタイム（年間） | ダウンタイム（月間） | 適用例 |
|---|---|---|---|
| 99%（ツーナイン） | 3.65日 | 7.3時間 | 社内ツール |
| 99.9%（スリーナイン） | 8.77時間 | 43.2分 | 一般的なWebサービス |
| 99.95% | 4.38時間 | 21.6分 | ECサイト |
| 99.99%（フォーナイン） | 52.6分 | 4.32分 | 決済システム |
| 99.999%（ファイブナイン） | 5.26分 | 25.9秒 | 医療・航空 |
まとめ
| ポイント | 内容 |
|---|---|
| SLI/SLO/SLA | 測定指標 → 目標値 → 顧客契約の3層構造 |
| SLIの選び方 | ユーザー体験を反映し、パーセンタイルで表現する |
| SLOの原則 | 100%は間違い。ビジネスに必要な水準を現実的に設定する |
チェックリスト
- SLI、SLO、SLAの違いを説明できる
- サービスタイプに応じたSLIを選定できる
- 可用性の9の数とダウンタイムの関係を理解した
次のステップへ
次は「エラーバジェットの考え方」です。SLOから導かれるエラーバジェットの概念と、それを組織の意思決定にどう活用するかを学びましょう。
推定読了時間: 30分