Section 6: 運用卓越性 — 🔧 応用編

対象: 実務 3-5 年 / GCP 経験あり / SRE プラクティス・SLO 設計・Chaos / Pentest 実践 を体系化したい人。 目標: 試験で問われる「正しい運用判断」と「Observability の設計」を高精度で出せるようになる。

1. Operational Excellence Pillar の深堀り

5 原則の運用への落とし込み

Toil（労力）の削減

Toil = 手作業・反復的・自動化可能な労働。SRE では Toil を 50% 以下 に抑えることを目標にする。

例:

• 毎週のレポート生成 → スクリプト化
• アラート対応 → ランブック → 自動修復
• ユーザー問い合わせ → セルフサービス化

試験頻出: 「Toil 削減」= 自動化 + セルフサービス化 + Runbook 化。

2. Cloud Monitoring の応用

Metrics の種類

カスタムメトリクスの実装

from google.cloud import monitoring_v3
from google.cloud.monitoring_v3 import MetricServiceClient

client = MetricServiceClient()
project_name = f"projects/{PROJECT_ID}"

series = monitoring_v3.TimeSeries()
series.metric.type = "custom.googleapis.com/orders_completed"
series.metric.labels["region"] = "asia-northeast1"
series.resource.type = "global"

point = series.points.add()
point.value.int64_value = 42
client.create_time_series(name=project_name, time_series=[series])

Workspaces / Metrics Scope

複数プロジェクトのメトリクスを 1 つのスコープ で見るための仕組み。

Metrics Scope（旧 Workspace）
  ├── Project A
  ├── Project B
  ├── AWS Account（連携）
  └── オンプレ（OpenTelemetry / Prometheus）

Cloud Monitoring と OpenTelemetry

OpenTelemetry は 業界標準のトレース・メトリクス・ログ統合プロトコル。GCP は OTel をネイティブサポート。

アプリ → OpenTelemetry SDK → OTel Collector → Cloud Monitoring / Trace

試験頻出: 「マルチクラウド・ベンダーロックイン回避」→ OpenTelemetry。

3. Cloud Logging の応用

Log Sinks（重要）

ログの 転送先 を定義する仕組み。組織レベル / フォルダ / プロジェクトで設定可能。

Aggregated Sink（集約 Sink）

組織全体のログを 1 ヶ所に集約。セキュリティ・コンプラに重要。

組織レベル Aggregated Sink
  └── 全プロジェクトの Audit Log を BigQuery に集約
        ↓
      長期保管 + SQL 分析

Log Buckets と保持

Log Analytics

BigQuery 上で Log Bucket を SQL クエリ可能 にする機能。コスト効率良くログ分析。

-- Cloud Logging のログを直接 SQL で
SELECT
  resource.labels.cluster_name,
  COUNT(*) AS error_count
FROM `project.location.LOG_BUCKET._AllLogs`
WHERE severity = 'ERROR'
GROUP BY 1
ORDER BY 2 DESC

Audit Logs の 4 種

試験頻出: 「Data Access ログはデフォルト無効」。コンプラ要件で必要なら明示的に有効化。

4. SLO 設計の詳細

SLO 設計の 6 ステップ

1. ユーザーの体験を特定（重要なユーザージャーニー）
2. SLI を選ぶ（Availability / Latency / Error Rate / Throughput / Quality）
3. 測定方法を決める（クライアント側？サーバー側？LB 経由？）
4. 目標値を決める（過去実績の上 + ビジネス要件）
5. エラーバジェット運用ルールを決める
6. 定期レビュー（四半期）

SLI のラベリング（Good / Total）

SLI = Good Events / Total Events

例 1: HTTP 成功率
  Good = HTTP 2xx, 3xx, 4xx（5xx を除外する判断もあり）
  Total = 全リクエスト

例 2: Latency
  Good = p99 が 200ms 以下のリクエスト
  Total = 全リクエスト

Cloud Monitoring の SLO 機能

GCP Console / API で SLO オブジェクト を作成。

エラーバジェット運用ルールの例

エラーバジェット残量で運用判断:

100% 残存       → 新規機能リリース自由、信頼性投資は最小
50% 以上残存    → リリース通常、軽い信頼性投資
50% 未満        → リリース慎重、信頼性投資強化
枯渇            → 機能リリース全面停止、信頼性対応集中

5. Multi-window / Multi-burn-rate アラート

Burn Rate とは

エラーバジェットの 消費速度。SLO 期間で予算を使い切るペースの倍率。

SLO: 99.9%（月予算 0.1% = 43.2 分）
Burn Rate 1x: 月末ちょうど予算消化（正常）
Burn Rate 14.4x: 1 時間で月予算の 2% 消費（緊急）

Google SRE Workbook の推奨アラート

Multi-window / Multi-burn-rate 設計

