運用・SRE 深掘り

Google SRE Book / Workbook 準拠 — GCP サービスで実装する SRE プラクティス

1. SLO / SLI / Error Budget

4 つの Golden Signals（Google SRE Book）

サービスの健全性を測る基本指標。これを満たさない監視は SRE 的に不完全です。

SLI の設計：Request-based vs Windows-based

具体的な SLI 例（公開向け Web サービス）

Error Budget Policy

Error Budget = 許容できる失敗の量。SLO 99.9% なら 0.1% の失敗予算がある。

Error Budget Policy の実例

# Error Budget Policy（例）

service: my-api
slo: 99.9%
compliance_period: 30days_rolling

actions:
  - condition: budget_remaining >= 50%
    actions:
      - 新機能リリース継続
      - 通常の運用

  - condition: budget_remaining < 50% AND >= 25%
    actions:
      - リリース速度を半減（週2回 → 週1回）
      - リリースごとに staging で 24時間試験
      - エンジニアリングマネージャーに報告

  - condition: budget_remaining < 25%
    actions:
      - 機能リリースを停止
      - 信頼性向上タスクに 100% 注力
      - 失敗の根本原因分析を実施
      - SRE と Dev で原因対策会議

  - condition: budget_exhausted (< 0%)
    actions:
      - 緊急リリースのみ許可（バグ修正・セキュリティパッチ）
      - インシデントレビューを CTO に報告
      - 翌期の SLO を見直す可能性

Multi-Burn-Rate Alert

「Error Budget の消費速度（Burn Rate）」でアラートする方式。Google SRE Workbook 推奨。

Multi-burn-rate アラート設計

# Cloud Monitoring の SLO アラート例
displayName: "SLO Burn Rate - CRITICAL (page)"
combiner: AND
conditions:
  - displayName: "Burn rate > 14.4 over last 1h"
    conditionThreshold:
      filter: |
        select_slo_burn_rate("projects/PROJECT/services/SERVICE/serviceLevelObjectives/SLO",
        "3600s")
      comparison: COMPARISON_GT
      thresholdValue: 14.4
      duration: 0s

  - displayName: "Burn rate > 14.4 over last 5m"
    conditionThreshold:
      filter: |
        select_slo_burn_rate("projects/PROJECT/services/SERVICE/serviceLevelObjectives/SLO",
        "300s")
      comparison: COMPARISON_GT
      thresholdValue: 14.4
      duration: 0s

notificationChannels:
  - projects/PROJECT/notificationChannels/PAGERDUTY_CHANNEL

2. FinOps（コスト最適化）

FinOps 原則と GCP の構造

FinOps は「クラウド支出をビジネス価値に紐付けて運用する文化」。CFO / Engineering / Product の三者が責任を共有。

GCP のコスト構造（主要サービス）

Budgets と Anomaly Detection

# Cloud Billing Budget 作成（CLI）
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Production Monthly Budget" \
  --budget-amount=10000USD \
  --filter-projects="projects/prod-project" \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0 \
  --threshold-rule=percent=1.5,basis=forecasted-spend \
  --notifications-rule-pubsub-topic="projects/PROJECT/topics/budget-alerts" \
  --notifications-rule-monitoring-notification-channels="projects/PROJECT/notificationChannels/SLACK"

Cost Anomaly Detection（コスト異常検知）

過去パターンから「異常な支出増加」を機械学習で検知。Cloud Billing の Reports 内で有効化。

• プロジェクト・サービス・ラベル粒度で異常を発見
• 「特定の SKU が突然 3倍になった」「新規プロジェクトが急に高額」を即時検知
• Budget Alert と組み合わせ: Budget は「絶対額」、Anomaly Detection は「変化率」を見る

Committed Use Discount (CUD) / Spot VM

Spot VM の活用パターン

# GKE での Spot ノードプール
apiVersion: v1
kind: Node
metadata:
  labels:
    cloud.google.com/gke-spot: "true"
