📚 GCP PCA 学習: 2026-06-29

セクション: 6.1 モニタリング・ロギング・プロファイリング・アラートの設計 前回からの繋がり: SDK で構築・デプロイしたシステムを本番運用するために、「何が起きているか」「なぜ遅いか」「いつエラーが起きたか」を把握する仕組み

① 一言サマリー

「モニタリング・ロギング・プロファイリング・アラート」とは、一言でいうと本番システムの健全性を 24/7 計測し、問題を自動検出・通知する仕組みです。

② たとえ話

あなたが飲食店を経営しているとします。

• Cloud Monitoring（メトリクス）= 毎時間、お客さんの来客数・売上・待ち時間を記録するノート
• 「14時に来客数が 20人 → リアルタイムで計測」
• ダッシュボード = 壁に張ったグラフで「今日の売上傾向」が一目瞭然

• アラートポリシー = 「来客が 0人になったら（営業不可）、店長に電話」

• Cloud Logging（ログ）= 毎日の営業日誌

• 「14:30 にクレーム発生」「15:00 に食材切れ」「16:15 に決済システム故障」

• 詳細に記録しておくと、「火曜の 15時いつもシステム止まるね」という規則性が見える

• Cloud Trace（分散トレース）= 1 つの注文が「受付 → キッチン → 会計」の各工程でかかった時間

• 「注文時間 30秒 → 料理時間 10分 → 会計時間 2分 = 合計 10分 32秒」

• どの工程が遅いかが一目瞭然

• Cloud Profiler（パフォーマンス分析）= キッチンスタッフの「どの作業に時間がかかるか」をストップウォッチで測定

• 「野菜切り 30% 、調理 50% 、盛り付け 20%」

• CPU・メモリ・I/O の詳細な消費パターンを把握

• Error Reporting（エラー検出）= クレーム内容をカテゴリ分類

• 「支払い忘れ 5件」「食べ物の鮮度不足 2件」 → 同じ問題なら一括対応

③ 図解

graph LR
    AppA[アプリケーション] -->|メトリクス|Monitoring[Cloud Monitoring
CPU・メモリ・レイテンシ]
    AppA -->|ログ行|Logging[Cloud Logging
ログルーター・シンク]
    AppA -->|リクエスト追跡|Trace[Cloud Trace
分散トレース]
    AppA -->|CPU・メモリ|Profiler[Cloud Profiler
パフォーマンス]
    AppA -->|エラー|ErrorRpt[Error Reporting
エラー集約]

    Monitoring --> Alerting[Alert Policy
閾値超過 → 通知]
    Logging --> Dashboard[ダッシュボード
可視化]
    Trace --> Dashboard

    Alerting -->|Email・Slack| Notify[通知]

④ 仕組みの深掘り

Cloud Monitoring（メトリクス収集・アラート）

メトリクス = 時系列数値データ（CPU、メモリ、レイテンシなど）

• Metric Descriptor：メトリクスの名前・単位・型を定義（例：compute.googleapis.com/instance/cpu/utilization）
• Time Series データ：各メトリクスが 1 分・5 分・1 時間単位で自動集計される
• GCP は全 VM / Workload の CPU・メモリを自動計測→ 追加インストール不要

• カスタムメトリクス：アプリケーション内で client.timeseries().create() を呼ぶと、独自メトリクス（例：ビジネス指標「1日のアクティブユーザー数」）も送信可能

• Monitoring Agent（推奨）：ディスク I/O・ネットワーク・プロセスメモリなど、VM 内部の詳細メトリクスを収集

• google-cloud-ops-agent（新）を GCE に インストール → Monitoring に自動送信

• Kubernetes は kubelet が自動的にメトリクス露出

• Alert Policy（アラート）

• 閾値ベース：「CPU > 80% が 5分続いたら → Slack に通知」
• リソース欠損：「リソースが削除されたら → メール通知」
• 複合条件：「（CPU > 80% AND メモリ > 90%）が 10分続いたら → PagerDuty」
• Notification Channel：Email・Slack・PagerDuty・Cloud Pub/Sub・SMS など複数選択可

Cloud Logging（ログ収集・分析）

ログ = テキスト形式のイベント記録（アプリケーション / システム）

• Log Ingestion（自動）
• GCP サービス（Cloud Run・GKE・Compute Engine）は自動的にシステムログを Logging に送信

• アプリケーションログ：stdout/stderr に出力 → Logging に自動キャプチャ

• Log Router（ルーティング）

• ログ到着時に resource.type = "gke_container" など条件でフィルタリング

