Google PCA: DevOps、デリバリーエンジニアリング、Infrastructure as Code — 学習ガイド

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

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

概要

Google CloudにおけるDevOps、デリバリーエンジニアリング、Infrastructure as Code (IaC)は、強力なトレーサビリティ、自動化、安全性を備えた信頼性の高い変更を継続的にデリバリーすることに重点を置いています。アーキテクチャは、短いフィードバックサイクル、再現可能なデプロイ、イミュータブルなインフラストラクチャ、そして組織とともにスケールするガードレールを最適化する必要があります。Google Cloudでは、これは通常、ソース管理のベストプラクティス、Cloud BuildによるCI、Artifact Registryによるアーティファクト管理、Cloud DeployによるCD、マニフェスト・Helm・Kustomizeを使用したGKEによるKubernetes、設定ドリフト制御のためのGitOps、そしてTerraformまたはGoogle CloudのデプロイメントテンプレートによるIaCを組み合わせることで実現されます。オペレーショナルエクセレンスには、プログレッシブデリバリー（ブルーグリーン、カナリー、トラフィックスプリッティング、フィーチャーフラグ）、ソフトウェアサプライチェーン管理（スキャン、来歴、署名）、テストおよびデプロイゲート、そしてスピード、安全性、監査可能性、オーナーシップのバランスをとるガバナンスが求められます。

CI/CD、ソース管理、リリースオーケストレーション

• CI/CDの原則

  • master/mainを常にリリース可能な状態に保ち、短命なフィーチャーブランチを用いたトランクベース開発を実践する。
  • すべての変更に対してビルド、テスト、スキャン、パッケージを自動化し、必須の承認とステータスチェックを伴うコードレビューを要求する。
  • コミット→ビルド→アーティファクトダイジェスト→環境リリースまでの完全なトレーサビリティを維持し、コミットSHAとビルドメタデータをイメージとデプロイメントのアノテーションに埋め込む。
  • 失敗パターン：長期間存続するブランチ、手動の引き継ぎ、不安定なテスト、再現不可能なビルド、アーティファクトのイミュータビリティの欠如は、開発サイクルの後期での予期せぬ問題やロールバックにつながる。

• ソース管理、ブランチ戦略、プルリクエスト、コードレビュー、トレーサビリティ

  • 保護されたブランチ、必須レビュー、コミット署名を使用する。リリースにタグを付け、マージコミットから生成された変更履歴を維持する。
  • CODEOWNERSとサービスのオーナーシップメタデータを適用して、ドメインのスチュワードシップを強制する。
  • コミットを課題やデプロイに接続する。監査とDORAメトリクスのために、CI/CDのログとメタデータをCloud LoggingとBigQueryにエクスポートする。

• Cloud Build

  • トリガー：Gitイベント（ブランチ、タグ、PR）、手動実行、またはPub/Subで発火する。パイプラインをDRYに保つため、バージョン、環境、フィーチャーフラグの置換変数でパラメータ化する。
  • ビルドステップ：公式のビルダーまたは自身で定義したコンテナを実行する。独立している場合は並列ステップを使用してレイテンシを削減する。言語の依存関係にキャッシュを使用してビルドを高速化する。
  • アーティファクト：イミュータブルなタグとダイジェストを付けてArtifact Registryにイメージをプッシュする。SBOMとビルドログを保存する。テストレポートをビルドアーティファクトとして公開する。
  • ビルドIDの保護：最小権限の専用サービスアカウントでCloud Buildを実行し、可能な場合はリポジトリごとにWorkload Identity Federationを使用する。プライベートネットワークや下り（egress）トラフィックを避けるためには、Private Poolsを使用する。サービスアカウントキーを制限し、短命なトークンを優先する。
  • 例（短縮版）：
    • cloudbuild.yaml:
      • steps:
        • name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
        • name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
      • substitutions:
        • _ENV=staging

• Cloud Deploy

  • リリースとターゲット：ターゲット間（例：dev → staging → prod）でのプロモーションを伴うデリバリーパイプラインをモデル化する。リリースは、イミュータブルなアーティファクト参照とデプロイ設定をキャプチャする。
  • 承認とプロモーション：ロールベースの制御で手動または自動の承認を要求する。アーティファクトとマニフェストは変更されないため、プロモーションは高速で低リスクのアクションであるべき。
  • カナリーロールアウトとロールバック：段階的な公開、ヘルスチェック、SLOエラー時の自動ロールバックの戦略を定義する。監査のために、すべてのプロモーション、承認者、検証結果を記録する。
  • 失敗パターン：環境間で可変なアーティファクト、本番環境での手動kubectl実行、デプロイ前検証のスキップは、ドリフトと追跡不可能な障害を引き起こす。

