メトリクス・SLO めとりくす・えすえるおー
簡単に言うとこんな感じ！
SLAは「契約書に書かれたサービスの最低保証ライン」。SLOはその内側にある「自分たちがこれを守ろうと設定した目標値」だよ。SLOが「99.9%の可用性を目標にしよう」でSLAが「99.5%を下回らないことを保証します」みたいな感じ。SLOを守ることでSLAを余裕を持って達成できるんだ！
メトリクス・SLOとは
メトリクス（Metrics）とは、システムの状態を数値で表した時系列データです。リクエスト数・エラー率・レイテンシ・CPU使用率・ディスクI/Oなど、サービスの健全性を継続的に計測します。PrometheusやDatadogなどのツールで収集し、Grafana等で可視化します。
SLO（Service Level Objective：サービスレベル目標）とは、「私たちはこのサービスをどのくらいの品質で提供することを目標にするか」という内部目標値です。「月間可用性99.9%」「P99レイテンシ200ms以下」などと定義します。SLOの測定基準となる個々のメトリクスをSLI（Service Level Indicator：サービスレベル指標）と呼びます。
SLAとSLO・SLIの3つは混同されがちですが、役割が異なります。SLA（Service Level Agreement）はユーザー・顧客との契約であり、違反すると返金やペナルティが発生します。SLOはSLAより厳しい内部目標として設定し、余裕（エラーバジェット）を持って運用します。
SLA・SLO・SLIの関係
| 用語 | 定義主体 | 対象 | 違反した場合 |
|---|---|---|---|
| SLA（契約） | 顧客との合意 | 外部向け最低保証 | 返金・ペナルティ・信頼損失 |
| SLO（目標） | 内部チーム | 内部目標値 | エラーバジェット消費 |
| SLI（指標） | エンジニアリング | 測定する具体的な数値 | — |
エラーバジェットとは
SLOが「月間可用性99.9%」の場合、1ヶ月（30日）のうち許容できるダウンタイムは30日 × 0.1% = 43.2分です。この43.2分がエラーバジェットです。バジェットが残っている間は積極的なリリースができますが、バジェットを使い切ると新機能リリースを停止して信頼性改善を優先します。
歴史と背景
- 2003年：GoogleがSRE（Site Reliability Engineering）の概念を社内で発展させ、SLO・SLI・SLAの3層モデルを確立
- 2016年：GoogleのSRE Bookが公開。SLO・エラーバジェットの概念が業界全体に普及
- 2018年：Prometheus + Grafanaを使ったSLO監視のオープンソース実装が充実し、エンタープライズ採用が加速
- 2019年：Google CloudがSLO Monitoringをマネージドサービスとして提供開始
- 2021年〜：OpenSLOという宣言的SLO定義のOSS標準が登場。ベンダー中立なSLO管理が可能に
- 2023年〜：SLO-based Progressive Delivery（SLOを条件にカナリアの進行判断を自動化）が標準化
SLO・エラーバジェットのイメージ
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| OpenSLO v1.0 | SLOをYAMLで宣言的に定義するベンダー中立な仕様 |
| Prometheus Data Model | メトリクスの時系列データモデルのデファクト標準 |
関連用語
- オブザーバビリティ — メトリクスはオブザーバビリティの3本柱の一つ
- 分散トレーシング — レイテンシのP99/P999がSLIとして使われることが多い
- ログ集約 — エラーログの数をカウントしてエラー率SLIとして使用する
- カナリアリリース — SLOベースのカナリア進行判断で自動ロールバックを実現
- SRE — SREがSLO・エラーバジェットを設計・運用し、信頼性とリリース速度のバランスを取る
- カオスエンジニアリング — 意図的障害時にエラーバジェットがどのくらい消費されるかを確認する実験
- CI/CDパイプライン — DORA MetricsはCI/CDの成熟度を測るSLI/SLOの一種