EXERCISE 60分

ストーリー

佐藤CTO
理論は十分だ。実際にマイクロサービスプラットフォームのSLI/SLOを設計してみよう
佐藤CTO
我々の決済プラットフォーム全体のサービスレベルを定義し、計測ダッシュボードまで設計してほしい

ミッション概要

ミッションテーマ目安時間
Mission 1ユーザージャーニーからSLIを導出15分
Mission 2SLO目標値の設定と根拠15分
Mission 3Multi-Window Burn-Rateアラート設計15分
Mission 4Grafanaダッシュボード設計15分

前提条件

platform: "FinPay - 決済プラットフォーム"
architecture:
  services:
    - name: "API Gateway"
      role: "リクエストルーティング、認証"
      rps: 5000
    - name: "Payment Service"
      role: "決済処理、決済状態管理"
      rps: 500
    - name: "Merchant Portal"
      role: "加盟店向け管理画面"
      rps: 200
    - name: "Notification Service"
      role: "決済結果通知(Webhook、メール)"
      rps: 1000
    - name: "Analytics Service"
      role: "取引分析、レポート生成"
      rps: 100

historical_data:
  payment_service:
    last_6_months_availability: [99.97, 99.95, 99.98, 99.92, 99.96, 99.94]
    last_6_months_latency_p99: [450, 520, 400, 600, 480, 510]
  api_gateway:
    last_6_months_availability: [99.99, 99.98, 99.99, 99.97, 99.99, 99.98]

monthly_revenue: "5億円"
regulatory: "PCI DSS Level 1準拠"

Mission 1: ユーザージャーニーからSLIを導出(15分)

要件

FinPayプラットフォームの主要ユーザージャーニーを3つ特定し、各ジャーニーに対して適切なSLIを設計してください。

各SLIについて以下を明記すること:

  • SLIタイプ(availability/latency/correctness/freshness)
  • Good Event と Valid Event の定義
  • 測定ポイント
  • 除外条件
解答例

ジャーニー1: 決済処理

項目SLI 1: 決済可用性SLI 2: 決済レイテンシ
タイプavailabilitylatency
Good Event決済APIが正常レスポンス(非5xx)決済完了が3秒以内
Valid Event全決済リクエスト正常な決済リクエスト
測定ポイントAPI Gateway(ALBログ)Payment Serviceメトリクス
除外ヘルスチェック、テスト決済タイムアウトした決済

ジャーニー2: 加盟店ダッシュボード

項目SLI 1: ポータル可用性SLI 2: データ鮮度
タイプavailabilityfreshness
Good EventポータルAPIが200を返す売上データが5分以内に反映
Valid Event全ポータルリクエストデータ表示リクエスト
測定ポイントAPI GatewayAnalytics Serviceメトリクス
除外CSRFトークンエラー(400)メンテナンスウィンドウ

ジャーニー3: 決済通知

項目SLI 1: 通知配信率SLI 2: 通知遅延
タイプavailabilitylatency
Good EventWebhookが200を受信決済完了から30秒以内に通知
Valid Event全通知対象イベント配信成功した通知
測定ポイントNotification ServiceNotification Serviceメトリクス
除外加盟店側のサーバーダウンリトライによる遅延

Mission 2: SLO目標値の設定と根拠(15分)

要件

Mission 1で設計したSLIに対して、SLO目標値を設定してください。 各SLOについて以下を明記すること:

  • 目標値と根拠
  • エラーバジェット(月間)
  • SLAとの関係(バッファ設計)
解答例
SLO目標値根拠月間エラーバジェットSLA
決済可用性99.95%過去最低99.92%、金融規制21.6分99.9%
決済レイテンシ99% < 3s過去p99最大600ms、余裕ありリクエストの1%95% < 5s
ポータル可用性99.9%営業時間帯の利用が中心43.2分99.5%
データ鮮度99.5%分析用途でリアルタイム性は緩い216分99%
通知配信率99.9%加盟店のビジネスに直接影響43.2分99.5%
通知遅延95% < 30sリトライを考慮した緩い目標5%のリクエスト90% < 60s

バッファ設計:

決済可用性:
  SLO: 99.95% ──┐
                ├─ バッファ: 0.05%(月間21.6分)
  SLA: 99.9%  ──┘

  SLOは過去実績(99.92%)に対して達成可能
  SLAはSLOにさらにバッファを持たせて安全に

Mission 3: Multi-Window Burn-Rateアラート設計(15分)