• 複数の Sink（宛先）へ振り分け

  • Cloud Storage（長期保存・コンプライアンス）
  • BigQuery（分析・SQL クエリ）
  • Cloud Pub/Sub（リアルタイム処理・ストリーミング）
  • 別の Cloud Project（マルチテナント SaaS）

• Log Query

• Cloud Logging UI で resource.type="gke_pod" AND severity="ERROR" のようにフィルタリング

• MQL（Monitoring Query Language）で時系列ログメトリクスを抽出

• Log-based Metrics

• ログから自動的にメトリクスを抽出（例：ログの ERROR 出現数をメトリクス化）
• ERROR ログが 10回以上出たら アラート → 素早い検出

Cloud Trace（分散トレース）

分散トレース = 1 つのリクエストがマイクロサービス群を通過する際の遅延分析

• Span：各サービスが処理した期間（例：「API Gateway 10ms → Auth Service 50ms → Database 200ms」）

• Trace：複数 Span の組み合わせ（リクエスト全体の経路）

• 自動計測

• Cloud Run は自動的にトレース情報を記録

• GKE は OpenTelemetry ライブラリで計測（Spring Cloud Sleuth などの標準ライブラリ）

• 用途

• 「注文 API が 5秒かかるのはなぜ？」→ Trace を見ると「Database クエリが 4.8秒」と判定
• Tail latency 問題（99 パーセンタイル）の原因特定

Cloud Profiler（パフォーマンス分析）

Profiler = CPU・メモリ・I/O の詳細な消費パターンを統計的に分析

• Continuous Profiling：本番環境で 24/7 CPU・メモリサンプリング（オーバーヘッド < 1%）
• Flame Graph：どの関数がどのくらい CPU 時間を食っているか可視化
• 「function_A 30%、function_B 40%、その他 30%」

• Memory Profiler：メモリリークを検出（確保メモリが徐々に増える関数を特定）

• 言語別対応

• Java / Go / Node.js / Python / Ruby：標準サポート
• カスタムコードでも OpenTelemetry で計測可能

Error Reporting（エラー検出・集約）

Error Reporting = ログから自動的にエラーを抽出・グループ化・集計

• 自動検出：ログに "ERROR" または "FATAL" が含まれるエントリを自動キャプチャ
• エラーグループ化：スタックトレースが同じ = 同じエラー と自動判定

• 「NullPointerException at line 42」が 100 回出ても「1 つのエラー」とグループ化

• 用途

• ダッシュボード：「エラー発生率 0.5%」「過去 1時間に新規エラー 3件」
• アラート：「新しいエラーが発生したら Slack」

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

Cloud Monitoring vs. 他のメトリクス収集

PCA 判断軸：「GCP サービスのメトリクスを集約する」なら Cloud Monitoring 一択。多クラウド環境なら Datadog が検討対象。

Cloud Logging vs. BigQuery / Cloud Storage

PCA 判断軸： - 即時検索 → Cloud Logging - 過去 1ヶ月の傾向分析 → BigQuery + Sink で自動連携 - 7年保存（GDPR） → Cloud Storage + Lifecycle

Cloud Trace vs. Application Performance Monitoring（APM）

PCA 判断軸：GCP マイクロサービスの latency 問題なら Cloud Trace。既存 APM ツール（Datadog）がある場合は「OpenTelemetry Collector で統合」も選択肢。

Cloud Profiler vs. Prometheus（メトリクス専用）

PCA 判断軸：「関数レベルの CPU 時間を分析」なら Profiler。「ビジネス指標（売上・APIコール数）を計測」なら カスタムメトリクス（Prometheus 互換）。

⑥ 実務への応用

シナリオ 1：Web サービス（Cloud Run）の本番運用

要件 - ユーザーが「アプリが遅い」と報告 → 原因を 5分以内に特定したい - SLA 99.9%（月 43分 downtime 許容） → エラーを自動検出・アラート

実装 1. Cloud Monitoring ダッシュボード： - Cloud Run の レスポンスタイム（p50・p95・p99） - エラー率（5xx エラー / 全リクエスト） - 同時実行数

1. Cloud Logging：
2. stdout に JSON ログ出力（timestamp・severity・request_id・error_msg）

3. severity="ERROR" のログを BigQuery に自動 Sink → 日次分析

4. Cloud Trace：

5. Cloud Run 内部ロジック + 外部 API コール（データベース・決済 API）の latency 分析

6. 「決済 API が 3秒かかってる」と検出

