Google PCD: 可観測性、デバッグ、サイト信頼性オペレーション — 学習ガイド

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Developer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloudにおける可観測性、デバッグ、サイト信頼性オペレーションは、システムを測定可能、診断可能、そして回復力のあるものにすることを中心に展開されます。強力な可観測性を実現するには、一貫したロギングと指標、分散トレーシング、実用的なアラート、そして規律あるインシデント対応が必要です。信頼性を確保するには、サービスレベル指標と目標の明確化、厳格なヘルスシグナリング、そして本番環境からの洞察をエンジニアリングの改善に繋げるフィードバックループが求められます。このセクションでは、これらの機能をGoogle Cloudでエンドツーエンドに構築する方法と、トレードオフや一般的な障害モードについて考察する方法を概説します。

ロギングとモニタリングの基礎

Cloud Logging

構造化ログを出力します。リリースをまたいでクエリやログベースの指標の堅牢性を維持できるよう、安定したフィールド名を持つJSONを推奨します。重要度、サービス名、バージョン、ロケーション、そして相関付けのためのリクエストIDまたはトレースコンテキストを含めます。
以下のフィールドを設定してログとトレースを関連付けます:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
バケットと保持期間。_Default バケットの保持期間は通常30日間です（設定可能）。_Required バケットには、より長く固定された保持期間を持つ特定の監査ログが含まれます。リージョンバケットを作成してデータ所在地を制御し、バケットごとにカスタムの保持期間を設定します。
シンク。分析のためにはBigQueryに、ストリーミングコンシューマーのためにはPub/Subに、アーカイブのためにはStorageにログをルーティングします。フォルダまたは組織レベルで集約シンクを使用して、子プロジェクトをキャプチャします。
クエリ。Loggingクエリ言語を使用して、resource.type、labels、jsonPayload、httpRequest、またはtextPayloadでフィルタリングします。

例:

構造化ログエントリ（省略形）: { “severity”: “ERROR”, “message”: “Checkout failed”, “service”: “payments”, “version”: “2026-09-01”, “user_id_hash”: “9c1…”, “labels”: {“tenant”:“gold”}, “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”, “logging.googleapis.com/spanId”: “00f067aa0ba902b7” }
保持期間の更新: gcloud logging buckets update _Default –location=global –retention-days=180
エラーログ用のBigQueryシンクの作成: gcloud logging sinks create bq-errors
bigquery.googleapis.com/projects/myproj/datasets/log_analytics
–log-filter=‘severity>=ERROR’
Cloud Runの最近の5xxエラーの読み取り: gcloud logging read ‘resource.type=“cloud_run_revision” AND httpRequest.status>=500’ –limit=20

Cloud Monitoring

指標。Google Cloudの指標、カスタム指標、ログベースの指標を使用します。カーディナリティの低いラベルを優先します。ラベルのカーディナリティが爆発的に増加すると、コストやクエリのレイテンシ問題を引き起こします。
ダッシュボード。サービスごと、および依存関係（データベース、キャッシュ、キュー）ごとにダッシュボードをキュレートします。RED（リクエスト、エラー、持続時間）およびUSE（使用率、飽和度、エラー）シグナルを可視化します。
アラートポリシー。しきい値、指標の欠落、比率、SLOバーンレート、または稼働時間チェックの失敗時にトリガーします。通知チャネル（メール、SMS、PagerDuty、Pub/Sub、Webhook）を設定します。ウィンドウ処理とアライナを使用して、アラートのバタつきを抑制します。
稼働時間チェック。複数のリージョンからプローブします。内部エンドポイントにはプライベート稼働時間チェックを使用するか、VPC内からシンセティックテストを実行します。

ログベースの指標

