SLO/SLI 2025 - 信頼性目標駆動の運用

2026.01.12

SLOSLISRE信頼性

信頼性エンジニアリングの新時代

2025年、SLO（Service Level Objective）とSLI（Service Level Indicator）を中心とした信頼性管理は、もはや大規模テック企業だけのものではありません。Google SREの哲学が広く浸透し、85%以上の企業がSLOベースの運用を導入または検討しています。本記事では、SLO/SLI駆動の運用における最新のベストプラクティスと2025年の動向を詳しく解説します。

SLO/SLI/SLAの定義と関係

3つの概念の明確な違い

┌─────────────────────────────────────────────────────────┐
│                 信頼性指標の階層構造                      │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  SLA (Service Level Agreement)                          │
│  └── 顧客との契約・法的拘束力                            │
│      └── 違反時のペナルティ（返金等）                     │
│                                                         │
│  SLO (Service Level Objective)                          │
│  └── 内部目標・チームのコミットメント                     │
│      └── SLAより厳しい値を設定                           │
│                                                         │
│  SLI (Service Level Indicator)                          │
│  └── 測定可能な具体的指標                                │
│      └── SLOの達成度を判定                               │
│                                                         │
└─────────────────────────────────────────────────────────┘

SLI（Service Level Indicator）

SLIはサービスの品質を測定する定量的な指標です。

# 代表的なSLI定義
sli_definitions:
  availability:
    description: "正常に応答したリクエストの割合"
    formula: "successful_requests / total_requests"
    good_event: "HTTP status < 500"

  latency:
    description: "レスポンスタイムの分布"
    formula: "requests_under_threshold / total_requests"
    threshold: "300ms"
    percentile: "p99"

  throughput:
    description: "処理可能なリクエスト数"
    formula: "requests_per_second"
    measurement_window: "1 minute"

  error_rate:
    description: "エラーとなったリクエストの割合"
    formula: "error_requests / total_requests"
    error_definition: "HTTP 5xx responses"

SLO（Service Level Objective）

SLOはSLIに対する目標値です。

# SLO設定例
service: payment-api
slos:
  - name: availability
    target: 99.95%
    window: 30d
    description: "決済APIは月間99.95%の可用性を維持"

  - name: latency_p99
    target: 99%
    threshold: 200ms
    window: 30d
    description: "99%のリクエストが200ms以内に応答"

  - name: latency_p50
    target: 99%
    threshold: 50ms
    window: 30d
    description: "中央値のレイテンシは50ms以内"

SLA（Service Level Agreement）

SLAは顧客との契約であり、違反時のペナルティが伴います。

# SLA定義例（顧客向け契約）
sla:
  service: Enterprise API
  effective_date: "2025-01-01"

  commitments:
    - metric: availability
      target: 99.9%
      measurement_period: monthly

  penalties:
    - availability_range: "99.0% - 99.9%"
      service_credit: 10%
    - availability_range: "95.0% - 99.0%"
      service_credit: 25%
    - availability_range: "< 95.0%"
      service_credit: 50%

  exclusions:
    - scheduled_maintenance
    - force_majeure
    - customer_caused_issues

エラーバジェットの運用

エラーバジェットとは

エラーバジェットは「許容できるダウンタイム」を定量化したものです。

99.9% SLOの場合（30日間）:
許容ダウンタイム = 30日 × 24時間 × 60分 × (1 - 0.999)
                 = 43.2分/月

99.95% SLOの場合（30日間）:
許容ダウンタイム = 30日 × 24時間 × 60分 × (1 - 0.9995)
                 = 21.6分/月

99.99% SLOの場合（30日間）:
許容ダウンタイム = 30日 × 24時間 × 60分 × (1 - 0.9999)
                 = 4.32分/月

エラーバジェットポリシー

# エラーバジェットポリシー設定
error_budget_policy:
  service: user-authentication
  slo_target: 99.95%
  window: 30d

  thresholds:
    healthy:
      remaining: "> 50%"
      actions:
        - continue_normal_development
        - allow_risky_deployments
        - experimentation_permitted

    warning:
      remaining: "25% - 50%"
      actions:
        - increase_deployment_scrutiny
        - prioritize_reliability_work
        - reduce_change_velocity

    critical:
      remaining: "< 25%"
      actions:
        - freeze_non_critical_deployments
        - all_hands_on_reliability
        - mandatory_postmortem_review

    exhausted:
      remaining: "0%"
      actions:
        - complete_deployment_freeze
        - incident_response_mode
        - executive_escalation

バーンレート（消費速度）の監視

