📚 GCP PCA 学習: 2026-05-21

セクション: 4.3 信頼性を確保するための手順開発 前回からの繋がり: ビジネスプロセスで「何を・いつ・確実にデプロイするか」を計画した次は、デプロイ後に「実際にどれだけ信頼できるか」を定量化・管理する仕組みが必要。その仕組みが SLO・SLI・エラーバジェットとインシデント管理。

① 一言サマリー

信頼性を確保するための手順開発とは、「目標稼働率（SLO）を達成するために、実績値（SLI）を毎日測定し、予算枠（エラーバジェット）内で安全に変更・運用する仕組み」です。

② たとえ話

銀行の ATM サービス をイメージしてください：

• SLO（目標）：「月間 99.9% の稼働率を保つ」← 経営層が決めるビジネス要件
• SLI（実績）：「今月は 99.92% 稼働している」← 毎日計測する実績値
• エラーバジェット：「月間の計画停止時間 = (1 - 99.9%) × 43200 分 = 43.2 分」← この枠内なら新機能デプロイ・保守作業を実行してもいい
• インシデント管理：「ATM が突然止まった → すぐに復旧 → 『なぜ止まった？』を調査 → 同じ原因で二度と止まらないようにコード修正」

目標達成のために「測定 → 判定 → アクション」を毎日回すのが信頼性運用の本質。

③ 図解

