オブザーバビリティと SRE

Google Cloud Observability の全体像

ここまでの章で「作る」「守る」を扱ってきました。本章のテーマは「動き続けていることを知る」です。オブザーバビリティ（可観測性）とは、システムが外に出すテレメトリー（指標・ログ・トレース）から内部状態を推測できる性質のこと。Google Cloud ではこれを Google Cloud Observability というスイート（旧称 Stackdriver）が一手に引き受けます。柱は 3 つのテレメトリーに対応する 3 プロダクト — 数値の時系列を扱う Cloud Monitoring、イベントの記録を扱う Cloud Logging、リクエストの経路と所要時間を扱う Cloud Trace — と、それを補う Cloud Profiler（CPU・メモリのホットスポット分析）、Error Reporting（例外の自動グルーピング）です。

役割分担を一言で言うと「気づくのは Monitoring、調べるのは Logging と Trace、直すヒントは Profiler と Error Reporting」です。試験でもこの使い分けが頻出します。

Cloud Trace は OpenTelemetry による計装が推奨で、Cloud Run は送受信 HTTP リクエストのレイテンシデータを自動送信します（第 7 章）。Cloud Profiler は Go / Java / Node.js / Python に対応し、統計的サンプリングでオーバーヘッドを 5% 未満（複数レプリカの平均では 0.5% 未満が一般的）に抑えるため本番常時稼働が前提です。Error Reporting は Cloud Logging に書かれた例外ログ、または専用 API から入力を受け取ります。

Cloud Monitoring — 指標・アラート・アップタイムチェック

指標とメトリクススコープ

Cloud Monitoring が扱う指標は出どころで 5 系統あります。① Google Cloud サービスが自動で出す指標、② Compute Engine VM に入れた Ops Agent が集める OS・アプリ指標、③ ユーザー定義（カスタム）指標、④ 外部・サードパーティ指標、⑤ Google Cloud Managed Service for Prometheus 経由の Prometheus 指標です。時系列データは「メトリクスタイプ × 監視対象リソース × ラベル」で識別され、クエリ言語は PromQL・MQL・Monitoring フィルタの 3 つが使えます。可視化は Metrics Explorer とダッシュボード（自動生成 + カスタム）が担います。

複数プロジェクトの一元監視はメトリクススコープで実現します。スコーピングプロジェクトに他の Google Cloud プロジェクト（および AWS アカウント）を追加すると、単一画面で横断的に指標を見られます。プロジェクトを環境ごとに分ける設計（第 2 章）と組み合わせて、監視専用プロジェクトに集約するのが定石です。

アラートポリシー — 条件・インシデント・通知チャネル

アラートは「条件（何をもって異常とするか）+ 通知チャネル（誰に知らせるか）+ ドキュメント（通知に添える対応手順）」の 3 点セットで定義します。条件を満たすとインシデントという記録が作られ、通知が飛び、指標ベースの条件では条件解消で自動クローズされます（クローズ時も通知可能）。通知チャネルは Email・Cloud Mobile App・PagerDuty・Slack・Pub/Sub・Webhook など多数に対応します。

指標ベースの条件タイプは 4 つ + ログベースがあります。

アップタイムチェック — 外形監視

アップタイムチェックは、世界各地のチェッカーから HTTP / HTTPS / TCP でエンドポイントを叩き続ける外形監視です。パブリックチェックは公開 URL や LB を、プライベートチェックは VPC 内の VM や内部ロードバランサの内部 IP を対象にできます。チェックは最低 3 つのチェッカー（3 ロケーション以上）から実行され、推奨のアラート条件は「2 リージョン以上で 1 分以上失敗したら通知」です。料金はチェックの実行回数ベースで、1 回のチェックはリージョンごとに 1 実行と数えます（2026-08 時点: プロジェクトあたり月 100 万実行まで無料、超過 $0.30/1,000 実行）。

gcloud monitoring uptime create pca-uptime-check \
  --resource-type=uptime-url \
  --resource-labels=host=example.com,project_id=PROJECT_ID \
  --protocol=https \
  --period=5 \
  --timeout=10

gcloud monitoring uptime list-configs

gcloud monitoring uptime delete CHECK_ID
gcloud monitoring uptime list-configs   # 空になれば OK