短時間ウィンドウ（5 分）と長時間ウィンドウ（1 時間）の AND で発火させ、短期スパイクで誤検知 を防ぐ。

Critical Alert =
  (Burn Rate > 14.4 over 5 min) AND (Burn Rate > 14.4 over 1 hour)

試験頻出: 「症状ベース」「Burn Rate ベース」のアラートが SRE の標準。

静的しきい値の限界

旧: 「CPU 80% 超でアラート」 → 環境変化で意味が変わる
新: 「SLO Burn Rate ベース」 → ユーザー影響に基づく

6. Cloud Trace と OpenTelemetry

分散トレースの設計

OpenTelemetry の構成

アプリ (OTel SDK)
   ↓ OTLP protocol
OTel Collector（オプション、エッジ集約）
   ↓
Cloud Trace / Cloud Monitoring / Logging

サンプリング

Trace と Profiler の使い分け

7. Alerting Policies の詳細

Alert Policy の構造

Alert Policy
├── Condition（条件）
│   ├── Metric Type
│   ├── Filter
│   ├── Aggregation
│   ├── Threshold
│   └── Duration（持続時間）
├── Notification Channels
├── Documentation（Runbook へのリンク）
└── Severity（Critical / Warning / Info）

Forecast-based Alert（最新）

メトリクスの 予測 に基づくアラート。リソース枯渇を事前察知。

例:

• 「ディスク使用率が 7 日以内に 90% に達する見込み」
• 「現在のペースだと月末にクォータ枯渇」

MQL / PromQL

Notification Channels の運用

8. デプロイ・リリース管理の応用

Cloud Deploy の Canary 設計（詳細）

strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true
    canaryDeployment:
      percentages: [5, 25, 50]
      verify: true   # 各段階で verify ステップ実行

Verify ステップ

各 Canary 段階の 検証スクリプト を Cloud Build Job で実行。失敗時は自動ロールバック。

例:

• スモークテスト
• SLO 達成チェック
• カスタム E2E

Progressive Delivery

Canary + Feature Flag + Observability の組合せ。

1. コード本番デプロイ（Feature Flag OFF）
2. Flag を 1% ユーザーに ON
3. SLO・エラー率を確認
4. 5% → 25% → 50% → 100% に拡大
5. 問題発生 → Flag OFF（コードはそのまま）

GitOps による Continuous Delivery

Config Sync / Policy Controller

[Config Sync] = Git → K8s クラスタへ宣言的に同期
[Policy Controller] = OPA/Gatekeeper で K8s リソースを検証

9. インシデント対応の応用

Incident Command System (ICS)

大規模障害時の 役割分担モデル。

Status Page

• 公開: Statuspage、Atlassian、PagerDuty
• 内部: Confluence、Notion、Google Site

Postmortem の Five Whys 例

障害: 注文 API が 30 分応答停止
Why 1: DB 接続枯渇
Why 2: 接続プール上限の 100 を超過
Why 3: 旧バージョンが接続を返さないバグ
Why 4: 単体テストはあったが、長時間負荷テストがなかった
Why 5: パイプラインに長時間負荷テストが組込まれていなかった

→ 再発防止策: CD パイプラインに 30 分の長時間負荷テストを追加。

Blameless Postmortem の鉄則

• 「誰が」ではなく「何が」を問う
• 個人の責任追及禁止
• システム・プロセスの改善に集中
• 共有して組織全体で学ぶ

10. Chaos Engineering の実践

Chaos Engineering 4 原則

1. 定常状態の仮説を立てる（SLO 達成状態）
2. 現実世界の事象を変数として扱う
3. 本番環境（または近い環境）で実験
4. 自動化して継続実行

段階的な導入

GKE Chaos の代表手法

Game Day の計画

1. シナリオ作成（例: us-central1 ゾーン a が停止）
2. 影響予測（どのサービスが落ちるか）
3. 実施時刻決定（事前告知 or 抜き打ち）
4. 監視・対応・記録
5. Debrief（学んだこと、改善点）

試験頻出: 「定期的に障害対応訓練」→ Game Day。

11. Penetration Testing と Security Audit

Pentest の流れ

1. スコープ定義（対象システム、許可範囲）
2. 偵察（公開情報収集、ポートスキャン）
3. 脆弱性特定（既知 CVE、設定ミス）
4. 攻撃（実際に侵入を試みる）
5. 影響評価（取得可能データ、横展開可能性）
6. レポート（リスク、再現手順、対策提案）
7. 修正と再検証

GCP での Pentest

• 事前申請不要（公開規約に従う）
• 禁止: DDoS、他テナント影響、SLA 影響
• 推奨: 本番に影響しない時間帯、対象を IP/プロジェクトで限定
• 自社・第三者のどちらでも可

GCP セキュリティ統制

