Google PCA: オペレーション、オブザーバビリティ、プラットフォームの自動化 — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概要

Google Cloud 上の運用、オブザーバビリティ、プラットフォームの自動化は、セキュリティとコストを管理しながら、サービスが診断可能、保守可能であり、継続的に改善されることを保証します。一貫性のある設計は、ロギング、メトリクス、トレーシング、監査可能性、ランブック、インシデント対応、割り当てとキャパシティのガバナンス、そして自動化に及びます。目標は、サービスレベル目標 (SLO) に関連付けられた、実用的でノイズの少ないシグナルと、手作業 (toil) と構成ドリフトを削減する決定論的な自動化を組み合わせることです。

ロギングと監査可能性

Cloud Logging は、Google Cloud サービス、GKE、VM からのログを一元管理します。request_id、user_id、service、version、latency_ms、severity のキーが一貫した構造化ログ (JSON) を優先的に使用します。構造化データにより、正確なクエリ、ログベースの指標、ポリシー評価が可能になります。VM と GKE ノードには、Ops Agent (推奨) または従来のロギングエージェントをインストールして、システムログとアプリケーションログを収集します。パーサーがフレームワーク用の JSON を出力するようにしてください。

• ログバケットと保持期間: データレジデンシーと CMEK のために、リージョンに配置されたログバケットを使用します。デフォルトのバケットには _Default と _Required が含まれます。後者は、管理アクティビティ、システムイベント、ポリシー拒否の監査ログを、固定の長期保持期間で保存します。データクラスごと (例: アプリ、セキュリティ、分析) に専用のバケットを作成し、保持期間と CMEK を調整します。保持期間が長いほどフォレンジックは向上しますが、コストが増加します。Logging での保持が不要な場合は、長期アーカイブのためにエクスポートします。

• ログシンクとエクスポート: ログルーターを使用して、シンク経由で BigQuery (分析)、Pub/Sub (SIEM やパイプライン)、Cloud Storage (アーカイブ) にルーティングします。パーティション分割された BigQuery テーブルを使用して、ボリュームとコストを管理します。サイレント障害を避けるため、シンクのサービスアカウントには、宛先への最小権限の書き込みアクセスを常に付与します。エクスポートされたログを Logging に再取り込みしないことで、ルーティングループを回避します。

• クエリとログベースの指標: Logs Explorer で logName、resource.type、severity、labels、jsonPayload フィールドのフィルタを使用します。エラー率の SLI とレイテンシのヒストグラムのために、ログベースの指標 (カウンターまたは分布) を導出し、アラートをサポートします。変動の大きいフィールドを正規化することで、カーディナリティを制御します。

• Cloud Audit Logs: 管理アクティビティ (コントロールプレーンの書き込み)、データアクセス (ユーザーデータの読み書き)、システムイベント、ポリシー拒否のログは、管理上のオブザーバビリティを提供します。データアクセスログは大量になるため、多くのサービスでデフォルトで無効になっています。必要な場合にのみ有効にし、適切な保持期間と CMEK を持つバケットにルーティングします。ポリシー拒否ログは、権限や組織のポリシー違反を早期に検出するのに役立ちます。職務上の分離を徹底します。通常、セキュリティチームが監査ログを所有・アクセスし、他のチームには制限されたビューが提供されます。

• 障害モードとトレードオフ:

  • 範囲が広すぎるシンクは BigQuery のコストを急増させます。正確にフィルタリングし、パーティションを期限切れにします。
  • カーディナリティの高い JSON フィールド (例: 完全な URL) はクエリのパフォーマンスを低下させます。サニタイズし、正規化されたラベルを抽出します。
  • 保持期間が不十分だと調査が困難になります。GCS や BigQuery へのエクスポートで緩和します。
  • エージェントの欠落やパーサーの設定ミスは、サイレントなログ損失を引き起こします。エージェントのハートビートと取り込みエラーでアラートを出すようにします。