Cloud Logging — ログの経路と保持を設計する

ログの種類とログエクスプローラ

Cloud Logging には、Google Cloud サービスが出すプラットフォームログ、GKE などのコンポーネントログ、Cloud Audit Logs や Access Transparency ログといったセキュリティログ（第 14 章）、アプリが Ops Agent・API・クライアントライブラリ経由で書くユーザー作成ログ、他クラウドやオンプレからのマルチクラウドログが集まります。調べるときの入口はログエクスプローラで、クエリ言語でフィルタして個々のエントリをトレースと突き合わせながら読めます。ログバケットを Log Analytics 対応にアップグレードすると SQL でログを集計・分析でき（BigQuery のリンクされたデータセットはバケットごとに 1 つ作成可能）、傾向分析に使えます。ただしアップグレードは取り消せません。

Log Router とシンク — すべてのログは経路が決まってから保存される

Cloud Logging API に届いたログエントリは、いったん Log Router を通り、シンクのフィルタ評価によって宛先が決まります。シンクは「包含フィルタ 1 つ + 除外フィルタ複数」を持ち、包含に一致し除外に一致しないエントリだけを宛先へ流します。各プロジェクトには最初から 2 つのシンクがあります。_Required シンクは管理アクティビティ監査ログなどを _Required バケット（保持 400 日）へ送り、変更も無効化もできません。_Default シンクは残りすべてを _Default バケット（既定 30 日、1〜3650 日に変更可）へ送り、こちらはフィルタ変更・無効化ができます。

ユーザー定義シンクの宛先は、ログバケット・BigQuery データセット・Cloud Storage バケット・Pub/Sub トピック（Splunk 等のサードパーティ連携用）・別プロジェクトの 5 種類です。たとえば監査ログを BigQuery で分析したいなら次のようにシンクを作ります（第 11 章）。

# 監査ログを BigQuery データセットへルーティングするシンクの例
gcloud logging sinks create audit-to-bq \
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/audit_logs \
  --log-filter='logName:"cloudaudit.googleapis.com"'

組織・フォルダレベルでは集約シンクが作れます。配下の全プロジェクトのログを 1 か所（中央プロジェクトのログバケットなど）に集める仕組みで、全社の監査ログ保全の定番です。インターセプト型集約シンクにすると、一致したログは各プロジェクトの _Default シンクを通らなくなり、重複保存を防げます（_Required への保存は必ず行われます）。

ログベースの指標

「このエラーログが何件出たか」を Cloud Monitoring の指標に変換するのがログベースの指標です。一致エントリ数を数えるカウンタ型と、ログから抽出した数値をヒストグラムにする分布型（レイテンシ集計に定番）があり、システム定義（logging.googleapis.com/ 配下）とユーザー定義（logging.googleapis.com/user/ 配下）に分かれます。ユーザー定義の指標は作成後に届いたログだけを数えます。毎分時系列が更新されるので、そのままアラートポリシーの条件に使えます。

料金の勘所（2026-08 時点）

• 取り込み（ストレージ課金）: ログバケットへの保存が $0.50/GiB（月 50 GiB/プロジェクトまで無料、30 日分の保存込み）。_Required バケットへの保存は課金されない
• 長期保持: 30 日を超えて保持する分に $0.01/GiB/月
• Log Router・Log Analytics のクエリ: 追加料金なし
• Monitoring 側: 課金対象指標の取り込みが最初の 150 MiB/月（請求先アカウントあたり）まで無料、以降 $0.2580/MiB から段階的に低減。アラートポリシー課金（メトリクス参照あたり $0.35/月）は 2027 年 9 月以降開始予定

gcloud logging write pca-handson-log \
  "決済処理でタイムアウトが発生しました" --severity=ERROR

gcloud logging write pca-handson-log \
  '{"message": "checkout failed", "orderId": "A-1234"}' \
  --severity=ERROR --payload-type=json

gcloud logging read \
  'logName="projects/PROJECT_ID/logs/pca-handson-log"' --limit=5

gcloud logging metrics create pca-error-count \
  --description="ハンズオン用: ERROR 以上のログ件数" \
  --log-filter='logName="projects/PROJECT_ID/logs/pca-handson-log" AND severity>=ERROR'