# Prometheusでのバーンレート計算
groups:
  - name: slo_burn_rate
    rules:
      # 1時間のバーンレート
      - record: slo:error_budget_burn_rate:1h
        expr: |
          1 - (
            sum(rate(http_requests_total{status!~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          )
          /
          (1 - 0.9995)  # SLO target

      # 6時間のバーンレート
      - record: slo:error_budget_burn_rate:6h
        expr: |
          1 - (
            sum(rate(http_requests_total{status!~"5.."}[6h]))
            /
            sum(rate(http_requests_total[6h]))
          )
          /
          (1 - 0.9995)

SLO設定のベストプラクティス

ユーザージャーニーベースのSLO

# ユーザージャーニーに基づくSLO設計
user_journeys:
  checkout_flow:
    description: "商品購入フロー全体"
    critical_path:
      - step: add_to_cart
        sli: latency_p99
        target: 99.9%
        threshold: 500ms

      - step: view_cart
        sli: availability
        target: 99.95%

      - step: payment_processing
        sli: latency_p99
        target: 99.99%
        threshold: 3000ms

      - step: order_confirmation
        sli: availability
        target: 99.9%

    composite_slo:
      target: 99.5%
      calculation: "product of individual SLOs"

段階的なSLO導入

Phase 1: 測定の確立（1-2ヶ月）
├── 基本的なSLIの計測開始
├── ダッシュボードの構築
└── ベースラインの把握

Phase 2: 目標の設定（2-3ヶ月）
├── 過去データに基づくSLO設定
├── ステークホルダーとの合意
└── エラーバジェットの導入

Phase 3: 運用の成熟（3-6ヶ月）
├── アラート戦略の最適化
├── ポリシーの自動化
└── 継続的な見直しサイクル

SLO設定のアンチパターン

# 避けるべきパターン
antipatterns:
  too_aggressive:
    bad: "99.999%（Five Nines）を最初から目指す"
    why: "現実的でなく、チームを疲弊させる"
    better: "99.9%から始めて段階的に向上"

  too_many_slos:
    bad: "20以上のSLOを同時に管理"
    why: "焦点が分散し、どれも達成できない"
    better: "重要な3-5個のSLOに集中"

  vanity_metrics:
    bad: "サーバーCPU使用率をSLIに"
    why: "ユーザー体験と直接関係しない"
    better: "ユーザー視点の指標を選択"

  static_targets:
    bad: "一度設定したら変更しない"
    why: "ビジネス要件は変化する"
    better: "四半期ごとに見直し"

主要ツールとプラットフォーム

Nobl9 - SLOプラットフォーム

# Nobl9 SLO定義
apiVersion: n9/v1alpha
kind: SLO
metadata:
  name: api-availability
  project: production
spec:
  description: "API可用性SLO"
  service: api-gateway
  indicator:
    metricSource:
      name: prometheus
      project: production
      kind: Agent
    ratioMetric:
      counter: true
      good:
        prometheus:
          promql: sum(rate(http_requests_total{status!~"5.."}[5m]))
      total:
        prometheus:
          promql: sum(rate(http_requests_total[5m]))
  budgetingMethod: Occurrences
  objectives:
    - displayName: "99.95% 可用性"
      target: 0.9995
      timeSliceTarget: 0.95
      op: gte
  timeWindow:
    - duration: 720h  # 30日
      isRolling: true
  alertPolicies:
    - fast-burn-alert
    - slow-burn-alert

Dynatrace - AI駆動のオブザーバビリティ

# Dynatrace SLO設定
slo:
  name: "Frontend Response Time"
  enabled: true
  evaluationType: "AGGREGATE"
  filter: "type(\"SERVICE\") AND entityName.equals(\"frontend-service\")"

  metricExpression: |
    (100) * (
      builtin:service.response.time:splitBy():avg:auto:sort(value(avg,descending)):limit(100):fold
      <= 200000  # 200ms in microseconds
    )

  target: 99.0
  warning: 99.5

  timeframe: "-30d"

  errorBudgetBurnRate:
    fastBurnThreshold: 10
    slowBurnThreshold: 2

Datadog - SLOモニタリング

# Datadog SLO定義
resource "datadog_service_level_objective" "api_latency" {
  name = "API Latency SLO"
  type = "metric"

  query {
    numerator   = "sum:trace.http.request.hits{service:api-gateway,resource_name:GET_/api/users}.as_count()"
    denominator = "sum:trace.http.request.hits{service:api-gateway,resource_name:GET_/api/users}.as_count()"
  }

  thresholds {
    timeframe = "30d"
    target    = 99.9
    warning   = 99.95
  }

  tags = ["service:api-gateway", "team:platform", "env:production"]
}

Google Cloud SLO Monitoring

# Google Cloud Monitoring SLO
resource "google_monitoring_slo" "api_slo" {
  service      = google_monitoring_custom_service.api.service_id
  display_name = "API Availability SLO"

  goal                = 0.999
  rolling_period_days = 30

  request_based_sli {
    good_total_ratio {
      good_service_filter = join(" AND ", [
        "metric.type=\"loadbalancing.googleapis.com/https/request_count\"",
        "resource.type=\"https_lb_rule\"",
        "metric.labels.response_code_class!=\"500\""
      ])
      total_service_filter = join(" AND ", [
        "metric.type=\"loadbalancing.googleapis.com/https/request_count\"",
        "resource.type=\"https_lb_rule\""
      ])
    }
  }
}

OpenSLO - オープン標準

# OpenSLO仕様（ベンダー非依存）
apiVersion: openslo/v1
kind: SLO
metadata:
  name: api-availability-slo
  displayName: "API Availability"
spec:
  description: "Measures the availability of the API"
  service: api-gateway
  indicator:
    metadata:
      name: api-availability-ratio
    spec:
      ratioMetric:
        counter: true
        good:
          metricSource:
            type: Prometheus
            spec:
              query: sum(rate(http_requests_total{code!~"5.."}[5m]))
        total:
          metricSource:
            type: Prometheus
            spec:
              query: sum(rate(http_requests_total[5m]))
  objectives:
    - displayName: "99.9% over 30 days"
      target: 0.999
      timeSliceWindow: 5m
  timeWindow:
    - duration: 30d
      isRolling: true

アラート戦略

マルチウィンドウ・マルチバーンレートアラート

# Google SRE推奨のアラート戦略
alerting_strategy:
  # 高速バーン（急激な劣化検出）
  fast_burn:
    short_window: 5m
    long_window: 1h
    burn_rate_threshold: 14.4  # 2%のバジェットを1時間で消費
    severity: critical

  # 中速バーン
  medium_burn:
    short_window: 30m
    long_window: 6h
    burn_rate_threshold: 6
    severity: warning

  # 低速バーン（緩やかな劣化検出）
  slow_burn:
    short_window: 2h
    long_window: 24h
    burn_rate_threshold: 3
    severity: info

Prometheusアラートルール実装

groups:
  - name: slo-alerts
    rules:
      # 高速バーン - Critical
      - alert: HighErrorBudgetBurn
        expr: |
          (
            slo:error_budget_burn_rate:5m > 14.4
            and
            slo:error_budget_burn_rate:1h > 14.4
          )
        for: 2m
        labels:
          severity: critical
          team: sre
        annotations:
          summary: "High error budget burn rate detected"
          description: |
            Service {{ $labels.service }} is burning error budget at
            {{ $value }}x the sustainable rate.
            At this rate, the monthly budget will be exhausted in
            {{ printf "%.1f" (div 100 $value) }} hours.
          runbook_url: "https://runbooks.example.com/slo-burn"

      # 中速バーン - Warning
      - alert: ElevatedErrorBudgetBurn
        expr: |
          (
            slo:error_budget_burn_rate:30m > 6
            and
            slo:error_budget_burn_rate:6h > 6
          )
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Elevated error budget consumption"
          description: |
            Service {{ $labels.service }} error budget burn rate is elevated.

      # 低速バーン - Info（長期的傾向）
      - alert: SustainedErrorBudgetBurn
        expr: |
          (
            slo:error_budget_burn_rate:2h > 3
            and
            slo:error_budget_burn_rate:24h > 3
          )
        for: 1h
        labels:
          severity: info
        annotations:
          summary: "Sustained error budget consumption detected"

アラート疲れを防ぐ設計

# アラート最適化ポリシー
alert_hygiene:
  principles:
    - actionable: "すべてのアラートに対応アクションが必要"
    - relevant: "ユーザー影響があるものだけ"
    - timely: "適切なタイミングで通知"
    - prioritized: "重要度に応じたルーティング"

  noise_reduction:
    grouping:
      - group_by: [service, environment]
        group_wait: 30s
        group_interval: 5m

    inhibition:
      - source: critical
        target: warning
        equal: [service]

    silencing:
      maintenance_windows: true
      deployment_periods: true

2025年の動向とトレンド

AI/ML駆動のSLO管理

# AI支援SLO最適化
ai_slo_features:
  anomaly_detection:
    description: "通常パターンからの逸脱を自動検出"
    capabilities:
      - seasonal_adjustment
      - trend_analysis
      - outlier_detection

  predictive_alerts:
    description: "バジェット枯渇を事前予測"
    lead_time: "4-24時間前に警告"

  auto_remediation:
    description: "自動修復アクションの実行"
    actions:
      - scale_up_resources
      - traffic_shift
      - rollback_deployment

  slo_recommendation:
    description: "過去データから最適なSLO値を提案"
    factors:
      - historical_performance
      - business_impact
      - cost_considerations

Platform Engineering統合

# プラットフォームエンジニアリングとSLO
platform_slo_integration:
  internal_developer_platform:
    self_service_slo:
      - "開発者がSLOを自分で定義・管理"
      - "テンプレートベースの設定"
      - "自動ダッシュボード生成"

  golden_paths:
    default_slos:
      web_service:
        availability: 99.9%
        latency_p99: 500ms
      api_service:
        availability: 99.95%
        latency_p99: 200ms
      background_job:
        success_rate: 99.5%
        processing_time_p99: 30s

FinOpsとSLOの融合

# コスト効率を考慮したSLO
finops_slo_alignment:
  cost_per_nine:
    "99.9%": "$10,000/month"
    "99.95%": "$25,000/month"
    "99.99%": "$100,000/month"

  optimization_strategy:
    - "ビジネス価値に見合ったSLOレベル"
    - "過剰な信頼性投資の回避"
    - "SLO達成コストの可視化"

  dynamic_slo:
    peak_hours:
      availability: 99.99%
      resources: high
    off_peak:
      availability: 99.9%
      resources: optimized

分散システムにおけるSLO

# マイクロサービスのSLO戦略
distributed_slo:
  service_mesh_integration:
    istio_slo:
      traffic_management:
        - circuit_breaking
        - retry_policies
        - timeout_configuration

  composite_slos:
    description: "複数サービスにまたがるSLO"
    calculation: |
      End-to-end SLO = Service_A_SLO × Service_B_SLO × Service_C_SLO
      99.9% × 99.9% × 99.9% = 99.7%

  dependency_mapping:
    critical_path_analysis: true
    impact_propagation: true

実装ロードマップ

Quarter 1: 基盤構築
├── オブザーバビリティ基盤の整備
├── 主要サービスのSLI計測開始
├── チームへのSRE教育
└── 初期SLOの設定

Quarter 2: 運用確立
├── エラーバジェットポリシーの導入
├── アラート戦略の実装
├── ダッシュボードの標準化
└── インシデント対応プロセスとの連携

Quarter 3: 最適化
├── SLOベースのリリース判定
├── 自動化の拡大
├── 予測分析の導入
└── ステークホルダーレポーティング

Quarter 4: 成熟
├── AI/ML支援の導入
├── FinOps統合
├── Platform Engineering連携
└── 継続的改善サイクルの確立

成功事例

大手ECサイトの事例

case_study:
  company: "国内大手ECプラットフォーム"
  challenge: "ブラックフライデーセール時の障害頻発"

  implementation:
    before:
      monitoring: "サーバーメトリクス中心"
      alerts: "CPU/Memory閾値ベース"
      incidents: "月平均15件"

    after:
      monitoring: "ユーザージャーニーSLO"
      alerts: "エラーバジェットベース"
      incidents: "月平均3件"

  results:
    - "インシデント80%削減"
    - "MTTR（平均復旧時間）60%短縮"
    - "エンジニアのオンコール負荷50%軽減"
    - "顧客満足度20ポイント向上"

まとめ

2025年のSLO/SLI駆動運用は、単なるモニタリング手法からビジネス意思決定の基盤へと進化しています。

重要なポイント:

  1. ユーザー視点のSLI設計 - 技術メトリクスではなく、ユーザー体験を測定
  2. エラーバジェットの活用 - リリース速度と信頼性のバランスを定量化
  3. 適切なアラート戦略 - マルチウィンドウ・マルチバーンレートで精度向上
  4. ツールの選定 - Nobl9、Dynatrace、OpenSLOなど目的に応じた選択
  5. 組織文化の変革 - SLOを中心とした意思決定プロセスの確立

SLO/SLI駆動の運用は、**「100%の可用性は不可能」**という現実を受け入れ、限られたリソースを最も効果的に活用するための戦略的アプローチです。2025年以降、この考え方はさらに普及し、Platform EngineeringやFinOpsとの統合が進むことで、より成熟した信頼性管理が実現されていくでしょう。

参考: Google SRE Books, OpenSLO Specification

おすすめ記事

最新情報

Chaos Engineering 2025 - レジリエンスを科学する

Chaos Engineeringレジリエンス

この技術を体系的に学びたいですか？

未来学では東証プライム上場企業のITエンジニアが24時間サポート。月額24,800円から、退会金0円のオンラインIT塾です。

LINEで無料相談する
← 一覧に戻る