例: カスタム保持期間を持つリージョンログバケットを作成し、フィルタリングされた監査シンクをエクスポートする。

undefined

undefined

モニタリング、トレーシング、アプリケーション診断

Cloud Monitoring は、システムとアプリケーションの指標を収集し、ダッシュボード、アラート、稼働時間チェック、通知チャネル、サービスレベル目標をサポートします。

• 指標とダッシュボード: Google サービス用の組み込み指標を使用し、Cloud Monitoring API または OpenTelemetry を介してカスタム指標を作成します。4つのゴールデンシグナル (レイテンシ、トラフィック、エラー、飽和) を重視します。ラベルは慎重に適用し、上限のないラベル値は避けます。Metrics Scope を使用して、複数プロジェクトのビューを集約します。必要に応じて、表現力豊かなクエリのために MQL を使用します。

• アラートと通知チャネル: SLO に対してマルチウィンドウ、マルチバーンレートのアラートを実装し、迅速な検出とノイズ削減のバランスを取ります。通知チャネル (メール、SMS、Pub/Sub、Webhook、サードパーティのインシデントツール) を定義し、アラートのドキュメントにランブックへのリンクとコンテキストを含めます。通知レート制限とインシデントの自動クローズを使用して、アラートストームを防ぎます。

• 稼働時間チェック: 複数のリージョンから、TLS 検証、DNS、コンテンツマッチを用いて重要なエンドポイントをプローブします。稼働時間チェックをアラートとサービスの SLO に関連付けます。稼働時間チェックは内部の依存関係を検証しないことを忘れないでください。合成トランザクションと内部ヘルスチェックで補完します。

• SLO と SLI: 可用性、レイテンシ、正確性のための SLI を定義します。Cloud Monitoring Service Monitoring で SLO を設定し、エラーバジェットを追跡します。顧客への影響と整合させるため、生のエラーではなく、バジェットの消費に対してアラートを発行します。残りのエラーバジェットを尊重するために、リリースゲートやプログレッシブデリバリーを使用します。

• Cloud Trace、Error Reporting、Profiler: OpenTelemetry を使用してサービス間の分散トレーシングを行い、リクエストと依存関係のメタデータでスパンにアノテーションを付けます。コストを管理しつつ重要なフローのカバレッジを確保するために、サービスごと、パスごとにサンプリングを動的に調整します。Error Reporting はログから例外を自動的に集約し、スタックトレースによって重複排除し、通知をトリガーします。Profiler は、本番環境で低オーバーヘッドで継続的な CPU、ヒープ、実時間のプロファイルを提供します。これを使用してホットパスを排除し、コストを削減します。

• 障害モードとトレードオフ:

  • 指標のカーディナリティが過剰になると、コストが増加しクエリが遅くなります。送信前に集約します。
  • トレースのサンプリング率が低いと、テールレイテンシの問題が隠れてしまいます。遅いパスに対してはより高いレートでサンプリングします。
  • 不適切な SLO (例: 厳しすぎる) はアラート疲れを引き起こします。実際のトラフィックデータで反復的に改善します。
  • 稼働時間チェックは成功していても、内部の依存関係が失敗している可能性があります。依存関係を考慮した SLO を使用します。

自動化、リソースインベントリ、ポリシー、ドリフト

繰り返し可能なタスクは、最小権限とべき等性で自動化します。

• ツール: 安全でエフェメラルな管理作業には、永続的な $HOME を持つ Cloud Shell を使用します。ヘルパーバイナリは ~/bin に配置して PATH の永続性を確保します。自動化には gcloud、REST API、クライアントライブラリを使用します。サービスアカウントと Workload Identity を使用して、長期的なキーを排除します。

• スケジューラとオーケストレータ: Cloud Scheduler を使用して、cron スケジュールで HTTP および Pub/Sub ジョブをトリガーします。Workflows を使用して、再試行、バックオフ、補正、タイムアウトを備えた複数サービスの自動化をオーケストレーションします。べき等性を確保し、ログに相関 ID を追加します。