gcloud logging metrics delete pca-error-count --quiet
gcloud logging logs delete \
  projects/PROJECT_ID/logs/pca-handson-log --quiet

SLI・SLO・エラーバジェット — 信頼性を数値で運用する

3 つの用語を区別する

SRE（Site Reliability Engineering）は「運用をソフトウェアエンジニアリングの問題として扱う」Google 発の方法論で、その中核が信頼性の数値化です。まず用語を厳密に区別します。

SLI 選びの原則は「計測しやすいものではなく、ユーザーが気にすることを測る」。ユーザー向けサービスなら可用性・レイテンシ・スループット、ストレージなら耐久性が代表です。レイテンシは平均でなくパーセンタイルで見ます — 平均 50ms でも 5% のリクエストが 20 倍遅い、というテールは平均に隠れるからです。そして目標を 100% にしてはいけません。100% は達成不可能なうえ、リリースの凍結を正当化してイノベーションを止めます。ユーザーが 99.9% と 99.99% の差を体感できないなら、低いほうで十分です。外部に約束する SLA より内部 SLO を厳しく設定し、契約違反の前に検知して動ける余白を持たせます。

エラーバジェットとバーンレート

SLO を裏返すとエラーバジェットになります。計算式は「(1 − SLO 目標) × コンプライアンス期間内の対象イベント数」。SLO 99.9%・30 日間なら 0.1% 分の失敗（時間に換算すると 43.2 分の全停止相当）が「使ってよい予算」です。予算が残っているうちは新機能のリリースやカオス実験に使い、枯渇が近づいたら信頼性改善を優先する — リリース速度と信頼性のトレードオフを、感情論でなく数値で裁定するのがエラーバジェットの役割です。

予算の消費速度がバーンレートです。バーンレート 1 は「このエラー率が続くと、コンプライアンス期間の終わりでちょうど予算を使い切る」速度を意味します。SLO 違反「後」に知っても手遅れなので、アラートはバーンレートに張ります。推奨は 2 段構えで、fast burn（ルックバック 1 時間・バーンレート 10 倍以上 → 即時対応）と slow burn（ルックバック 24 時間・2 倍以上 → 営業時間内に対応）を併用します。

Cloud Monitoring の SLO モニタリング

この理屈をマネージドで実装するのが Cloud Monitoring の SLO モニタリングです。Cloud Run サービス・GKE のワークロード / Service / Namespace・App Engine・Cloud Service Mesh・Istio on GKE のサービスはサービス候補として自動検出され、コード変更なしで SLO を張れます（該当しないものはカスタムサービスとして定義）。SLI は可用性・レイテンシ（またはカスタム指標）から選び、評価方法はリクエストベース（良いリクエスト ÷ 全リクエスト）かウィンドウベース（基準を満たした時間窓の割合）、コンプライアンス期間はローリング（直近 1〜30 日）かカレンダー（暦週・暦月でリセット）を選びます。SLO はサービスあたり最大 500 個、作成はコンソールのほか Cloud Monitoring API（services API）でも可能で、作った SLO にはバーンレートアラート（ルックバック期間は最大 24 時間）を紐づけられます。

トイルとポストモーテム — 文化の側

数値化とならぶ SRE の柱が 2 つあります。トイルの削減: トイルとは「手作業・反復的・自動化可能・戦術的・長期的価値がなく・サービス成長に比例して増える」運用作業のことで、SRE はトイルを業務時間の 50% 未満に抑え、残りをエンジニアリング（自動化・信頼性改善）に充てるのが原則です。ブレイムレス（非難しない）ポストモーテム: 障害後は個人を責めずにシステム側の原因を掘る文書を書き、レビューして共有します。書く基準（ユーザー影響が閾値超え、データ損失、オンコールの手動介入、監視で検知できず人が見つけた、など）をあらかじめ決めておくのが実務の型です。非難する文化では人が問題を隠すようになり、組織は同じ障害を繰り返します。

gcloud run deploy pca-slo-demo \
  --image=us-docker.pkg.dev/cloudrun/container/hello \
  --region=asia-northeast1 \
  --allow-unauthenticated