カウンタは発生回数を集計します（例: /api/alpha/* リクエストのカウント）。
ディストリビューションはレイテンシやペイロードサイズをキャプチャします。
例: gcloud logging metrics create api_alpha_count
–description=“Count of /api/alpha/* requests”
–log-filter=‘httpRequest.requestUrl=~"/api/alpha/.*" AND resource.type=“cloud_run_revision”’

運用分析

アドホック分析には、シンクを介してBigQueryにルーティングします。コストを管理するために、タイムスタンプによるスキーマとパーティショニングを設計します。
該当する場合は、エクスポートせずに集計するためにLoggingバケットのLog Analyticsを使用します。
CPU、メモリ、キューの深さ、Cloud SQLの接続数、Spannerのhigh-priority CPU、Pub/Subのunacked messages、Cloud Storageの429/5xxレートなどの指標からキャパシティシグナルを構築します。

一般的な落とし穴とトレードオフ

過剰なロギングは取り込みコストを増加させ、シグナルを不明瞭にします。サンプリングと重要度の規律を優先してください。
相関IDがないとインシデントのトリアージが妨げられます。トレースIDをエンドツーエンドで伝播させてください。
ホットバケットでの長期保持はコストを増加させます。長期的なニーズには、アーカイブまたはBigQueryにエクスポートしてください。

トレース、エラー、詳細診断

分散トレーシング

トレースコンテキスト。W3C trace-context (traceparent, tracestate) を推奨します。Cloud Traceとの相互運用性のために、引き続きx-cloud-trace-contextをサポートします: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
伝播。サービス、メッセージキュー、非同期境界を越えてトレースヘッダーを転送します。RPCやSQL呼び出しを行う際には、新しい子スパンをキャプチャします。コンテキストが失われると、サービスマップが壊れ、「不明なサービス」ノードが増加します。
サンプリング。コストと忠実度のバランスを取ります。イングレスでの動的なヘッドベースサンプリングや、まれに発生する遅いリクエストに対するテールベースサンプリングは、有用性を向上させることができます。

Cloud Trace

レイテンシヒストグラム、スパンのウォーターフォール、サービスマップを提供します。重要なサブオペレーション（RPC、DBクエリ）にはアノテーションを使用します。
p95/p99トレースを使用して外れ値を診断します。ファンアウト、N+1クエリ、ロック競合に注意します。
トレースとログの関連付けを有効にすることで、トレースをクリックするとそのログが表示されるようになります。

Error Reporting

サービス/バージョンごとに、スタックシグネチャによって例外を自動的に集約します。サービスコンテキストを設定して、サービス間の混同を避けます。ノイズの多い既知のエラーを抑制するか、優先度の低い通知に振り向けます。
例外メッセージからPIIを編集（リダクト）します。代わりに、安定したエラーコードと相関IDをログに記録します。

Cloud Profiler

サポートされているランタイムに対して、低オーバーヘッドの継続的なCPU/ヒーププロファイリングを提供します。バージョン間やトラフィックレベル間でプロファイルを比較して、リグレッションを検出します。サンプリングのアーティファクトを正確なカウントとして解釈しないようにします。

Cloud Debugger

スナップショットは、プロセスを一時停止することなく、コードの特定の場所で変数をキャプチャします。ログポイントは、一時的なロギングステートメントを挿入します。アクセスを制限し、機密性の高い変数を編集（リダクト）し、非PII式にスコープを限定します。

短い例: W3C traceparentを追加し、ログを関連付ける

HTTP伝播: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Cloud Traceにリンクするためのログフィールド: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

信頼性エンジニアリング、アラート、ヘルスシグナル

SLI、SLO、SLA、エラーバジェット

SLIはユーザーの満足度を測定します: 可用性、レイテンシ、正確性。クリティカルなエンドポイントとユーザージャーニーごとに定義します。
SLOは目標を設定します。例: 30日間でリクエストの99.9%が300ms未満であること。
エラーバジェットは許容可能な信頼性の低下を定量化します。バジェットはリリース、実験、移行などに使用します。バーンレートが高すぎる場合は、変更を凍結します。
SLAは外部とのコミットメントです。マージンを確保するために、SLOはSLAよりも厳しく設定します。

アラート品質の設計

可能な限り、原因ベースのアラートよりもSLOベースおよび兆候ベースのアラートを優先します。
マルチウィンドウ、マルチバーンレートのアラート（例: 5分間で14倍、1時間で2倍）を使用して、ノイズを減らしつつ、急速な消費と緩やかな消費の両方を捉えます。
ウォッチドッグのためにメトリクスの欠落をアラート対象に追加します（例: 長時間実行ジョブのハートビート）。
重大度に応じてルーティングし、通知をレートリミットし、ランブックやダッシュボードへのリンクを提供します。

ヘルスチェックとプローブ

Readinessチェックは、依存関係の準備が整うまでトラフィックをゲートします。Livenessチェックは、ハングしたプロセスに対して再起動をトリガーします。Startupプローブは、起動が遅いコンテナが時期尚早に再起動されるのを防ぎます。
ロードバランスされたVMの場合、ヘルスチェッカーのソース範囲を許可しないと、トラフィックがバックエンドに到達しません: gcloud compute firewall-rules create allow-lb
–network prod –allow tcp
–source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Kubernetesの例: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
外形監視（Synthetic testing）。アップタイムチェックや、Cloud Scheduler + Cloud Run/Functionsを介したカスタムのエンドツーエンドフローを使用して、ログイン、支払い、その他のクリティカルパスを検証します。
依存関係のモニタリング。データベース接続の飽和、RPCエラー率、キューのバックログ、下り（egress）エラー、サードパーティのSLIを追跡します。一時的な429/5xxエラーに対しては、安全性のためにべき等キーを使用して、切り捨て付き指数バックオフによるリトライを設定します。

インシデント対応、セキュリティを意識したデバッグ、根本原因

インシデント対応のライフサイクル

トリアージ: 重大度を分類し、インシデントコマンダーを割り当て、定義されたチャネル経由でオンコール担当者を呼び出します。
封じ込め: 既知の緩和策とトラフィック制御（ロールバック、カナリア、サーキットブレーカー、レートリミッター）を適用します。
コミュニケーション: 内部の作戦室を維持し、ステークホルダーに定期的に最新情報を伝え、必要に応じてユーザー向けのステータスを公開します。
解決と復旧: SLI を通じて健全性を検証し、早計な「すべて正常」の宣言を避けます。
ポストモーテム（事後検証）: タイムライン、検知のギャップ、貢献要因、そして担当者と期日付きのアクションアイテムを、非難することなく分析します。完了まで追跡します。

ランブック

トリガー、必要なコンテキスト、診断コマンド、安全な緩和策、ロールバック手順、エスカレーションパスを含めます。特定の障害モードに対応するダッシュボード、ログ、プレイブックへのリンクを記載します。

割り当てとキャパシティのモニタリング

Cloud Monitoring のメトリクスを通じてサービスの割り当てを監視します。使用率が 70～80% に達した時点でアラートを自動化し、計画的な負荷テストやローンチに備えて事前に増加をリクエストします。
追跡すべきキャパシティのシグナル: CPU、メモリ、ファイルディスクリプタ、スレッドプール、DB 接続、オートスケーラーの上限、リクエストキューの深さ。

機密情報を公開しないデバッグ

シークレットと PII をソースで墨消しし、シークレットは Secret Manager に一元化します。ユーザー識別子にはハッシュ化またはトークン化を使用します。ロギングミドルウェアでフィールドレベルの墨消しを有効にします。
IAM を介してログ、トレース、デバッグツールへのアクセスを制限します。該当する場合は CMEK と VPC Service Controls を使用します。
Debugger では、大きなオブジェクトグラフの収集を無効にし、機密性の高いフレームをキャプチャしないように条件を追加します。

レイヤーを横断した根本原因分析

ランタイム: Profiler を介して GC、スレッドプール、または CPU のスパイクを、Trace の p99 レイテンシと関連付けます。
ネットワーク: ロードバランサーのログ、VPC Flow Logs、ファイアウォールのログ、Connectivity Tests を調査してパスを検証します。ヘルスチェックの失敗は、一般的にファイアウォールルールの欠落やポートの間違いが原因です。
IAM: Cloud Audit Logs をレビューして権限拒否やポリシーの変更を確認し、サービスアカウントのロールとトークンのスコープを確認します。
データ: Cloud SQL Insights、Spanner のクエリ統計、Bigtable の CPU とホットタブレット、Storage のエラー率を使用してホットスポットを見つけます。一時的な障害にはバックオフ付きリトライを適用し、テールレイテンシを増幅させるファンアウトを削減します。
相関付けられたトレース ID とログベースのメトリクスで全体を結びつけ、インシデント後の分析中に複数ソースの結合を実行するために BigQuery にエクスポートします。

実践的な問題シナリオ

Fjord Retail は、Cloud Run、Cloud SQL、Pub/Sub、および外部の税金 API を使用して、複数サービスで構成されるチェックアウト機能を Google Cloud に移行します。フラッシュセール中に、ユーザーから断続的なタイムアウトと急増するエラー率が報告され、オンコール担当者はノイズが多くシグナルの乏しいアラートを受け取っています。

アプローチ:

トレース相関付けによる構造化ロギングの実装

サービス間で W3C traceparent の伝播を追加し、すべてのログに logging.googleapis.com/trace を含めます。理由: エンドツーエンドの相関付けにより、エンジニアは遅いユーザーリクエストから、遅延している特定の RPC やクエリ、およびそのログへと迅速に切り替えることができます。

Logging バケット、保持期間、エクスポートの作成

_Default の保持期間を 90 日に延長し、EU のワークロード用にリージョナルバケットを作成します。ERROR および WARNING ログを対象に、BigQuery への集約シンクを追加します: gcloud logging sinks create bq-prod
bigquery.googleapis.com/projects/fjord/datasets/ops_logs
–log-filter=‘severity>=WARNING’ –include-children 理由: 十分なホットストレージの保持期間はデバッグを助け、BigQuery はホットストレージのコストを増大させることなく、迅速なインシデント分析を可能にします。

SLI/SLO と SLO ベースのアラートの定義

可用性 SLI: 成功したリクエスト数 / 合計リクエスト数。レイテンシ SLI: POST /checkout の p95 実行時間。
SLO: 月次で 99.9% の可用性、チェックアウトの 95% が 300ms 未満で完了。
マルチウィンドウのバーンレートアラートと、チェックアウトのハートビートに対するメトリクス欠損アラートを設定します。理由: 症状ベースのアラートはノイズを減らし、ユーザーへの影響がある場合にのみページングします。

ヘルスプローブと合成チェックの設定

Cloud Run サービスは /ready と /healthz を公開します。/checkout に対するグローバルな稼働時間チェックと、VPC 内でテスト認証情報を使用して完全なチェックアウトを実行するプライベートな合成ジョブを追加します。理由: readiness probe は、コールド状態のバックエンドがトラフィックを受信するのを防ぎ、合成チェックはエンドツーエンドの問題やサードパーティの回帰を検出します。

Cloud Trace と Profiler の有効化、バックオフ付きリトライの採用

該当箇所に Trace/Profiler エージェントをインストールし、HTTP クライアントの自動計装と SQL スパンのアノテーションを有効にします。税金 API の呼び出しには、べき等キーを持つ切り捨て指数バックオフを実装します。理由: トレースはレイテンシの要因を特定し、バックオフは 429/5xx エラーの増幅を減らし、エラーバジェットを保護します。

キャパシティと割り当てのモニタリング

Cloud SQL の接続数、CPU、InnoDB バッファプール、Pub/Sub の未確認メッセージ、Cloud Run の同時実行数、およびサービス割り当て使用状況に関するダッシュボードとアラートを追加します。理由: キャパシティの飽和はテールレイテンシの隠れた一般的な原因であり、早期のアラートは停止を防ぎます。

プライバシーのためのデバッグの強化

ハッシュ化されたユーザー ID を使用し、エラーメッセージから PII を除外します。Debugger の使用を本番環境に限定し、墨消しルールとログポイントのみを使用するように制限します。理由: データ最小化の原則を遵守しつつ、オブザーバビリティを維持します。

依存関係モニターとサーキットブレーカーの構築

カスタムメトリクスを介して外部の税金 API の成功率とレイテンシを追跡し、障害がしきい値を超えた場合にキャッシュされた税率に切り替えるサーキットブレーカーを作動させます。理由: サードパーティの依存関係における障害を隔離し、コアとなるチェックアウトの可用性を維持します。

ランブックとエスカレーションパスの準備

手順を文書化します: SLO ダッシュボードの確認、Trace サービスマップでのホットエッジのチェック、Cloud SQL Insights での遅いクエリの調査、ファイアウォールとヘルスチェックの検証、割り当てのヘッドルームの評価。ロールバックとカナリアの手順を含めます。理由: 一貫性のある迅速な対応は MTTR を短縮し、その場しのぎの危険な変更を回避します。