Infrastructure as Code と構成管理

• Terraform

  • モジュール: 再利用可能なパターン（例: VPC、GKE クラスタ、サービスアカウント、IAM バインディング）をカプセル化します。モジュールのリリースをバージョン管理し、バージョンを固定（ピン留め）します。内部モジュールレジストリを公開します。
  • リモートステート: Cloud Storage にバージョニング、リテンションポリシー、CMEK を有効にして保存します。ロックを有効にし、IAM と均一なバケットレベルのアクセスでアクセスを制限します。ステートをバックアップします。
  • プランとポリシーチェック: CI で terraform fmt/validate/plan を実行します。プランに対する人によるレビューを必須とします。コードとしてのポリシー（OPA/Conftest、Sentinel、または Policy Controller）を適用して、違反（例: パブリックバケット、広範な IAM バインディング）をブロックします。
  • 環境プロモーション: 環境ごとに個別のワークスペースまたは個別のステート/バックエンドを使用します。同じモジュールバージョンと変数を使用して変更をプロモートします。クラウドリソースを手動で編集してはなりません。機密性の高い入力は Secret Manager または自動化から取得し、決してハードコーディングしないでください。
  • 障害モード: ステートへのシークレットの漏洩、ロックなしでの同時変更、Terraform 外での編集によるドリフト（構成乖離）、destroy/replace を破壊する暗黙的な依存関係。

• Google Cloud のデプロイテンプレートと宣言的な構成

  • 命令的なステップのスクリプトではなく、宣言的なツール（Terraform、Google Cloud Deployment Manager、または Kubernetes Configuration as Code）を使用して、望ましい状態を定義します。
  • イミュータブル（不変）なインフラストラクチャを推奨します: インスタンステンプレートを置き換え、MIG をローリングアップデートします。Pod をその場でパッチするのではなく、新しい GKE Deployment をロールアウトします。イミュータブルなパターンは、ロールバックと監査を簡素化します。
  • Deployment Manager は Google Cloud リソース用の Jinja/Python テンプレートをサポートしますが、Google Cloud に限定されます。Terraform はより広範なエコシステムとポリシー関連ツールを提供します。組織の標準化とスキルセットに基づいて選択します。

• Kubernetes マニフェスト、Helm、Kustomize、および GitOps

  • マニフェスト: ベーステンプレートと環境ごとのオーバーレイを保持します。環境によって異なるべきもの（例: レプリカ数、リミット、エンドポイント）のみをパラメータ化します。
  • Helm: チャートを使用してサービスをパッケージ化、テンプレート化、バージョン管理します。依存関係をロックし、イメージダイジェストをピン留めします。障害モード: 過度なテンプレート化は意図を不明瞭にし、レビューを複雑にします。
  • Kustomize: オーバーレイ（ベース + 環境ごとのパッチ）を管理します。純粋な Kubernetes で十分な場合は Helm よりもシンプルです。
  • GitOps: コントローラ（例: Config Sync、Argo CD、Flux）が、クラスタを Git 内の望ましい状態に継続的に調整（リコンサイル）します。すべての変更はレビューと監査証跡を伴う PR になります。ドリフトを自動的に検出して修正します。

プログレッシブデリバリー、サプライチェーン、テスト、および検証

• 機能フラグとトラフィック管理

  • 機能フラグはデプロイとリリースを分離します。段階的な公開、A/B テスト、緊急停止スイッチに使用します。フラグの状態がバージョン管理され、監査可能であることを保証します。古いフラグは廃止します。
  • トラフィックスプリッティング: Cloud Run ではリビジョン間でパーセンテージベースのルーティングを使用します。GKE では、加重ルーティングをサポートするサービスメッシュまたは Ingress コントローラを使用します。単一のホスト名/TLS 配下の API の場合、HTTP(S) Load Balancer の背後でパスごとに個別のバックエンドサービスを維持します。パスルーティングは、単一の URL と証明書を維持しつつ、新旧のバージョンをクリーンに分離します。
  • ブルーグリーン: 本番環境として準備ができた 2 つのスタックを実行します。ロードバランサ、サービスセレクタ、または Cloud Run のリビジョントラフィックを介して、トラフィックをアトミックに切り替えます。即時のロールバックを可能にしますが、定常状態のコストが 2 倍になります。
  • カナリアとプログレッシブロールアウト: ゴールデンシグナルとビジネス KPI を測定しながら、ごく一部から徐々にトラフィックを増やします。リグレッション（機能低下）が発生した場合は、ロールバックを自動化します。