spec:
  # Spot は強制終了されるため、tolerations で受け入れ可能な Pod のみスケジュール
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: batch-worker
spec:
  template:
    spec:
      tolerations:
        - key: "cloud.google.com/gke-spot"
          operator: "Equal"
          value: "true"
          effect: "NoSchedule"
      terminationGracePeriodSeconds: 25   # 30秒の SIGTERM 内に終了

サービス別コスト最適化レシピ

3. インシデント対応・オンコール

アラート設計：SLO ベースの厳選

Google SRE Book 推奨：「人間が即座に行動を取る必要があるもの」だけ通知する。

典型的なアラート設計の改善例

悪い：「Cloud Run の CPU > 80% が 5分継続」
       → CPU 高くてもユーザー影響なしの可能性、誤検知

良い：「過去 1時間の error rate が 5% (Burn Rate 14.4) AND 過去 5分の error rate が 5%」
       → SLO 違反が短期 + 長期で確認、ユーザー影響確定

Runbook と Toil 削減

Runbook = アラート発火時の対応手順書。Toil = 手動・反復・自動化可能な作業。

良い Runbook の構成

# Runbook: Cloud Run Service "my-api" の error rate 上昇

## 1. 即時確認
1. Cloud Monitoring の SLO ダッシュボードを開く：
2. Burn Rate を確認（14.4 倍以上なら緊急）
3. Cloud Run の error率トレンドを直近 30分で確認

## 2. 切り分け
- (a) 直近のデプロイがあるか？ → Cloud Build Activity を確認
- (b) Cloud SQL の CPU / 接続数を確認
- (c) 外部 API（決済代行）のヘルスチェック
- (d) Cloud Logging で 5xx の内訳を確認

## 3. 緊急対応
### (a) デプロイが原因の場合
```bash
gcloud run services update-traffic my-api \
  --to-revisions=PREVIOUS=100 --region=us-central1
```

### (b) Cloud SQL の問題
- 接続数 > 90% → 一時的に max-instances を半減
- CPU > 95% → スレーブへ切替検討（Read Replica）

### (c) 外部 API 障害
- Circuit Breaker を有効化
- Slack #partner-incidents で連携

## 4. エスカレーション
30分以内に解決しなければ → On-call Engineering Manager に連絡（PagerDuty）
1時間以内に解決しなければ → CTO 通知

Postmortem 文化（Blameless）

インシデント後の振り返り。「誰の責任か」ではなく「システムをどう変えるか」に焦点。

Postmortem テンプレート（Google SRE Book 準拠）

# Postmortem: Cloud SQL Connection Exhaustion - 2026-05-28

## サマリー
- **日時**: 2026-05-28 14:00-14:15 JST（15分）
- **影響**: 注文 API の 30% が 500 を返却
- **重大度**: SEV-HIGH
- **ステータス**: 解決 / 再発防止策実装中

## タイムライン
- 14:00 セールキャンペーン開始、トラフィック 3倍に
- 14:03 Cloud SQL の接続数が max_connections に到達
- 14:05 PagerDuty アラート発火（SLO Burn Rate 14.4）
- 14:07 On-call Engineer 認識・対応開始
- 14:10 Cloud Run の max-instances を 100 → 50 に縮小
- 14:15 接続数回復、SLO 復活

## 根本原因
- Cloud Run max-instances=100 × 各 Pod の DB プール 20 = 最大 2,000 接続要求
- Cloud SQL の max_connections=100 → 接続枯渇

## 影響
- 注文失敗 248件、約 $5,000 の機会損失
- ユーザー苦情 12件
- SLO 月間 Error Budget の 30% を消費

## やったこと（What went well）
- アラートが 2分以内に発火 → 検知早期
- Runbook がすぐ参照可能 → 対応 4分以内

## うまくいかなかったこと（What went poorly）
- Cloud SQL 接続数の Capacity Planning が不十分
- セール前の負荷試験で max-instances 想定を考慮していなかった

## アクションアイテム
| # | 対応 | 担当 | 期限 |
|---|------|------|------|
| 1 | PgBouncer 導入で接続プーリング集約 | Alice | 2026-06-15 |
| 2 | Cloud SQL のフラグで max_connections=500 に増やす | Bob | 2026-06-01 |
| 3 | セール前 Capacity Planning チェックリスト整備 | Carol | 2026-06-30 |
| 4 | 接続数 80% で Page アラートを追加 | Dave | 2026-06-05 |