Continuous Security

12. Load Testing の応用

キャパシティ計画

1. 想定ピーク負荷を定義（例: ブラックフライデーで 10x）
2. 現在の負荷耐性を測定（Load Test）
3. ボトルネック特定（CPU / DB / NW）
4. スケール戦略決定（Autoscaling、Spanner / GKE 増設）
5. SLO 達成範囲を確認

ロードテストの種類

GCP での負荷テスト構成例

[負荷生成]
  GKE で Locust 分散実行（マスター 1 + ワーカー N）
  Cloud Build からトリガー
[ターゲット]
  本番に近い Staging 環境
[観測]
  Cloud Monitoring / Trace で性能測定
  SLO 達成範囲を記録

13. Continuous Compliance の応用

Policy as Code

[Organization Policy] = GCP リソースの強制ポリシー
[Policy Controller (Gatekeeper)] = K8s リソースの強制ポリシー
[Open Policy Agent (OPA)] = 汎用 Policy エンジン

代表的な Organization Policy

Assured Workloads

規制業界（HIPAA、FedRAMP、IL4、CJIS）向けの コンプラ環境。

• リージョン制限、US Person 限定オペレーション等を強制
• 設定が固定され、誤設定リスクを下げる

Continuous Compliance Scanning

14. Gemini Cloud Assist の運用活用（最新）

Investigations 機能

障害発生時、自然言語で質問すると 関連リソース・ログ・メトリクスを横断分析。原因仮説と対処方法を提示。

ユーザー: 「Cloud Run service-a が直近 1 時間で 5xx 増加。原因は？」
   ↓
Gemini Cloud Assist:
  - service-a の SLO Burn Rate: 8x（過剰）
  - 関連ログ: Cloud SQL 接続タイムアウト多発
  - 関連メトリクス: Cloud SQL CPU 95%
  - 原因仮説: Cloud SQL のクエリ過負荷
  - 対処提案: クエリ最適化 / インスタンス昇格
  - 関連 Runbook: ...

Log Analytics + Gemini

ユーザー: 「直近 1 時間の error log を要約して」
Gemini:
  - 大半は OOMKilled
  - 集中時間帯: 14:30-14:45
  - 影響 Pod: 12 個
  - 修復提案: メモリ Limit を 1Gi → 2Gi

Alert Summarization

複数の連動アラートを 1 つにまとめて表示。

15. 信頼性に関する重要な考え方

信頼性 vs コスト

99% → 99.9%: 10x コスト
99.9% → 99.99%: 10x コスト
99.99% → 99.999%: 10x コスト

ユーザーが感じる信頼性 を見極め、過剰投資を避ける。

多層防御（Defense in Depth）

Layer 1: ネットワーク（Cloud Armor, VPC SC）
Layer 2: 認証（IAM, OAuth）
Layer 3: 認可（最小権限）
Layer 4: データ（暗号化、CMEK）
Layer 5: 監視（SCC, Cloud Logging）
Layer 6: インシデント対応（Chronicle）

Graceful Degradation

完全に失敗するのではなく 機能を縮退 する設計。

例:

• レコメンドが落ちたら一般人気商品を表示
• DB レプリカが落ちたらキャッシュから読む
• 一部マイクロサービスが落ちても主機能は継続

Failure Domain

「何が同時に壊れるか」を意識した冗長化設計。

1 リージョン < 1 ゾーン < 1 ノード < 1 Pod
↑ broader failure domain     narrower ↓

冗長化はより広い Failure Domain に対しても効くべき。

16. 運用卓越性のトレードオフ例

ケース 1: SLO 99.9% vs 99.99%

要件: 月 1 回のメンテ + 機能リリース重視

• 99.9% SLO → エラーバジェット 43 分 / 月 → 余裕あり
• 99.99% SLO → エラーバジェット 4.3 分 / 月 → メンテ不可能

→ 99.9% を選択（リリース速度確保）

ケース 2: アラート全部 PagerDuty vs Burn Rate ベース

要件: オンコール疲弊を防ぎたい

• A: 全 Critical を PagerDuty → 月 100 件、疲弊
• B: Burn Rate Multi-window → 月 5 件、本質的

→ B を採用（アラート疲れ防止）

ケース 3: Chaos Engineering を本番で？

要件: ミッションクリティカル、過去に大規模障害

• A: 本番で Chaos 実施 → リスク高
• B: Staging でのみ → 本番との差分でリスク残る
• C: 本番で限定的（夜間、1 サービス、自動修復確認） → 段階導入

→ C を採用（段階的に成熟度に応じて拡大）

17. 章末まとめ

必ず覚える「運用卓越性の翻訳パターン」

次のステップ

• 直前確認: 03_要点と暗記.md
• 関連セクション: Section 1（設計）、Section 5（実装管理）