PCDBE 合格対策
🔬 SRE DEEP DIVE

Observability ディープダイブ

Cloud Operations Suite (旧 Stackdriver) を駆使した Metrics / Logs / Traces の三本柱。Query Insights / Cloud Audit Logs / Cloud Trace / OpenTelemetry 実装パターン。

📑 目次

  1. 1. Observability の 3 本柱
  2. 2. Cloud Monitoring の活用
  3. 3. Cloud Logging — ログ集約と分析
  4. 4. Cloud Audit Logs — 監査ログの活用
  5. 5. Cloud Trace + OpenTelemetry
  6. 6. Query Insights ディープダイブ
  7. 7. ダッシュボード設計
  8. 8. アラート設計の Anti-pattern
  9. 9. ログエクスポートと長期保管
  10. 10. Observability のコスト管理

1. Observability の 3 本柱

📊 Metrics

  • 数値時系列データ
  • 例: CPU 利用率、QPS
  • 傾向と異常検出

📜 Logs

  • 構造化テキスト
  • 例: クエリログ、エラーログ
  • 調査・トラブルシュート

🔍 Traces

  • 分散トレース
  • 例: API → DB の伝播経路
  • ボトルネック特定
3 本柱を組み合わせる: メトリクスで「何かおかしい」と気付き、ログで「何が起きたか」を確認、トレースで「どこで起きたか」を特定する。

2. Cloud Monitoring の活用

2-1. DB ごとの主要メトリクス

Cloud SQL

メトリクス用途
cloudsql.googleapis.com/database/cpu/utilizationCPU 利用率
cloudsql.googleapis.com/database/memory/usageメモリ使用量
cloudsql.googleapis.com/database/disk/utilizationストレージ利用率
cloudsql.googleapis.com/database/network/connectionsアクティブ接続数
cloudsql.googleapis.com/database/replication/replica_lagレプリ遅延（秒）
cloudsql.googleapis.com/database/postgresql/transactions/aborted_count失敗トランザクション数（Postgres）

Spanner

メトリクス用途
spanner.googleapis.com/instance/cpu/utilization_by_priority優先度別 CPU 利用率（HIGH を 65% 以下に）
spanner.googleapis.com/api/request_latenciesAPI レイテンシ p50/p95/p99
spanner.googleapis.com/api/api_request_countAPI 呼び出し回数（ステータス別）
spanner.googleapis.com/instance/storage/used_bytesストレージ使用量

Bigtable

メトリクス用途
bigtable.googleapis.com/server/latenciesサーバーサイド レイテンシ
bigtable.googleapis.com/cluster/cpu_loadクラスタ CPU 利用率
bigtable.googleapis.com/cluster/storage_utilizationストレージ利用率
bigtable.googleapis.com/replication/latencyレプリ遅延

2-2. MQL (Monitoring Query Language)

Cloud Monitoring の高度クエリ言語。複雑な集計や演算をサポート。

# MQL 例: Cloud SQL の CPU 利用率を1時間平均で集計
fetch cloudsql_database
| metric 'cloudsql.googleapis.com/database/cpu/utilization'
| filter resource.database_id == 'project:my-db'
| group_by 1h, [value_avg: mean(value.utilization)]
| every 1h

3. Cloud Logging — ログ集約と分析

3-1. ログの種類

ログタイプ内容
cloudsql.googleapis.com/postgres.logPostgreSQL 標準ログ
cloudsql.googleapis.com/mysql-general.logMySQL 一般ログ
cloudsql.googleapis.com/mysql-slow.logMySQL スロークエリログ
cloudaudit.googleapis.com/activity管理操作ログ
cloudaudit.googleapis.com/data_accessデータアクセスログ

3-2. ログクエリ例

スロークエリ検索（Cloud SQL PostgreSQL）

resource.type="cloudsql_database"
log_id("cloudsql.googleapis.com/postgres.log")
textPayload =~ "duration: [0-9]{4,}"

エラーログ抽出