要件

決済可用性SLO(99.95%)に対するMulti-Window Multi-Burn-Rateアラートを設計してください。 PromQLでアラートルールを記述すること。

解答例
# SLO: 99.95% (許容エラー率: 0.0005)
# ウィンドウ: 30日

alerts:
  critical:
    burn_rate: 14.4
    long_window: 1h
    short_window: 5m
    budget_exhaustion: "~2日"
    action: "PagerDuty即時通知"

  warning:
    burn_rate: 6.0
    long_window: 6h
    short_window: 30m
    budget_exhaustion: "~5日"
    action: "Slack #sre-alerts、当日対応"

  info:
    burn_rate: 3.0
    long_window: 3d
    short_window: 6h
    budget_exhaustion: "~10日"
    action: "Jiraチケット作成"
# Recording Rules
- record: finpay:payment_error_ratio:5m
  expr: |
    1 - (
      sum(rate(payment_requests_total{status!~"5.."}[5m]))
      /
      sum(rate(payment_requests_total[5m]))
    )

- record: finpay:payment_error_ratio:1h
  expr: |
    1 - (
      sum(rate(payment_requests_total{status!~"5.."}[1h]))
      /
      sum(rate(payment_requests_total[1h]))
    )

- record: finpay:payment_error_ratio:6h
  expr: |
    1 - (
      sum(rate(payment_requests_total{status!~"5.."}[6h]))
      /
      sum(rate(payment_requests_total[6h]))
    )

# Alert Rules
- alert: PaymentSLO_Critical
  expr: |
    finpay:payment_error_ratio:1h > (14.4 * 0.0005)
    and
    finpay:payment_error_ratio:5m > (14.4 * 0.0005)
  for: 2m
  labels:
    severity: critical
    service: payment
  annotations:
    summary: "決済SLO: Critical burn rate detected"

- alert: PaymentSLO_Warning
  expr: |
    finpay:payment_error_ratio:6h > (6 * 0.0005)
    and
    finpay:payment_error_ratio:30m > (6 * 0.0005)
  for: 5m
  labels:
    severity: warning

- alert: PaymentSLO_Info
  expr: |
    finpay:payment_error_ratio:3d > (3 * 0.0005)
    and
    finpay:payment_error_ratio:6h > (3 * 0.0005)
  for: 30m
  labels:
    severity: info

Mission 4: Grafanaダッシュボード設計(15分)

要件

FinPayプラットフォーム全体のSLOダッシュボードを設計してください。 以下を含むこと:

  1. エグゼクティブビュー(全SLO一覧)
  2. サービスビュー(決済サービスの詳細)
  3. 使用するPromQLクエリ
解答例

エグゼクティブビュー:

パネルタイプPromQL
決済可用性Statsum(increase(payment_requests_total{status!~"5.."}[30d])) / sum(increase(payment_requests_total[30d])) * 100
決済バジェット残Gaugeバジェット消費率の逆数
ポータル可用性Stat同様のクエリ(portal用)
通知配信率Stat同様のクエリ(notification用)
SLO達成状況Table全SLOの一覧(目標/実績/バジェット残)

サービスビュー(決済):

パネルタイプ内容
可用性トレンドTime Series30日ローリングの可用性推移 + SLO線
バーンレートTime Series1h/6h/3dのバーンレート推移
レイテンシ分布Heatmapレイテンシのヒートマップ
エラー内訳Pie Chartエラーコード別の内訳
エンドポイント別Tableエンドポイント別のエラー率とレイテンシ
依存サービスStat決済API、DBの健全性

達成度チェック

ミッションテーマ完了
Mission 1SLI導出
Mission 2SLO目標設定
Mission 3Burn-Rateアラート設計
Mission 4ダッシュボード設計

まとめ

ポイント内容
SLI設計ユーザージャーニーから導出し、Good/Valid Eventを明確に定義
SLO設定過去データとビジネス制約からバランスの取れた目標を設定
アラートMulti-Window Burn-Rateで3段階のアラートを設計
ダッシュボードエグゼクティブ→サービスの階層で設計

チェックリスト

  • 実際のサービスに対してSLIを設計できた
  • データに基づいたSLO目標値を設定できた
  • PromQLでBurn-Rateアラートを記述できた
  • SLOダッシュボードの構成を設計できた

次のステップへ

次は理解度チェッククイズです。Step 2で学んだSLI/SLO設計の理解度を確認しましょう。


推定読了時間: 60分