• 定型的な自動化の例:

  • インベントリおよびドリフトレポートのために、GCS と BigQuery へ毎日アセットをエクスポートする。
  • SLO バーンレート計算を自動化し、ダッシュボードに公開する。
  • 組織のポリシーと IAM の異常に対して、定期的なポリシー評価を実行する。

• リソースインベントリとポリシー評価: Cloud Asset Inventory は、リソース、IAM バインディング、組織のポリシーの特定時点のスナップショットとリアルタイムの変更フィードを提供します。履歴分析とドリフト検出のために BigQuery にエクスポートし、ほぼリアルタイムのポリシー違反のトリアージのために Pub/Sub にサブスクライブします。Policy Analyzer と Recommender を使用して、過度に広範な IAM や未使用の権限を検出します。Organization Policy で制約を適用し、デプロイ前に policy-as-code で構成を検証します。

• 構成ドリフト: 宣言的な IaC と継続的な検証でドリフトを防ぎます。検出時には、自動的に調整するか、リソースを隔離します。管理対象かアドホックかを区別するために、リソースに来歴（例: deployment_id）のタグを付けます。

• セキュリティ、信頼性、コストのための可観測性アーキテクチャ:

  • セキュリティ: 監査ログを CMEK で保護され、アクセスが制限されたバケットにルーティングし、専用のセキュリティプロジェクトにエクスポートします。Pub/Sub を介して SIEM と統合します。
  • 信頼性: SLI とトレースからダッシュボードとアラートを生成します。Workflows を使用してインシデント対応の自動化をリハーサルします。
  • コスト: メトリクスのカーディナリティを制御し、バケットごとにログの保持期間を調整し、BigQuery のエクスポートをパーティション分割し、Profiler を使用してホットパスを最適化します。

例: 毎日のアセットエクスポートをスケジュールし、ワークフローを実行する。

undefined

undefined

実践的な問題シナリオ

Contoso Commerce は、マルチリージョンの GKE ベースの決済プラットフォームを立ち上げようとしています。要件: 監査可能な管理、ノイズの少ない SLO ベースのアラート、エンドツーエンドのリクエストトレース、夜間のコンプライアンスインベントリの自動化、および厳格なコスト管理。

アプローチ:

1. ロギングと監査の基盤を確立する

• アプリ、セキュリティ、分析ログ用に、CMEK を使用したリージョンログバケットを作成します。アプリ用に 30 日、セキュリティ用に要件に応じて 400 日以上を設定します。Admin Activity、System Event、Policy Denied のログをセキュリティバケットにルーティングします。Data Access ログは決済サービスに対してのみ有効にします。
• 論理的根拠: 機密性による分離は、影響範囲とコストを削減します。CMEK はコンプライアンスを満たします。Data Access のスコープを限定することで、ログ量の急増を回避します。

2. 構造化されたアプリケーションロギングと収集を実装する

• GKE ノードに Ops Agent をデプロイし、サイドカー/デーモンセットのコレクターを使用して、PII をサニタイズした相関 ID (trace_id, span_id) とユーザー/セッションラベルを含む構造化 JSON としてアプリのログを転送します。
• 論理的根拠: 構造化ログにより、正確なクエリ、ログベースのメトリクス、トレースとの結合が可能になります。相関 ID は分散診断をサポートします。

3. 分散トレーシング、エラー集約、プロファイリングをデプロイする

• OpenTelemetry SDK でマイクロサービスを計装し、Cloud Trace にエクスポートします。チェックアウトと決済のパスにはより高いサンプリングレートを設定します。すべてのランタイムで Error Reporting を有効にし、CPU/メモリが重要なサービスには Profiler を有効にします。
• 論理的根拠: トレースはサービスホップごとのレイテンシを特定します。Error Reporting はスタックトレースをグループ化してトリアージを加速します。Profiler はコンピューティングコストとテールレイテンシを削減します。