resource.type="cloudsql_database"
severity >= "ERROR"
textPayload =~ "FATAL|PANIC"

特定インスタンスへの SELECT クエリ

resource.type="cloudsql_database"
resource.labels.database_id="my-project:my-db"
log_id("cloudsql.googleapis.com/postgres.log")
textPayload =~ "SELECT"

3-3. ログベースメトリクス

ログ内の特定パターンをカスタムメトリクスとして集計可能。

例: PostgreSQL の deadlock 発生回数 1. ログクエリ: textPayload =~ "deadlock detected" 2. ログベースメトリクスとして登録: 名前: postgresql_deadlock_count タイプ: COUNTER 3. Cloud Monitoring で時系列グラフ + アラート

4. Cloud Audit Logs — 監査ログの活用

4-1. 4 種類の監査ログ

種類内容有効化
Admin Activity リソース変更（CREATE / DELETE 等） 常時有効、無料
Data Access データ読み書き 明示有効化、有料
System Event システムイベント 常時、無料
Policy Denied ポリシー拒否 常時、無料

4-2. Data Access ログの活用

Data Access ログは大量に発生してコストが嵩む。すべての DB アクセスをログ化すると月数万円〜。

4-3. 監査要件への対応

金融機関・医療機関の規制（GDPR、SOX、HIPAA）では、誰が・いつ・何にアクセスしたかの記録保持が要求される。Cloud Audit Logs を Log Sink で BigQuery へエクスポート → 7年保管のパターンが典型。

5. Cloud Trace + OpenTelemetry

5-1. 分散トレースの考え方

ユーザー Request ├ [API Gateway] 500ms │ ├ [Auth Service] 50ms │ ├ [Catalog Service] 100ms │ │ └ [Cloud SQL] 80ms ← ここがボトルネック │ └ [Payment Service] 200ms │ └ [Cloud SQL] 50ms └ レスポンス

5-2. OpenTelemetry 導入パターン

2026年現在、Cloud Trace はOpenTelemetry (OTel) をフルサポート。Cloud Trace API への直接送信よりも、OTel collector 経由が推奨。

導入手順:
  1. アプリに OpenTelemetry SDK を組み込み（Java/Go/Python/Node など）
  2. DB クライアントの自動計装（auto-instrumentation）を有効化
  3. OTel Collector を Sidecar / Daemon として配置
  4. Collector が Cloud Trace へ送信
  5. Cloud Trace UI でトレース確認 + ボトルネック特定

5-3. DB クエリレベルのトレース

OTel の DB 自動計装で、各 SQL クエリの実行時間がトレース span として記録される。これにより「アプリのどの処理が DB を遅くしているか」がトレースから即座に判明。

6. Query Insights ディープダイブ

6-1. Query Insights が見せるもの

Query Insights 画面 ┌─────────────────────────────────────────────────┐ │ 時系列グラフ: CPU 利用率 / クエリレイテンシ p99 │ ├─────────────────────────────────────────────────┤ │ Top クエリ (CPU 消費トップ N) │ │ - クエリテキスト │ │ - 実行回数 / 平均実行時間 / I/O │ │ - ユーザー / アプリ識別 │ ├─────────────────────────────────────────────────┤ │ Wait Events (待機イベント分析) │ │ - Lock / Buffer / IO / CPU │ │ - どこで時間が消費されているか │ ├─────────────────────────────────────────────────┤ │ 実行計画 (EXPLAIN) │ │ - Seq Scan / Index Scan の判定 │ │ - 推定行数 vs 実際の行数 │ └─────────────────────────────────────────────────┘

6-2. Query Insights の活用パターン

パターン A: 突然のレイテンシ悪化

  1. Cloud Monitoring でレイテンシ p99 増加を検知
  2. Query Insights で同時刻の Top クエリを確認
  3. 新規に頻出している SQL を特定
  4. EXPLAIN で実行計画確認 → インデックス不足判明
  5. インデックス追加 → 改善確認

パターン B: Wait Event 分析

