ストーリー
田
田中VPoE
SLI/SLO戦略、階層設計、エラーバジェットポリシー、レビュープロセス — 4つの要素を学んだ。ここからはTaskFlow社の全サービスに対してSLI/SLO体系を設計してもらう
田
田中VPoE
そうだ。ただし闇雲に設計するのではなく、ティア制度に基づくSLO基準水準、依存関係を考慮した階層設計、エラーバジェットポリシー、レビュープロセスの全てを含んだ包括的な体系だ。この設計書が経営会議で「SLI/SLO運用の正式開始」を承認してもらうための提案資料になる
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | SLI/SLO体系設計書 |
| 想定時間 | 90分 |
| 成果物 | SLI/SLO体系設計書(階層SLO + エラーバジェットポリシー + レビュープロセス) |
| 対象組織 | TaskFlow株式会社(Step 1, 2と同一) |
前提条件
サービス一覧とティア分類
TaskFlow社 サービスカタログ:
Tier 1(クリティカル):
1. API Gateway - 全リクエストの入り口
2. Payment Service - 決済処理
Tier 2(重要):
3. Task Service - タスクCRUD(コア機能)
4. Project Service - プロジェクト管理
5. Auth Service - 認証・認可
6. Notification Service - 通知配信
Tier 3(標準):
7. Search Service - 全文検索
8. Report Service - レポート生成
9. File Service - ファイルアップロード・管理
10. Analytics Service - 利用状況分析
Tier 4(低優先):
11. Batch Service - バッチ処理(夜間集計等)
12. Admin Service - 管理者ツール
13. Migration Service - データ移行ツール
14. Sandbox Service - テスト用サンドボックス
15. Webhook Service - 外部連携Webhook
依存関係情報
主要な依存関係:
API Gateway → Auth Service → Database
API Gateway → Task Service → Database, Cache
API Gateway → Project Service → Database
API Gateway → Payment Service → Database, External Payment Gateway
API Gateway → Search Service → Elasticsearch
API Gateway → Report Service → Database, S3
Task Service → Notification Service → SQS → Email/Push Provider
Project Service → Notification Service → SQS → Email/Push Provider
Payment Service → Notification Service → SQS → Email/Push Provider
Report Service → Analytics Service → Data Warehouse
Batch Service → Database, Data Warehouse, S3
現状のSLI実績(直近3ヶ月平均)
| サービス | 可用性実績 | P99レイテンシ実績 | エラーレート実績 |
|---|
| API Gateway | 99.97% | 180ms | 0.02% |
| Payment Service | 99.95% | 350ms | 0.04% |
| Task Service | 99.93% | 220ms | 0.05% |
| Project Service | 99.92% | 250ms | 0.06% |
| Auth Service | 99.98% | 80ms | 0.01% |
| Notification Service | 99.85% | N/A(非同期) | 0.12% |
| Search Service | 99.80% | 500ms | 0.15% |
| Report Service | 99.70% | 3000ms | 0.20% |
Mission 1: サービスSLI/SLO定義
要件
以下を設計してください。
- 全15サービスのSLI定義(サービスタイプに応じたSLI選択)
- 全15サービスのSLO値設定(ティア基準水準と実績データに基づく)
- SLO設定の根拠(各SLOの値がなぜその水準かの説明)
解答例
Tier 1 サービス
| サービス | SLI | 計算式 | SLO | 根拠 |
|---|
| API Gateway | 可用性 | 2xx+3xx応答数 / 総リクエスト数 | 99.95% | 全リクエストの入り口。実績99.97%から余裕を持たせつつTier 1基準を満たす |
| API Gateway | レイテンシ | 200ms以内の応答数 / 総リクエスト数 | 99.0% | P99が180ms。200ms閾値で99%目標は現実的 |
| Payment Service | 可用性 | 成功トランザクション数 / 総トランザクション数 | 99.95% | 決済は売上直結。実績99.95%でギリギリだがTier 1基準 |
| Payment Service | レイテンシ | 500ms以内の応答数 / 総リクエスト数 | 99.0% | 外部ゲートウェイ依存あり。P99 350msから余裕を確保 |
Tier 2 サービス
| サービス | SLI | 計算式 | SLO | 根拠 |
|---|
| Task Service | 可用性 | 成功応答数 / 総リクエスト数 | 99.9% | コア機能。実績99.93%から0.03%マージン |
| Task Service | レイテンシ | 300ms以内の応答数 / 総リクエスト数 | 99.0% | P99 220ms。300ms閾値で十分な余裕 |
| Project Service | 可用性 | 成功応答数 / 総リクエスト数 | 99.9% | 実績99.92%。Tier 2基準を満たす |
| Auth Service | 可用性 | 成功認証数 / 総認証試行数 | 99.95% | 全サービスの依存先。Tier 2だがSLOは高めに設定 |
| Auth Service | レイテンシ | 100ms以内の応答数 / 総リクエスト数 | 99.5% | 認証は低レイテンシが重要。P99 80msで余裕あり |
| Notification Service | 配信率 | 30秒以内に配信されたイベント数 / 総イベント数 | 99.5% | 非同期のため可用性より配信率。実績99.85%から余裕 |
Tier 3 サービス
| サービス | SLI | 計算式 | SLO | 根拠 |
|---|
| Search Service | 可用性 | 成功応答数 / 総リクエスト数 | 99.5% | 検索ダウン時はフォールバック可。実績99.80%から余裕 |
| Report Service | 可用性 | 成功生成数 / 総リクエスト数 | 99.5% | バッチ的性格が強い。実績99.70%から引き上げ |
| Report Service | 鮮度 | 60秒以内に生成完了した割合 | 95.0% | レポート生成は時間がかかるため基準を緩和 |
| File Service | 可用性 | 成功アップロード/ダウンロード数 / 総操作数 | 99.5% | S3依存で安定しているが、Tier 3基準を適用 |
| Analytics Service | 鮮度 | データが1時間以内に反映される割合 | 99.0% | 分析はリアルタイム性が低い |
Tier 4 サービス
| サービス | SLI | SLO | 根拠 |
|---|
| Batch Service | ジョブ成功率 | 99.0% | 夜間実行、リトライで対応可能 |
| Admin Service | 可用性 | 99.0% | 社内ツール、営業時間のみ使用 |
| Migration Service | ジョブ成功率 | 95.0% | 不定期使用、手動リトライ可 |
| Sandbox Service | 可用性 | 95.0% | テスト用、SLO自体が参考値 |
| Webhook Service | 配信成功率 | 99.0% | リトライ機構あり |
Mission 2: ジャーニーSLOと階層設計
要件
以下を設計してください。
- 主要ジャーニーSLO(5つ以上) の定義
- 依存関係に基づくSLO整合性の検証
- SLO階層図(ジャーニー → サービス → インフラの対応関係)
解答例
ジャーニーSLO
| ジャーニー | 関与サービス | SLI | SLO | 理論的上限 |
|---|
| タスク作成 | Gateway→Auth→Task→DB→Notification | 2秒以内に完了 | 99.9% | 99.75% |
| プロジェクト一覧 | Gateway→Auth→Project→DB→Cache | 3秒以内に表示 | 99.9% | 99.80% |
| 決済完了 | Gateway→Auth→Payment→External→Notification | 5秒以内に完了 | 99.9% | 99.75% |
| 全文検索 | Gateway→Auth→Search→Elasticsearch | 1秒以内に結果表示 | 99.5% | 99.40% |
| レポート生成 | Gateway→Auth→Report→Analytics→S3 | 60秒以内に完了 | 99.0% | 99.35% |
| ファイルアップロード | Gateway→Auth→File→S3 | 10秒以内に完了 | 99.5% | 99.85% |
SLO整合性の検証
ジャーニー: タスク作成(SLO 99.9%)
Gateway: 99.95%
Auth: 99.95%
Task: 99.9%
DB: 99.99%
Notification: 99.5% (非同期・非クリティカル)
クリティカルパスの理論的上限:
0.9995 × 0.9995 × 0.999 × 0.9999 = 99.84%
問題: 理論的上限(99.84%) < ジャーニーSLO(99.9%)
対策:
案1: Task ServiceのSLOを99.95%に引き上げ → 99.89%(まだ不足)
案2: 加えてAuth ServiceのSLOを99.99%に引き上げ → 99.93%(達成可能)
案3: ジャーニーSLOを99.8%に引き下げ
→ 案2を採用。Auth Serviceは全サービス共通依存なので
高SLO投資の費用対効果が高い
SLO階層図
ジャーニーSLO サービスSLO インフラSLO
───────────── ────────────── ─────────────
タスク作成 99.9% ─┬── Gateway 99.95% ──┬── RDS 99.99%
├── Auth 99.99% ├── ElastiCache 99.99%
├── Task 99.95% └── ECS 99.95%
└── Notification 99.5%
決済完了 99.9% ──┬── Gateway 99.95%
├── Auth 99.99%
├── Payment 99.95%
└── Notification 99.5%
全文検索 99.5% ──┬── Gateway 99.95% ──── Elasticsearch 99.9%
├── Auth 99.99%
└── Search 99.5%
Mission 3: エラーバジェットポリシーとレビュープロセス
要件
以下を設計してください。
- ティア別エラーバジェットポリシー(4段階)
- バーンレートアラート設定(Tier 1/2向け)
- レビュープロセス設計(週次・月次・四半期)
- SLO運用開始のロードマップ
解答例
ティア別エラーバジェットポリシー
Tier 1:
| ステージ | バジェット残量 | アクション |
|---|
| Green | 75-100% | 通常開発。週次レビューで状況報告 |
| Yellow | 50-75% | SREレビュー付きデプロイ。信頼性タスク30% |
| Orange | 25-50% | 新機能一部凍結。VPoE報告。カナリア必須 |
| Red | 0-25% | 完全機能フリーズ。全リソースを信頼性回復に |
Tier 2:
| ステージ | バジェット残量 | アクション |
|---|
| Green | 60-100% | 通常開発 |
| Yellow | 30-60% | リスク評価強化。信頼性タスク30% |
| Orange | 10-30% | 大規模変更凍結。SREリード報告 |
| Red | 0-10% | 機能フリーズ。ポストモーテム必須 |
Tier 3/4: 閾値は設定するがアクションは勧告レベル(強制力なし)
バーンレートアラート
| サービスティア | ページアラート | チケットアラート | 報告アラート |
|---|
| Tier 1 | 1hバーンレート>14.4 | 6hバーンレート>6 | 3dバーンレート>1 |
| Tier 2 | 1hバーンレート>14.4 | 6hバーンレート>6 | 1wバーンレート>1 |
| Tier 3 | なし | 6hバーンレート>10 | 1wバーンレート>1.5 |
| Tier 4 | なし | なし | 1wバーンレート>2 |
レビュープロセス
| レビュー | 頻度 | 参加者 | 主要議題 |
|---|
| 週次SLO | 毎週月曜 30分 | SRE + オンコール | バジェット残量確認、今週のデプロイリスク |
| 月次サービス | 月初水曜 1時間 | SREリード + サービスオーナー | SLO達成率、改善策、SLO調整提案 |
| 四半期戦略 | 四半期末 2時間 | VPoE + 全リード | ティア見直し、ポリシー有効性、投資判断 |
SLO運用開始ロードマップ
| フェーズ | 期間 | 対象 | マイルストーン |
|---|
| Phase 1: パイロット | 月1-2 | Tier 1(2サービス) | SLI計測開始、SLOダッシュボード稼働 |
| Phase 2: 拡大 | 月3-4 | Tier 1+2(6サービス) | エラーバジェットポリシー適用、週次レビュー開始 |
| Phase 3: 全社展開 | 月5-6 | 全サービス | 全サービスSLO設定完了、月次・四半期レビュー開始 |
達成度チェック
| 観点 | 達成基準 |
|---|
| SLI/SLO定義の網羅性 | 全15サービスのSLIとSLOが定義されている |
| 階層設計の整合性 | ジャーニーSLO→サービスSLO→インフラSLOの整合性が検証されている |
| ポリシーの実用性 | ティア別のエラーバジェットポリシーが具体的なアクションとともに定義されている |
| レビュープロセスの設計 | 3つのレビューサイクルが参加者・アジェンダとともに設計されている |
| ロードマップの現実性 | 段階的な展開計画が現実的なタイムラインで示されている |
推定所要時間: 90分