7. Alert Policy：

8. レスポンスタイム p99 > 2秒 が 5分続いたら → Slack

9. エラー率 > 1% が 2分続いたら → PagerDuty（本番 on-call エンジニア起動）

10. Error Reporting：

11. 「PaymentService の NullPointerException」が 10回以上 → 開発チームに Slack
12. 「新規エラー検出」で dev team がその日のうちに対応

結果：ユーザーからの報告を待たず、アラートで 事前検出。RCA（根本原因分析）が 30分以内に完了。

シナリオ 2：マイクロサービス（GKE）の分散トレース

要件 - API Gateway → Auth Service → Product Service → Database - 各マイクロサービスは異なるチーム開発 - 「エンドツーエンドで 3秒かかる」をブレークダウン

実装 1. Cloud Trace（OpenTelemetry）： - 各 Pod に OpenTelemetry SDK インストール - API Gateway でリクエストに trace_id を付与 - 各サービスが trace_id を伝播 → 同じ trace で一覧可能

1. Trace ビュー：

   Request ID: 12345
   ├─ API Gateway: 100ms
   │  ├─ Auth Service: 800ms (遅い!)
   │  │  └─ Redis 接続: 750ms
   │  └─ Route matching: 50ms
   └─ Product Service: 200ms
      ├─ Database クエリ: 180ms
      └─ キャッシュ: 20ms
   
   合計: 1100ms
   

2. 発見：Auth Service の Redis が遅い → Auth チームが接続プール サイズを増やす → 全体 latency が 1100ms → 400ms に改善

シナリオ 3：バッチ処理（Dataflow）のメモリリーク検出

要件 - Dataflow パイプラインが 24h 稼働 - 4時間目からメモリが 80% で張り付く（メモリリーク疑い）

実装 1. Cloud Profiler： - Dataflow Worker で Profiler 有効化 - CPU・メモリをリアルタイム監視

1. Flame Graph：
2. メモリプロファイラで「parse_json 関数が確保メモリを解放していない」と特定

3. 開発チーム：JSONDecoder.close() を追加 → メモリ安定

4. Alert Policy：

5. メモリ > 80% が 10分続いたら → Ops チームに Slack
6. Worker 再起動（ロールアウト）

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

誤解 1：「エラーログを見ればいい」

現実： - Cloud Logging に大量のログが溜まり、検索は秒単位でかかる - 本番トラブルで「エラーログを漁る」は時間がかかりすぎる

正解： - Cloud Monitoring アラートで問題を 自動検出（秒単位） - Error Reporting で エラーをグループ化・集約 - ログは 事後分析用（Root Cause Analysis = RCA）

誤解 2：「Monitoring だけで十分」

現実： - Cloud Monitoring は「メトリクス（数値）」のみ - 「CPU = 95%」と「何が CPU 使ってるか」は別問題

正解： - メトリクス（数値傾向）→ Cloud Monitoring - 詳細ログ（何が起きたか）→ Cloud Logging - パフォーマンス（どの関数が遅いか）→ Cloud Profiler - を組み合わせて多次元分析

例： - Cloud Monitoring：「CPU 95%」→ アラート - Cloud Logging：「Database クエリが 100個溜まってる」→ 原因推定 - Cloud Profiler：「SELECT クエリの parseJSON が CPU の 60%」→ 修正対象確定

誤解 3：「Cloud Logging は無制限に保持」

現実： - Cloud Logging は 30日デフォルト保持 → 自動削除 - 「半年前のログで調査したい」は不可

正解： - Sink を使って自動転送： - Cloud Storage（7年保存・監査用） - BigQuery（分析用） を設定して、永続保管

誤解 4：「アラート Policy = Slack 通知するだけ」

現実： - アラート発火 → 通知 → 手作業で調査・復旧

正解： - 自動修復スクリプト + アラート Policy - 例：CPU > 90% → MIG の自動スケールアウト（既に GKE・Cloud Run は自動） - 例：メモリリーク検出 → Pod の自動再起動（Kubernetes restart policy） - 例：エラー率 > 5% → ロールバック実行（Cloud Deploy の自動ロールバック）

誤解 5：「カスタムメトリクスは自由に作成」

現実： - カスタムメトリクスは 1メトリクス/月 $0.12（150万メトリクス/月で $4） - 「ユーザー ID ごとのメトリクス」を 1000万ユーザー分作成 → 月 $1.2M