4. SLI/SLO の定義とアラートおよびダッシュボードの設定

• SLI を定義します: p90 および p99 のチェックアウトレイテンシ、チェックアウト API の可用性、決済成功率。SLO を設定します（例: 99.9% の可用性、800ms 未満の p99 レイテンシ）。ランブックのリンクと PagerDuty チャネルを含むバーンレートアラート（1 時間で 2%、6 時間で 1%）を設定します。ゴールデンシグナルとエラーバジェットの傾向を表示するダッシュボードを構築します。
• 論理的根拠: エラーバジェットアラートは顧客への影響に関連付けられ、ノイズを削減します。ダッシュボードは運用状況の認識を提供します。

5. 外部および内部のヘルスチェックを追加する

• コンテンツ検証を含むチェックアウトエンドポイントのマルチリージョン稼働時間チェックを設定します。カートから決済までのフローに合成トランザクションチェックを追加します。GCLB と GKE の readiness probe を統合します。
• 論理的根拠: 稼働時間チェックは顧客向けの可用性を検証します。合成フローは依存関係の破損を検出します。

6. インベントリ、ポリシー監視、ドリフト検出の自動化

• GCS と BigQuery への Cloud Asset Inventory のエクスポートを受け取るためのセキュリティプロジェクトを作成します。IAM と組織のポリシーの変更に対してリアルタイムの Pub/Sub フィードを有効にします。Workflows を夜間に実行して、望ましい状態のマニフェストと現在のアセットを比較します。チケットを起票するか、リスクの低いドリフトを自動調整します。
• 論理的根拠: 一元化されたインベントリは監査をサポートします。継続的なポリシー評価は権限の肥大化を防ぎます。自動化はドリフトを抑制します。

7. 割り当てとキャパシティの管理

• コンピューティング、ロードバランサ、API の割り当てを、70% および 85% の使用率でアラートを出すように監視します。目標負荷に合わせて、より高い割り当てを事前にリクエストします。GKE クラスタのオートスケーラーと HPA の上限を割り当てに合わせます。起動が遅い MIG ベースのサービスには、予測オートスケーリングを有効にします。
• 論理的根拠: 割り当ての上限は、障害のように見えることがあります。事前の調整と整合性のとれたオートスケーリングにより、ピーク時のスロットリングを防ぎます。

8. 可観測性におけるコストの最適化

• バケットごとにログの保持期間を制限し、Log Router フィルタを介して本番環境の冗長なデバッグログを除外し、必要なフィールドのみをパーティションの有効期限付きで BigQuery にエクスポートします。メトリクスラベルのカーディナリティを制限します。Profiler の結果を使用して、ホットなサービスをダウンサイズします。
• 論理的根拠: 可観測性は費用対効果が高いべきです。対象を絞った保持とエクスポートにより、コストの暴走を防ぎます。

9. ランブックとインシデント対応演習の準備

• 各アラートポリシーに対して、診断クエリ、トレースフィルタ、ロールバックコマンド、コミュニケーションを含む、バージョン管理されたランブックを作成します。ゲームデーを実施して、エスカレーションと自動化を検証します。
• 論理的根拠: 確定的で実践された対応は、MTTR を削減し、信頼性を向上させます。

10. 検証と反復

• 継続的にアラートのノイズを確認し、しきい値を調整し、実際のトラフィックに基づいて SLO を改良します。事後分析のアクションアイテムを、所有者と期限を設けて完了まで追跡します。
• 論理的根拠: 可観測性と運用は、測定されたフィードバックを通じて改善され、それにより労力が削減され、サービスの品質が時間とともに向上します。

← 移行、モダナイゼーション、ハイブリッドクラウド戦略 · すべてのドメイン · DevOps、デリバリーエンジニアリング、Infrastructure as Code →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →