1. SLO / SLI / Error Budget の設計
1-1. 概念の整理
| 用語 | 意味 | 誰が決めるか |
|---|
| SLA (Service Level Agreement) |
サービスとして契約上保証する稼働率 |
Google（クラウド事業者） |
| SLO (Service Level Objective) |
SLI に対する内部目標値 |
自社（SRE と PdM） |
| SLI (Service Level Indicator) |
実際に測定する指標 |
自社（SRE） |
| Error Budget |
SLO に対する許容ダウンタイム |
SLO から自動算出 |
例: 「Cloud SQL のクエリ成功率 SLO = 99.9%」 の場合
Error Budget = 100% - 99.9% = 0.1%
月間 (30日 = 43,200分) → 許容ダウンタイム = 43.2 分/月
1-2. SLO 階層の設計
ユーザー視点の SLO (最重要)
└─ クエリ p99 レイテンシ < 100 ms (99.9%)
└─ クエリ成功率 > 99.95%
サービス視点の SLO (構成要素)
└─ DB CPU 利用率 < 80% (95%)
└─ ストレージ利用率 < 80% (98%)
└─ レプリ遅延 < 5 秒 (99.5%)
インフラ視点の SLI (詳細メトリクス)
└─ Cloud SQL 死活
└─ 接続成功率
└─ binlog の遅延
SLO 設計のコツ: ユーザー視点を最上位に置く。インフラメトリクスだけで SLO を作ると「DB は動いてるのにユーザーは困っている」事態に。エンドツーエンドの体験を必ず計測する。
2. DB ごとの SLI 候補
Cloud SQL
| SLI | 計測方法 | 典型 SLO |
|---|
| クエリ成功率 | アプリログのエラー率 / Cloud Logging | 99.95% |
| クエリ p99 レイテンシ | Cloud Monitoring cloudsql.googleapis.com/database/postgresql/transactions | < 100ms |
| 接続失敗率 | カスタムメトリクス（アプリ側） | < 0.1% |
| レプリ遅延 p99 | cloudsql.googleapis.com/database/replication/replica_lag | < 5s |
| バックアップ成功率 | cloudsql.googleapis.com/backup_operations | 100% |
Spanner
| SLI | 計測方法 | 典型 SLO |
|---|
| クエリ成功率 | spanner.googleapis.com/api/api_request_count でステータス別集計 | 99.99% |
| 高優先度 CPU 利用率 | spanner.googleapis.com/instance/cpu/utilization_by_priority | < 65% |
| クエリ p99 レイテンシ | spanner.googleapis.com/api/request_latencies | < 50ms |
| Lock conflicts | Query Stats から | < 100/min |
Bigtable
| SLI | 計測方法 | 典型 SLO |
|---|
| サーバーサイド レイテンシ p99 | bigtable.googleapis.com/server/latencies | < 10ms |
| CPU 利用率 | クラスタ平均 | < 70% |
| Hot Tablet 数 | Key Visualizer + Custom Metric | = 0 |
| レプリ遅延 | bigtable.googleapis.com/replication/latency | < 10s |
3. Runbook テンプレート集
Runbook とは
Runbook = 「アラートが鳴ったら何をするか」のステップバイステップ手順書。深夜の On-call エンジニアが寝ぼけても作業できるレベルで書く。
テンプレート: Cloud SQL CPU 高騰
-
影響範囲確認
Cloud Monitoring で「DB に依存するサービスのエラー率」を確認。ユーザー影響がない場合は P3 として翌朝対応。
-
原因切り分け (15分以内)
Query Insights で Top SQL 確認 → 特定 SQL が CPU を食っているか？ → 急なバッチが走ったか？
-
緊急対応
- バッチが原因なら停止
- スロークエリなら SELECT pg_cancel_backend(pid) でキャンセル
- リソース不足ならマシンタイプアップ（要 ChatOps 承認）
-
事後対応
Incident チケット起票、Postmortem の予約、Query Insights のレポート保存
テンプレート: ストレージ枯渇間近
-
残量確認
gcloud sql instances describe で残ストレージサイズ確認
-
増加要因確認
テーブル毎の容量 (
information_schema.tables) を抽出、binlog/WAL のサイズも確認
-
緊急対応
- Auto Storage Increase 無効なら有効化
- 不要な過去データ削除（PITR 内のテーブルは別途検討）
-
恒久対応
容量増加トレンドの分析、アーカイブ戦略策定
テンプレート: レプリ遅延拡大
-
遅延継続時間確認
Cloud Monitoring グラフで遅延の急増ポイントを特定
-
原因切り分け
- Primary 側: 大量書き込みバッチが走っていないか？
- Replica 側: CPU/メモリ不足になっていないか？
- 大規模 DDL (ALTER TABLE) が走っていないか？
-
対応
バッチを分割実行、レプリのマシンタイプアップ、不要なクエリを Primary に逃がす
4. On-call 体制と通知設計
4-1. アラート優先度の設計
| 優先度 | 通知先 | 応答 SLA | 典型例 |
|---|
| P1 (Critical) |
PagerDuty + 電話 |
5分以内 |
DB ダウン、書き込み 100% 失敗、ストレージ枯渇 |
| P2 (High) |
PagerDuty |
15分以内 |
CPU 90%超、レプリ遅延 5分超 |
| P3 (Warning) |
Slack |
翌営業日 |
CPU 70%超、ストレージ 70%超 |
| P4 (Info) |
Slack/Email |
定期レビュー |
Query Insights 推奨、Cost 増加 |
アラート疲労 (Alert Fatigue): 鳴りすぎるアラートは無視される。
対策: アラートあたり「アクション可能か?」を常に問う。アクション不要なものは削除。
4-2. ロテーション設計
推奨パターン:
- Primary On-call（1人、1週間ローテ）
- Secondary（Primary がエスカレーション）
- 週末は別ローテで負担分散
- On-call 中は 緊急対応のみ、新機能開発はしない
5. 変更管理 (Change Management)
5-1. 変更影響度の分類
| 変更タイプ | 影響度 | 必要なプロセス |
|---|
| マイナーパッチ自動適用 | 低 | 事前通知のみ |
| マシンタイプ変更 | 中 | 変更承認 + メンテウィンドウ |
| スキーマ変更（軽量） | 中 | レビュー + ステージング検証 |
| スキーマ変更（重い ALTER） | 高 | 変更承認 + ドライラン + メンテウィンドウ |
| メジャーアップグレード | 致命的 | Blue-Green + 全機能テスト + ロールバック計画 |
| リージョン移行 | 致命的 | プロジェクト体制 + 数ヶ月計画 |
5-2. 変更時のチェックリスト
変更実施前:
- 影響範囲ドキュメント化
- テスト環境で実施
- ロールバック手順を文書化
- 変更承認（必要に応じて CAB）
- 関係者への通知
- 監視強化体制
変更実施中:
- 変更ログをリアルタイム記録
- 監視メトリクスを表示
- Go/No-Go チェックポイント
変更完了後:
- 動作確認（事前定義のテスト）
- 監視メトリクスの正常性確認
- 関係者への完了通知
- 記録（変更履歴 DB）
6. DR ドリルの実施パターン
6-1. DR ドリルの目的
マネージド DB でも、実際にフェイルオーバーしてみないとアプリが正しく動くかわからない。Runbook の通り動けるか、人と手順の検証が目的。
6-2. ドリルパターン
パターン A: Cloud SQL 手動フェイルオーバー
事前準備
├ DR チーム招集（運用 + アプリ + ビジネス）
├ 影響時間の合意（ユーザー通知）
└ ロールバック計画確認
実施 (本番のメンテ時間)
├ gcloud sql instances failover
├ アプリログで再接続状況を確認
├ クエリレイテンシの監視
└ フェイルオーバー所要時間記録
事後
├ Postmortem 形式で振り返り
└ Runbook 更新
パターン B: クロスリージョン Replica Promote
ステージング環境で実施 (本番は影響大すぎ)
├ DR リードレプリカを別環境に作成
├ アプリのステージング接続先を切り替え
├ Promote 実行
├ 整合性検証
└ 元構成への戻し
パターン C: テーブル誤削除のリストア
- 本番テーブルを意図的に「削除」（ステージング）
- PITR で削除直前に巻き戻し
- 新しい復元先インスタンスから削除されたテーブルだけエクスポート
- 本番に再インポート
- 全プロセス所要時間と問題点を記録
DR ドリル頻度: 四半期に 1 回、ロール分担を変えながら全員が経験を持つ。「年 1 回だけ」ではいざという時に動けない。
7. Chaos Engineering 入門
7-1. 概念
計画的に小規模な障害を注入し、システムのレジリエンスを検証する手法。本番でなく検証環境で実施。
7-2. DB 領域での Chaos 実験
| 実験 | 方法 | 確認事項 |
|---|
| レイテンシ注入 |
tc コマンド or Proxy で DB ネットワークに遅延付加 |
アプリのタイムアウト挙動、再試行ロジック |
| パケットロス注入 |
iptables で一定割合パケットドロップ |
接続プールの回復性 |
| 強制フェイルオーバー |
gcloud sql instances failover |
RTO 計測、アプリ再接続 |
| ストレージ満杯シミュ |
大量データ書き込みで意図的に満杯 |
アラート発火、書き込みエラー処理 |
Chaos は必ず非本番環境で実施。本番で実施するには成熟した SRE 組織と組織合意が必要。
8. キャパシティプランニング
8-1. プランニングの考え方
現在のリソース利用率
↓
成長率 (月次トレンド)
↓
予測モデル (例: 3ヶ月先まで)
↓
発注リードタイム考慮
↓
早めにスケールアップ計画
8-2. メトリクスベース予測
| メトリクス | 監視指標 | アクション閾値 |
|---|
| CPU 利用率 | 30日平均、ピーク値 | 平均 60%超でアップグレード計画 |
| ストレージ | 増加率 (GB/日) | 3ヶ月先で 80% 到達なら拡張 |
| 接続数 | ピーク値の月次推移 | max の 60% で警告 |
| QPS | 毎時ピーク値 | キャパシティの 70% で対策 |
8-3. Spanner のキャパシティプランニング例
- 過去 3 ヶ月の CPU 利用率トレンドを抽出
- 線形 / 指数モデルでフィット
- 6 ヶ月先で CPU 65% を超える時期を予測
- 1 ヶ月前に PU 増加を計画
- 自動スケーリング (Spanner Autoscaler) は併用するが、急増には対応が遅れる
9. Postmortem 文化
9-1. Blameless Postmortem
「誰が悪いか」ではなく「システム / プロセス / ツールのどこに問題があったか」に焦点を当てる。これにより全員が事故を正直に報告でき、再発防止につながる。
9-2. テンプレート
# Incident YYYY-MM-DD: [タイトル]
## サマリー
- 発生時刻:
- 復旧時刻:
- 影響範囲: (どの機能・何人のユーザー・どれだけのトランザクション)
- 重要度: P1 / P2 / P3
## タイムライン
- HH:MM 監視アラート発生
- HH:MM On-call が応答
- HH:MM 原因特定
- HH:MM 対応開始
- HH:MM 復旧確認
## 根本原因 (Root Cause)
- 5 Whys 分析:
- なぜ A? → B
- なぜ B? → C
- ...
## 効いた対応 / 効かなかった対応
- 効いた: [対応内容]
- 効かなかった: [対応内容と理由]
## 再発防止策 (アクションアイテム)
- [ ] AI-1: 担当=Alice, 期限=YYYY-MM-DD
- [ ] AI-2: 担当=Bob, 期限=YYYY-MM-DD
## 教訓
- 何を学んだか
- 他チームに共有すべきか
9-3. アクションアイテムのトラッキング
Postmortem のアクションアイテムが実装されないと、同じ事故が再発する。SRE チームは AI のクローズ率を 四半期毎に KPI として測定する。
📋 SRE 観点の試験ポイント
PCDBE 試験では、SRE 視点で次が問われる:
- 「自動化と再現性」 → Terraform + IaC が正解
- 「監視とアラート」 → Cloud Monitoring + Alert Policy + Notification Channel
- 「自動復旧」 → Cloud SQL HA で自動フェイルオーバー
- 「変更管理」 → メンテナンスウィンドウ + Near-Zero Downtime (Enterprise Plus)
- 「災害対策」 → クロスリージョン Replica + 手動 Promote 手順