正解： - 高カーディナリティ（種類が多い）メトリクスは BigQuery + Log-based Metrics を使用 - ログに記録 → Log-based Metrics で集約 → BigQuery で分析 - コスト：ログ $5 + BigQuery 分析料金（より安い）

誤解 6：「Alert Policy で複雑な条件は書けない」

現実： - UI では「CPU > 80%」「メモリ > 90%」の単純条件のみ - 「（CPU > 80% AND メモリ > 90%）OR ディスク使用率急増」は UI では無理

正解： - Cloud Monitoring Query Language（MQL） で複雑な条件を書く

fetch resource
| metric 'compute.googleapis.com/instance/cpu/utilization'
| condition value > 0.8
| {cpu_high, memory_high}
| union
| condition ANY(false)

⑧ 理解度チェック

次のシナリオで最適なサービス組み合わせを選んでください：

「Web API サーバー（Cloud Run）が本番で『時々 5秒のレスポンス遅延が発生』と報告されている。エラーではなく、『なぜ遅いのか』の原因が不明。ASAP で原因を特定して修正したい。」

どのサービスの組み合わせを最初に確認すべきか？

• (A) Cloud Monitoring で「レスポンスタイム p99」ダッシュボード + Error Reporting でエラーログ検索
• (B) Cloud Trace で遅延トレース確認 + Cloud Profiler で CPU・メモリサンプリング確認
• (C) Cloud Logging で stdout ログ全件ダウンロード + 手動パース
• (D) Compute Engine の Profiler ライセンス購入 + オンプレ Datadog エージェント

⑨ 深掘り補足（オプション）

Cloud Monitoring Query Language（MQL）の活用

Alert Policy UI では単純な条件しか書けませんが、MQL を使うと複雑な条件が可能：

fetch gke_container
| metric 'kubernetes.io/pod/memory/used_bytes'
| group_by [resource.pod_name],
    [value_memory: mean(value.memory_used)]
| condition value_memory > 1_000_000_000  # 1GB 超過
| unit 'byte'

PCA 試験での重要性：「メトリクスベース自動復旧」は MQL 理解が必須。SLO-based Alert（エラーバジェット に基づくアラート）も MQL で実装。

Uptime Check（外部監視）

用途：「エンドユーザーの観点から API が生きているか」を確認

• HTTPS GET https://api.example.com/health を 1分ごとに実行
• 応答コード 200 ≠ 5xx なら「健康」→ アラート OFF
• 3 回連続失敗 → アラート ON

PCA での使用： - Web API の可用性監視（内部メトリクスではキャッチできない場合） - 外部サービス依存性の監視（決済 API など） - 月 $1 / endpoint の追加コスト

SLO・SLI と Alert Policy の統合（Google SRE 標準）

SLI（Service Level Indicator） = 「API の成功率 99.9%」という目標

SLI = (成功したリクエスト数) / (総リクエスト数)

Alert Policy で SLI 監視：

SLI < 0.999（99.9% 未満）が 5分続いたら → Slack

これにより「目標値からの乖離」をリアルタイムで検出。

Cloud Trace + OpenTelemetry Collector（マルチクラウド対応）

⚠️ Preview：OpenTelemetry Collector for Google Cloud（プレビュー）

複数クラウド環境（GCP + AWS + Azure）のトレースを 一つの Cloud Trace に集約可能：

Application (GCP)
  ↓ OpenTelemetry SDK
[OpenTelemetry Collector] ← Application (AWS)
  ↓
Cloud Trace

PCA での評価ポイント：マルチクラウド戦略（GCP + AWS 混在）の際に「分散トレースの統一」を実現する手法として選択肢に。

Cost Optimization：Logging コスト削減

Cloud Logging は「取り込み（Ingestion）課金」→ 大規模ログは月数千円～数万円

削減策： 1. ログレベルフィルタリング：本番は INFO 以上のみ、開発は DEBUG 全量

resource.type = "cloud_run_revision"
AND (severity="ERROR" OR severity="WARNING" OR severity="INFO")

1. Sink で BigQuery へ自動転送：Cloud Logging から削除 → ストレージコスト節約
2. Cloud Logging：保持 30日

3. BigQuery：永続保存（分析用）

4. Log Exclusion フィルタ：ヘルスチェックログ（毎秒出力）を除外

   resource.type="gke_pod" AND logName=~"healthcheck"
   

PCA 試験での重要性：「コスト最適化」が出題比率 11%。不要なログ排除で月 50% コスト削減は高評価。

次回: 6.2 デプロイとリリース管理（カナリアデプロイ・ブルーグリーン・フィーチャーフラグ）