Wait Event意味対応
Lock:transactionidロック競合アプリのトランザクション順序見直し
BufferIOディスク I/O 待機buffer 不足、メモリ増 or ワーキングセット削減
CPUCPU 待機マシンタイプアップ or クエリ最適化
Clientクライアント待機アプリ側のボトルネック

7. ダッシュボード設計

7-1. 階層型ダッシュボード

[LEVEL 1: Executive Dashboard] - サービス全体の SLO 達成状況 - 月次トレンド (アクセス数、エラー率、コスト) - インシデント数 [LEVEL 2: Service Dashboard] - API レイテンシ (p50/p95/p99) - エラー率 - 上流 → 下流の依存 [LEVEL 3: DB Dashboard] - 各 DB の主要メトリクス - レプリ遅延、接続数 - Top クエリ [LEVEL 4: Diagnostic Dashboard] - 詳細メトリクス - ログ集約 - トレース可視化

7-2. Golden Signals

Google SRE Book が定義する 「4つの黄金信号」。すべての本番サービスで監視すべき基本指標。

信号意味DB での例
Latency応答時間クエリ p99 レイテンシ
Traffic負荷量QPS, 接続数
Errorsエラー率クエリ失敗率, タイムアウト数
Saturation飽和度CPU/メモリ/ストレージ利用率

8. アラート設計の Anti-pattern

典型的なアラート Anti-pattern:

8-1. 良いアラートの 5 つの条件

  1. Actionable: 受信したら明確なアクションがある
  2. Symptom-based: 原因ではなく症状でアラート（「DB CPU 80%」より「クエリ p99 が SLO 超過」）
  3. Right Severity: 重要度を正しく分類（P1〜P4）
  4. Sufficient Context: アラートに Runbook URL を含める
  5. Tested Regularly: 鳴っているアラートを四半期にレビュー

9. ログエクスポートと長期保管

9-1. Log Sink によるエクスポート

Cloud Logging ↓ Log Sink (フィルター条件) ┌────────────────────────┬──────────────────┐ ↓ ↓ ↓ BigQuery Cloud Storage Pub/Sub (分析・長期保管) (Archive) (リアルタイム連携)

9-2. 監査要件への対応

要件保管先保持期間
金融 (SOX)BigQuery + GCS Archive7 年
医療 (HIPAA)BigQuery + GCS Archive6 年
GDPRBigQuery業務要件次第
PCI-DSSBigQuery + 改ざん防止 GCS1 年以上

10. Observability のコスト管理

10-1. ログコストの落とし穴

Data Access ログを全 Cloud SQL インスタンスで有効化すると、月数万円〜のログ料金が発生する場合がある。
特に DEBUG レベルのログを保持すると容量爆発。

10-2. コスト削減パターン

  1. Log Routing で必要なログだけ Cloud Logging に取り込む（ノイズログは除外）
  2. 長期保管は GCS Archive クラスへ（Logging より大幅安価）
  3. BigQuery に取り込む際はパーティション + クラスタリングで分析コスト削減
  4. Custom メトリクスのcardinalityを抑える（ラベル組み合わせを減らす）
  5. 不要になったログベースメトリクスは削除

10-3. 可視化ツール選択

用途推奨ツール
標準的なメトリクス可視化Cloud Monitoring Dashboards (無料)
BI / ビジネス向けLooker / Looker Studio
カスタム高度可視化Grafana (Cloud Monitoring プラグイン)
APM 統合Datadog / New Relic (3rd party)

📋 Observability の試験ポイント

PCDBE で Observability に関連する出題:
  1. 「スロークエリ調査」 → Query Insights
  2. 「監査要件 + 長期保管」 → Audit Logs + Log Sink → BigQuery/GCS Archive
  3. 「分散トレース」 → Cloud Trace + OpenTelemetry
  4. 「アラート設計」 → 5分継続 + Notification Channel 分離
  5. 「ログコスト爆発」 → Log Routing + サンプリング
公式参考リソース