• ソフトウェアサプライチェーンの管理

  • イメージスキャン: Artifact Analysis の脆弱性スキャンを有効にします。重大な脆弱性や既知の不正なベースイメージに対してはビルドを失敗させます。パッチ適用のケイデンスを維持します。
  • 来歴（Provenance）と署名: Cloud Build で SLSA 準拠のビルド来歴を生成します。Cosign でアーティファクトに署名します。デプロイ前に証明書（attestation）を要求する Binary Authorization ポリシーを適用します。
  • 依存関係の管理: バージョンとダイジェストをピン留めし、SBOM を維持し、重要な依存関係をベンダー化（vendoring）し、チェックサムを検証します。障害モードには、推移的な依存関係のドリフトや、侵害されたレジストリが含まれます。

• テストピラミッド、デプロイゲート、およびデプロイ後の検証

  • ピラミッド: 高速な単体テストを重視します。結合テストと契約テストを追加します。対象を絞ったエンドツーエンドテストを実行します。テストデータは現実的なものにし、非識別化します（Cloud DLP を使用して PII を削除）。
  • デプロイゲート: プロモーションの前に、テスト合格率、脆弱性のステータス、ポリシーコンプライアンス、コードレビューのしきい値を適用します。リスクが高い場合は、本番環境への手動承認を要求します。
  • デプロイ後の検証: Cloud Monitoring、Error Reporting、Trace を使用して、スモークテスト、合成チェック、カナリア分析を実行します。KPI が悪化した場合、自動ロールバックをトリガーし、キャプチャされたコンテキストとともにインシデントを起票します。
  • 運用診断: 必要な場所に Cloud Logging エージェントをデプロイし、Trace と Debugger のためにサービスを計装（instrument）します。安全な修復のためのランブックを維持します（例: 最小限のダウンタイムで永続ディスクをオンラインでサイズ変更し、resize2fs を実行する）。

ガバナンス、安全性、監査性、所有権

• 安全性と両立したスピード

  • 短命なPRと必須レビューを伴うトランクベース開発は、品質を犠牲にすることなくフローを維持します。
  • 一般的なスタック（GKE + Helm, Cloud Run, Dataflow）用のテンプレートを備えたセルフサービスパイプラインは、チームを加速させ、独自仕様のリスクを低減します。

• アクセス、アイデンティティ、承認

  • パイプラインのステージごとに専用のサービスアカウントを最小権限で使用し、Workload Identity Federationを利用します。静的なキーは避けてください。
  • 職務の分離：開発者はビルドし、リリースマネージャーは本番環境へのプロモーションを承認し、ランタイムオペレーターはランタイム構成と予算を所有します。

• 監査性とコンプライアンス

  • Cloud Build、Cloud Deploy、Cloud Audit LogsをBigQueryにエクスポートします。データセットビューとIAMを使用して、スコープを限定した監査データを監査人と共有します。ポリシーに従ってCloud StorageやBigQueryにエクスポートすることで、メトリクスを長期的に保持します。
  • デプロイメントメタデータにアーティファクトのダイジェストを記録します。各リリースについて、エンドツーエンドのSBOMと来歴を維持します。

• 所有権とSLO

  • 各サービスには、オーナー、オンコールローテーション、SLO、そしてリリースをゲートするエラーバジェットがあります。バジェットが枯渇しているときに変更をプッシュしないように、デプロイメントポリシーをSLOコンプライアンスに結びつけます。

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

  • ブルーグリーン方式のコスト vs ロールバックの速度、カナリアリリースの信頼性 vs 完全リリースまでの時間。
  • GitOpsの一貫性 vs 運用の柔軟性。ロギングとフォローアップPRを伴う、制御された緊急アクセス（break-glass）を許可します。
  • 過度なテンプレート化は可読性を低下させます。設定は明示的かつ最小限に保ちます。
  • 中央集権的なポリシーは設定ミスを防ぎますが、チームを不必要にブロックしないように、反復的に展開する必要があります。

実践的な問題シナリオ

企業：Borealis Fintech

課題：Borealis社は、v1とv2を同じホスト名とTLSの下で維持しつつ、GKE上に新しい決済APIをローンチしようとしています。彼らは、エンドツーエンドのトレーサビリティ、カナリアリリースとフィーチャーフラグによるプログレッシブデリバリー、強力なサプライチェーン管理、そして開発、ステージング、本番にわたる監査済みのプロモーションを必要としています。また、クラスター構成にはGitOpsを、プラットフォームリソースにはTerraformを使用したいと考えています。

アプローチ：