4. リリース工学・カオステスト・キャパシティ

Progressive Delivery（段階的リリース）

Cloud Deploy + Cloud Run/GKE の自動 Progressive Delivery

# Cloud Deploy の Delivery Pipeline
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-app
serialPipeline:
  stages:
    - targetId: staging
      profiles: []
    - targetId: prod-canary
      profiles: []
      strategy:
        canary:
          runtimeConfig:
            cloudRun:
              automaticTrafficControl: true
          canaryDeployment:
            percentages: [5, 25, 50]      # 段階的に拡大
            verify: true                    # 各段階で検証
    - targetId: prod-full
      profiles: []

Feature Flag による機能フラグ

# Feature Flag の典型実装（自前 or LaunchDarkly/Flagsmith 利用）
def get_feature(feature_name: str, user_id: str) -> bool:
    """機能フラグの有効性を判定"""
    config = feature_flag_client.get_config(feature_name)

    # 1. 完全有効 / 完全無効
    if config["enabled"] is False:
        return False
    if config["rollout_percent"] == 100:
        return True

    # 2. % rollout（ユーザーIDの hash で決定）
    user_hash = hash(f"{feature_name}:{user_id}") % 100
    return user_hash < config["rollout_percent"]

# 使い方
if get_feature("new_checkout_flow", user_id):
    return render_new_checkout()
else:
    return render_legacy_checkout()

Chaos Engineering

「意図的に障害を起こして、システムの弱点を発見」する実践。

典型的な Chaos Experiments

Capacity Planning

「将来のトラフィック増に対応できるか」を事前に確認する活動。

負荷試験のシナリオパターン

# k6 を使った負荷試験
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // 2分かけて 100 VU まで上げる（ramp-up）
    { duration: '5m', target: 100 },   // 5分維持
    { duration: '2m', target: 500 },   // 500 VU まで急増（spike）
    { duration: '5m', target: 500 },   // 維持
    { duration: '2m', target: 0 },     // ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://my-api.example.com/orders');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

Quota 管理のチェックリスト

• Compute Engine: CPU、Persistent Disk、External IP（地域別）
• Cloud SQL: max_connections（インスタンスフラグ）、インスタンス数
• Cloud Run: max-instances、リクエスト/秒
• Cloud Storage: バケット数、API request/秒
• BigQuery: 同時クエリ数、スロット数、ストリーミング挿入
• Pub/Sub: メッセージ/秒、topic 数
• API レート制限: quota.exceeded エラーで判明する前に確認

5. DR / BCP（災害復旧・事業継続）

RPO / RTO の定義

DR 戦略パターン

GCP サービス別 DR 設計

• Cloud Run: 複数リージョンに同じ Service をデプロイ + Global HTTP(S) LB でルーティング
• GKE: GKE Multi-cluster + Anthos / Cloud Service Mesh で複数リージョン
• Spanner: マルチリージョン構成（自動同期、RPO=0、RTO≈0）
• Cloud SQL: クロスリージョンリードレプリカ + 手動フェイルオーバー（RPO: 秒、RTO: 数分）
• Firestore: マルチリージョンモードでリージョン障害時も継続
• Cloud Storage: Dual-region / Multi-region クラスで自動レプリケーション
• BigQuery: copy_dataset でクロスリージョン同期、または BigQuery Omni
• Pub/Sub: グローバルサービス（リージョン障害でも自動継続）

6. Observability 深掘り

Pillars of Observability（3つの柱）

Profiles（4本目の柱）

近年は Profiling（CPU/メモリの関数単位 hotspot）も Observability の柱として注目。GCP では Cloud Profiler が継続的プロファイリング（< 1% オーバーヘッド）を提供。

High Cardinality の罠

サンプリング戦略

USE Method / RED Method

📚 SRE 実践のための学習リソース

• Google SRE Book（無料公開）
• Google SRE Workbook
• Google Cloud Architecture Framework
• Cloud Monitoring SLO ドキュメント
• SRE Resources（テンプレート集）