SERVICE_URL=$(gcloud run services describe pca-slo-demo \
  --region=asia-northeast1 --format='value(status.url)')
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code}\n" "$SERVICE_URL"
done

gcloud run services delete pca-slo-demo \
  --region=asia-northeast1 --quiet

信頼性を「確認する」手法 — カオスエンジニアリングと DiRT

試験セクション 4.3 は「本番の信頼性を確認する手順」を問います。監視は「起きた異常に気づく」仕組みですが、ここで扱うのは「異常を意図的に起こして備えを検証する」プロアクティブな手法です。

• カオスエンジニアリング: 計画的に障害を注入し、システムと運用チームの応答を検証します。例: マルチゾーン GKE クラスタのノードを停止する、Cloud SQL インスタンスを無効化してフェイルオーバーを確かめる、ファイアウォールルールでリージョン障害を模擬する。Chaos Monkey のようなフォールトインジェクションツールを使い、まず本番同等のステージング環境で実施し、本番でやる場合は監視とロールバック手順を必ず用意します。実験の許容量を測る物差しはエラーバジェットです
• DiRT の考え方: Google 社内では DiRT（Disaster Recovery Testing）と呼ばれる大規模な災害復旧演習を計画的に実施し、ゾーン・リージョン切断級の障害への復旧力を本番相当の環境で検証しています。自組織でも「四半期ごとにリージョン障害を想定した復旧訓練を行い、RTO / RPO（第 17 章）が実測で達成できるか確認する」形で取り入れます。バックアップは「復元できて初めてバックアップ」です
• ペネトレーションテスト: 自分の Google Cloud リソースへの侵入テストは Google への事前通知が不要です（利用規約と Acceptable Use Policy の順守、影響を自プロジェクトに限定することが条件）。セキュリティ設計（第 13 章）の検証手段として要件に現れます

障害対応そのものにも型があります。根本原因分析（RCA）の基本手順は、① 現象の確定（何が・いつから・どの範囲で）→ ② 直近の変更の確認（デプロイ・設定変更 — 障害の多くは変更起因）→ ③ テレメトリーでの絞り込み（ダッシュボードで異常な指標を見つけ、ログで該当リクエストを特定し、トレースで遅い区間を突き止める）→ ④ 仮説を立てて検証 → ⑤ 復旧後にポストモーテムで恒久対策、という流れです。ロールバックできる障害はまず戻して（第 16 章）、原因究明は復旧後に行うのが鉄則です。

つまずきポイント

理解度チェック

まとめと次章へ

• Google Cloud Observability は指標の Cloud Monitoring・ログの Cloud Logging・トレースの Cloud Trace が 3 本柱。Profiler（コードのホットスポット）と Error Reporting（例外の集約）が補完する
• アラートポリシーは条件 + 通知チャネル + ドキュメント。外形監視はアップタイムチェック（最低 3 ロケーションから実行）
• ログは Log Router のシンクで経路が決まる。_Required（400 日固定）と _Default（既定 30 日）の 2 バケットが最初からあり、集約シンクで組織全体のログを一元化できる
• SLI はユーザーが気にすることを測り、SLO は 100% にしない。エラーバジェット = (1 − SLO) × 対象イベント数がリリース速度と信頼性を裁定し、アラートはバーンレート（fast burn 10 倍/1 時間、slow burn 2 倍/24 時間）に張る
• 信頼性は監視するだけでなく、カオスエンジニアリング・復旧演習（DiRT の考え方）・ペネトレーションテスト（自リソースへは Google への事前通知不要）で能動的に確認する

「気づく・調べる・数値で運用する」仕組みが整いました。次の第 16 章では、インフラをコードで再現可能にし、リリース自体を安全にする IaC と CI/CD — Terraform・Cloud Build・Cloud Deploy とデプロイ戦略 — を扱います。エラーバジェットが「いつリリースするか」を決め、CI/CD が「どう安全にリリースするか」を決める、という接続です。

参考リンク（公式ドキュメント）:

• Cloud Monitoring overview
• Cloud Logging overview
• Routing and storage overview（Log Router とシンク）
• Alerting overview
• SLO monitoring
• SRE Book: Service Level Objectives
• Well-Architected Framework: Reliability pillar