1. ソース管理とブランチ戦略の確立

   • サービスディレクトリを持つモノレポと、別のインフラ用リポジトリを作成します。保護されたmainブランチ、必須のPRレビュー、CODEOWNERS、署名付きコミットを強制します。論理的根拠：明確な所有権と監査対応可能な履歴を持つトランクベースのフロー。

2. Cloud BuildとArtifact Registryによるアーティファクトのビルド

   • cloudbuild.yamlを定義して、$COMMIT_SHAでタグ付けされ、SBOMと来歴でアノテーションが付けられたイメージをビルドし、プッシュします。最小権限を持つ専用のCloud BuildサービスアカウントとPrivate Poolを使用します。論理的根拠：追跡可能なダイジェストを持つ、再現可能で分離されたビルド。

   • 例：

undefined

3. ソフトウェアサプライチェーン管理の実装

   • Artifact Registryで脆弱性スキャンを有効にします。Cloud Buildのビルド後ステップで来歴を生成し、Cosignでイメージに署名します。GKEへのデプロイ前に署名とスキャン合格を要求するようにBinary Authorizationを設定します。論理的根拠：信頼できない、または脆弱なアーティファクトを強制時にブロックする。

4. Cloud Deployによるデリバリーのモデル化

   • dev、staging、prodをターゲットとし、prodにはカナリア戦略を用いたデリバリーパイプラインを定義します。prodへのプロモーションには、ロールベースの承認者による手動承認を要求します。論理的根拠：イミュータブルなプロモーションと監査可能な承認。

   • clouddeploy.yaml（抜粋）：

undefined

5. 同じホスト名でv1とv2のAPIをルーティング
   • 外部HTTP(S)ロードバランサを構成し、/v1と/v2パス用にそれぞれ別のバックエンドサービスを設定し、各々が対応するGKE NEGを指すようにします。論理的根拠：クリーンなパスベースの分離、同じ証明書とDNS、独立したデプロイ可能性。

   • 例（抜粋）：

undefined

6. Terraformによるインフラストラクチャ管理
   • VPC、GKE、Artifact Registry、サービスアカウント、IAM用のモジュールを作成します。リモートステートは、バージョニングとリテンションが設定されたCMEK保護のCloud Storageバケットに保存します。CIでOPAポリシーを強制し、リスクのある変更を防ぎます。論理的根拠：再利用可能で、レビュー可能で、統制されたプラットフォームのプロビジョニング。

undefined

7. Helm/KustomizeとGitOpsによるKubernetesの構成

   • Kustomizeを使用して、APIのベースマニフェストと環境ごとのオーバーレイを維持します。Config SyncまたはArgo CDを使用して、クラスターをGitの状態に調整します。論理的根拠：宣言的で、監査可能で、ドリフトに強い運用。

8. カナリアリリースとフィーチャーフラグによるプログレッシブデリバリー

   • 本番環境にはCloud Deployのカナリアリリースを、新しいロジックをゲートするためにはフィーチャーフラグSDK（OpenFeature）を使用します。トラフィックの5%から開始し、SLOが健全であれば自動的にプロモートし、悪化した場合は自動的にロールバックします。また、フラグをキルスイッチとして使用します。論理的根拠：影響範囲（blast radius）を縮小し、デプロイとリリースを分離する。

9. 品質ゲートと検証

   • パイプラインのステージ：単体テスト → エフェメラル環境に対する統合テスト → コンテナスキャン → ポリシーチェック → ステージングでのエンドツーエンドテスト → 自動化されたSLOベースの検証（Cloud Monitoring、Error Reporting、Trace）を伴う本番カナリアリリース。論理的根拠：早期の迅速なフィードバック、本番前の強力な安全性、デプロイ後の客観的なヘルスチェック。

10. 運用、ロギング、監査

    • サポートVMにCloud Logging/Monitoringエージェントをインストールし、GKEワークロードのログ/メトリクスを有効にします。CI/CDログと監査ログをBigQueryにエクスポートし、監査人用にスコープを限定したビューを提供します。ランブック（安全なロールバックや緊急時のDNS/LB切り替え手順を含む）を維持します。論理的根拠：迅速な修正のための可観測性と、コンプライアンス対応の証拠。

この設計は、トランクベースのフローと自動化されたパイプラインによるスピード、カナリアリリース、フィーチャーフラグ、Binary Authorizationによる安全性、イミュータブルなアーティファクト、承認、中央集権化されたログによる監査性、そしてCODEOWNERSとGitOpsで管理された環境による明確な所有権を維持します。

← オペレーション、オブザーバビリティ、プラットフォームの自動化 · すべてのドメイン · コスト、パフォーマンス、持続可能なクラウド設計 →

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

Googleを閲覧 →