graph LR
    A["SLO
目標稼働率
99.9%"] -->|測定| B["SLI
実績値
毎日集計"]
    B -->|判定| C{エラーバジェット
枠内か?}
    C -->|Yes| D["デプロイ・変更OK"]
    C -->|No| E["リスク管理
変更延期"]
    D --> F["インシデント
発生"]
    F --> G["復旧
RTO < 1時間"]
    G --> H["事後分析
ポストモーテム"]
    H --> I["改善実装
コード修正"]
    I --> B
    style A fill:#e1f5ff
    style B fill:#fff3e0
    style C fill:#f3e5f5
    style D fill:#c8e6c9
    style E fill:#ffccbc
    style G fill:#fce4ec
    style H fill:#f1f8e9

④ 仕組みの深掘り

（1）SLO / SLI / エラーバジェットの関係

SLO（Service Level Objective）= ビジネス目標

目標稼働率 99.9%（= 月間ダウンタイム 43 分）を設定する際の判定軸：

SLI（Service Level Indicator）= 実績値

毎日の実績を測定し、SLO に向けて進捗を可視化：

SLI = 成功トランザクション数 / 全トランザクション数

例：
- 今日のリクエスト 1000万件
- うち成功 9,990万件（失敗 1万件）
- SLI = 99.9% ✓ 目標達成

Cloud Monitoring で SLI を定義：

• レイテンシ SLI：「ユーザーリクエストに 200ms 以内で応答した割合」
• エラー率 SLI：「5xx エラーなく完了した割合」
• 利用可能性 SLI：「エンドポイントが応答を返した割合」

エラーバジェット（Error Budget）= 変更実行権

エラーバジェット = 1 年間のダウンタイム = (1 - SLO) × 年間秒数

例：99.9% SLO の場合
= 0.1% × 31,536,000 秒（1 年）
= 31,536 秒
= 約 8.76 時間 / 年
= 約 43 分 / 月

この枠を超えないように変更（デプロイ・保守）を管理：

• SLI が 99.9% を大きく上回る月 → エラーバジェット余裕あり → 大型デプロイ・リファクタリング OK
• SLI が 99.85% 付近 → エラーバジェット残少 → 小さい変更のみ、リスク高い変更は延期
• SLI が 99.8% 以下 → エラーバジェット枯渇 → 変更凍結、修正と調査に集中

PCA 試験での判定軸：「SLO 99.9% なら月 43 分、99% なら月 7 時間のエラーを許容する組織設計」

（2）インシデント管理と事後分析

インシデント の定義

• Sev 1（Critical）：サービス全体停止、3 時間以上のダウンタイム、顧客への金銭損失 → 即座に CEO / CTO 通知・全社停止
• Sev 2（High）：機能部分停止、1-3 時間ダウンタイム、顧客影響あり → 30 分以内に対応チーム招集
• Sev 3（Medium）：一部ユーザーのみ影響、30 分-2 時間ダウンタイム → 営業時間内に対応
• Sev 4（Low）：機能低下・警告ログ、ユーザー不便だが使える → バックログに積む、マージしてから対応

復旧の 2 つの指標

• RTO（Recovery Time Objective）：「目標復旧時間」← 事前に SLO から決めておく
• 99.99% SLA → RTO < 15 分（年間 52 分ダウンタイム）
• 99.9% SLA → RTO < 1 時間（年間 8.76 時間ダウンタイム）
• RPO（Recovery Point Objective）：「目標復旧時点データ」← データ損失許容量
• RPO < 1 分 = 1 分ごとにバックアップ（コスト 10 倍）
• RPO < 1 時間 = 1 時間ごとで十分（標準的）

インシデント対応の 4 段階

GCP での実装例：

Cloud Monitoring → Alert Policy（99.5% 以下なら発火）
  → Cloud Logging で原因特定（「2026-05-21 15:30 に memory spike」）
  → Cloud Trace で遅いエンドポイント特定
  → Cloud Profiler で「CPU 90% 消費する関数」を特定
  → コード修正 → Cloud Build で CI 実行 → Cloud Deploy で Canary 5% → Blue 100%
  → 24 時間後、ポストモーテム会議で「なぜ memory spike したか」を議論

（3）キャパシティプランニング

キャパシティ = 「最大負荷を安全に処理できるリソース量」

必要キャパシティ = ピーク負荷 × 安全マージン（1.2-1.5 倍）

例：
- 通常 QPS: 10,000
- ピーク QPS: 20,000（イベント時・昼12時）
- 安全マージン: 1.3 倍
→ 必要キャパシティ: 20,000 × 1.3 = 26,000 QPS で設計

3 つのプランニング軸

1. 計算（CPU / Memory）：Compute Engine / GKE の vCPU・メモリ枚数
2. ネットワーク（Bandwidth）：Cloud NAT / Cloud CDN の帯域幅、Interconnect 本数
3. ストレージ（I/O）：Cloud SQL / Bigtable の iops・スループット

予測の 3 段階

GCP での実装：

Cloud Monitoring で「過去 1 年の QPS 推移」を可視化
  → Trend Anomaly Detection で「異常検知」
  → キャパシティ足りなくなる 2-4 週間前に通知
  → MIG（Managed Instance Group）の max_replicas を増加
  → 自動スケーリング設定を事前更新

⑤ 他サービスとの使い分け

SLO 定義・管理

インシデント管理

⑥ 実務への応用

ケース 1：Web スタートアップ（初期段階）

SLO: 99%（月 7 時間のダウンタイム許容）
理由: 成長スピード > 完璧さ

エラーバジェット使用戦略：
- 毎日大型デプロイ（複数フィーチャー同時）
- 月間 2-3 回のインシデント許容
- ポストモーテムは「何が起きたか」のみ、再発防止は後付け

RTO: 4 時間（人手で対応、自動化なし）
RPO: 1 日（毎日バックアップ）

インシデント対応:
- Slack での通知のみ
- 手動ロールバック可能なコード設計

ケース 2：B2B SaaS（安定期）

SLO: 99.5%（月 3.5 時間）
理由: 顧客に「SLA 保証 99.5%」としてセール

エラーバジェット使用戦略：
- 週 1 回デプロイ（金曜は禁止）
- Canary 5% → Green 50% → Blue 100% で段階的リリース
- エラーバジェット消費量を毎日ダッシュボードで監視

RTO: 1 時間（自動フェイルオーバー + 手動復旧）
RPO: 15 分（リージョン間レプリケーション）

インシデント対応:
- PagerDuty で On-call スケジュール管理
- Sev 2 以上は 30 分以内に事後分析会議開催
- 3 ヶ月ごと「エラーバジェット消費パターン分析」

ケース 3：金融・決済（高信頼性）

SLO: 99.99%（年 52 分）
理由: 規制要件 + 顧客信頼 + ブランド損失回避必須

エラーバジェット使用戦略：
- 月 1 回デプロイ（計画済み変更ウィンドウ）
- エラーバジェット枯渇時は変更凍結
- 本番デプロイ前に Staging 環境で 1 週間 soak test

RTO: 5 分（複数地域・複数インスタンス同時実行）
RPO: 30 秒（同期レプリケーション）

インシデント対応:
- 15 分ごとに CEO・CFO に通知
- Sev 1 は全社で対応
- 48 時間以内に詳細なポストモーテム + 監査報告書

⑦ よくある誤解・落とし穴

誤解 1：「SLO = 実装の複雑さ」

❌ 誤り：99.99% SLO だから 5 つの地域、20 インスタンスで設計

✅ 正解：「ビジネス価値 = SLO 達成に必要な最小リソース」 - 99% SLO なら Compute Engine 1 インスタンス + 定期バックアップで十分 - 99.9% なら 2 インスタンス + 自動フェイルオーバー - 99.99% なら 3+ リージョン + Cloud Spanner（同期レプ）

PCA 試験：「SLO から逆算してアーキテクチャを選ぶ」思考が採点軸

誤解 2：「エラーバジェット = 浪費していい」

❌ 誤り：「月 43 分の枠があるから、テストなしで毎日デプロイ」

✅ 正解：「枠を超えないエリアで、可能な限り高速イテレーション」 - エラーバジェット残がある = 「変更してもいい」ではなく「変更してもいい枠」 - 10 人チームが全員変更実行したら 10 倍リスク増大 - Canary 5% ではじめて、99.95% 以上なら 100% へ段階的に

誤解 3：「ポストモーテムは『誰が悪いか』を決める会」

❌ 誤り：「エンジニア A が手動デプロイを間違えた → 減給」

✅ 正解：「システムの弱点を見つけ、自動化・ガード で二度と起きないようにする」 - ポストモーテムは「No Blame」原則（誰の責任も追求しない） - 焦点：「なぜ人間の手動作業が必要だった？」→ 「CI-CD パイプラインで自動化」 - 例：手動デプロイミス → Cloud Deploy の Canary で自動検証に

誤解 4：「キャパシティプランニング = リザーバーション購入」

❌ 誤り：「1 年分の Compute Engine インスタンスを定価で購入」

✅ 正解：「Commitment Discount（年間契約 25% 割引）+ Spot VM（70% 割引）の混在」 - 必要キャパシティ 26,000 QPS = 基本: Committed 20,000（価格固定）+ Spot 6,000（浮動価格） - Commitment 超過分は Spot で補い、コスト最適化

⑧ 理解度チェック

シナリオ 1：B2B SaaS の信頼性設計

ある B2B SaaS 企業が以下の要件でアーキテクチャを検討しています：

「顧客に SLA 保証 99.9% を提供し、ダウンタイムの影響を最小化したい。現在の SLI は 99.85%。月間エラーバジェット = 43 分。今月はすでに 35 分消費した。CTO は大型フィーチャー（API スキーマ変更）のデプロイを月末に計画。どうすべきか？」

シナリオ 2：インシデント対応とポストモーテム

ある決済システムで以下のインシデント発生：

「2026-05-21 14:30 に Cloud SQL Primary が Disk Full（ストレージ枯渇）で停止。Failover に 8 分かかり、その間トランザクション全て失敗。決済 50 万件が未確定ステータスで並ぶ。RTO 目標は 5 分。ポストモーテムで、エンジニア X が『Disk Monitoring アラートを見落とした』と指摘されている。会社は X を処分すべき？」

⑨ 深掘り補足（実務の応用知識）

最新 GA 機能の活用

1. Cloud Monitoring の SLO API（GA）

GCP ネイティブな SLI 定義・追跡：

# SLO 定義例：成功率 99.9%
SLO:
  target: 0.999
  window: 30 days

indicator:
  type: request_based
  query: |
    resource.type = "api"
    metric.response_code_class = "2xx" OR "3xx"

alert:
  threshold: 0.99  # 99% 下回ったら通知
  duration: 5m

Benefits： - Cloud Console で SLI 進捗を日次ダッシュボード表示 - エラーバジェット消費速度を可視化 - Threshold ベース アラートで変更リスク判定（自動化可）

2. Cloud Logging API MCP Server（GA）と Cloud Monitoring MCP Server（GA）

⚠️ 2026-05 最新 GA リリース

AI agent・Gemini Enterprise と統合して、インシデント分析を自動化：

インシデント検出 
  → Cloud Monitoring MCP（メトリクス取得）
  → Cloud Logging MCP（ログ分析）
  → Gemini Agent（「CPU spike の原因は？」を自動質問応答）
  → ポストモーテムドラフト自動生成

実務への効果： - 手動ログ検索 30 分 → AI による分析 3 分 - ポストモーテムの初期ドラフト自動作成（レビュー修正のみ） - 深夜のインシデント対応時に AI が根本原因を提示

3. Ops Agent での OpenTelemetry Telemetry API（Preview）

⚠️ Preview

従来の Cloud Logging API / Cloud Monitoring API に加えて、OpenTelemetry 標準で メトリクス・トレース・ログを統合：

Application Code
  → OpenTelemetry Instrumentation
  → Ops Agent v2.66.0+
  → Telemetry API（新・標準化）
  → Cloud Monitoring / Cloud Logging

Benefits： - クラウドベンダーロックインが軽減（他クラウドへの移行が容易） - トレース・メトリクス・ログの相関分析が自動化

次回: 5.1 開発/運用チームへのアドバイス（IaC・Terraform・構成管理）