SLI/SLOの設計

ストーリー

「『サービスが遅い』と言われたとき、何を基準に『遅い』と判断する？」

松本先輩が問いかけた。

「えーと......なんとなく体感で......」

「それではダメだ。SLI と SLO を定義すれば、サービスの信頼性を数値で議論できるようになる。『感覚』ではなく『データ』で品質を語れるようになろう」

SLI / SLO / SLA の関係

┌────────────────────────────────────────────┐
│                                            │
│  SLI (Service Level Indicator)             │
│    = 何を測るか（指標）                    │
│    例: リクエストの99パーセンタイル         │
│        レイテンシが200ms以下の割合          │
│                                            │
│  SLO (Service Level Objective)             │
│    = どこまでを許容するか（目標）          │
│    例: 99.9% のリクエストが200ms以内       │
│                                            │
│  SLA (Service Level Agreement)             │
│    = 顧客との契約（約束）                  │
│    例: 可用性99.9%を下回った場合、         │
│        翌月の利用料を10%返金               │
│                                            │
│  関係:  SLI で測定 → SLO で目標設定        │
│         → SLA で契約                       │
│                                            │
│  SLO は常に SLA より厳しく設定する         │
│  （SLA 違反前に気づいて対処するため）      │
│                                            │
└────────────────────────────────────────────┘

SLI の設計

代表的な SLI の種類

SLI	定義	計算方法
可用性（Availability）	リクエストが正常に処理された割合	成功レスポンス / 全リクエスト
レイテンシ（Latency）	レスポンス時間が閾値以内の割合	200ms以内のリクエスト / 全リクエスト
スループット（Throughput）	単位時間あたりの処理量	リクエスト数 / 秒
エラー率（Error Rate）	エラーレスポンスの割合	5xx レスポンス / 全リクエスト
正確性（Correctness）	正しい結果を返した割合	正確なレスポンス / 全リクエスト

SLI の選び方

ユーザーにとって何が重要か？ から考える

Webアプリケーション:
├── ページが表示されるか → 可用性
├── ページの表示速度 → レイテンシ
└── エラーが出ないか → エラー率

APIサービス:
├── APIが応答するか → 可用性
├── レスポンスタイム → レイテンシ
├── 正しいデータが返るか → 正確性
└── レート制限に引っかからないか → スループット

データパイプライン:
├── 処理が完了するか → 完了率
├── データが正しいか → 正確性
└── 処理時間 → レイテンシ（鮮度）

SLO の設計

SLO の例

ECサイトの SLO 例:

1. 可用性 SLO
   SLI: HTTP 200-499 レスポンスの割合
   SLO: 30日間で 99.9% 以上

2. レイテンシ SLO
   SLI: レスポンスタイムの p99
   SLO: p99 が 500ms 以内を 99% の時間維持

3. エラー率 SLO
   SLI: HTTP 5xx レスポンスの割合
   SLO: 30日間で 0.1% 以下

SLO の設定手順

1. ユーザージャーニーを特定する
   → 「ユーザーが商品を検索して購入する」

2. 各ステップで重要な指標を選ぶ
   → 検索: レイテンシ
   → 商品表示: 可用性
   → 決済: 可用性 + 正確性

3. 現在のパフォーマンスを測定する
   → 過去30日のデータを収集

4. 目標値を設定する
   → 現在の実績よりやや高い値
   → ビジネス要件を考慮

5. 計測期間（ウィンドウ）を決める
   → 30日間のローリングウィンドウが一般的

SLO の計測ウィンドウ

ウィンドウ	特徴	使い所
30日ローリング	直近30日を常に計算	最も一般的
カレンダー月	月初から月末まで	月次レポート
四半期	3ヶ月間	経営報告

実践：SLO ドキュメントの例

yaml

# SLO ドキュメント: ECサイト注文API

service: order-api
owner: order-team
last_updated: 2024-01-15

slos:
  - name: "注文API可用性"
    sli:
      type: availability
      description: "HTTP ステータスコード 200-499 のレスポンス割合"
      good_events: "HTTP status < 500"
      total_events: "全HTTPリクエスト"
    target: 99.9%
    window: 30d
    consequence: "SLO違反時は機能リリースを凍結し、信頼性改善に注力"

  - name: "注文APIレイテンシ"
    sli:
      type: latency
      description: "p99レスポンスタイム"
      threshold: 500ms
    target: 99%
    window: 30d
    consequence: "SLO違反時はパフォーマンス改善タスクを最優先"

  - name: "決済処理正確性"
    sli:
      type: correctness
      description: "決済金額が注文金額と一致する割合"
    target: 99.99%
    window: 30d
    consequence: "SLO違反時は決済システムの緊急レビュー"

SLI の計測方法

計測ポイント:

ユーザー    ロードバランサー    アプリケーション     DB
  │              │                   │              │
  │   ←─────────→│                   │              │
  │   フロントSLI │   ←──────────────→│              │
  │              │   バックエンドSLI   │   ←────────→│
  │              │                   │   DB SLI      │
  │                                  │              │

推奨: ユーザーに最も近い位置で計測する
  → ロードバランサーのアクセスログ
  → リアルユーザーモニタリング（RUM）

まとめ

項目	ポイント
SLI	何を測るか（指標）
SLO	どこまで許容するか（目標）
SLA	顧客との契約（SLO より緩く設定）
設計手順	ユーザージャーニー → 指標選定 → 測定 → 目標設定
計測	ユーザーに近い位置で計測する

チェックリスト

SLI / SLO / SLA の違いを説明できる
代表的なSLI（可用性、レイテンシ、エラー率）を理解した
SLO の設定手順を説明できる
SLO ドキュメントを作成できる
SLI の計測ポイントの考え方を理解した

次のステップへ

SLI/SLO の設計を学んだら、次はエラーバジェットの運用方法を学びます。SLO と密接に関連するこの概念を理解しましょう。

推定読了時間: 30分