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サービスを使用して、信頼性を考慮した設計、リスクの分離、環境間でのビルドの安全なプロモート方法について詳しく説明します。

テスト戦略とデータ管理

テストピラミッドとテストの種類

• 単体テスト: 関数、クラス、小さなモジュールの高速で分離された検証。これらがテストスイートの大半を占めるべきです。コミットごと、プルリクエストごとに実行します。
• 統合テスト: アプリケーションとそのデータストアやキューなど、コンポーネント間の相互作用を検証します。可能な場合はGoogle Cloudエミュレータを使用します。
• 契約テスト: マイクロサービスにおけるコンシューマ駆動契約は、APIの破壊的変更を防ぎます。統合前に、プロバイダの動作がコンシューマの期待するスキーマとセマンティクスに準拠しているかを検証します。Pactなどのツールを使用し、APIをバージョニングしてスキーマを公開します。
• エンドツーエンドテスト: 本番同様の構成、ID、ネットワークポリシーを使用して、システム全体のパスをテストします。テスト数を制限し、並列化し、本番前環境で実行します。
• スモークテスト: 各デプロイ後に、重要な依存関係、ルート、ヘルスチェックが正しく動作することを確認する最小限のプローブ。これらはデプロイ後の最初の検証です。

テストデータの管理、分離、再現性、環境パリティ

• データシーディング: 単体テスト用に小さく決定論的なデータセットを、統合/パフォーマンステスト用に大きく代表的なデータセットを生成します。ソース管理にチェックインされたフィクスチャからシードします。
• 分離: テストが状態を共有しないようにします。エフェメラルなデータベース、分離されたGKE名前空間、Cloud Storageオブジェクトの一意なプレフィックスを使用します。SQLの場合はテストごとにスキーマを作成し、Pub/Subの場合は一時的なトピック/サブスクリプションを生成します。
• 再現性: 依存関係のバージョンを固定し、ビルドをハーメティックにし、ランダムシードを固定します。テストコンテナをダイジェスト付きでArtifact Registryに保存します。
• 環境パリティ: 開発、QA、ステージング、本番環境にわたって、コンテナイメージとInfrastructure-as-Codeを標準化します。構成をイメージから分離し、環境固有のメタデータとシークレットを使用します。Compute Engineでは、デプロイごとの値をインスタンステンプレートのメタデータに保存します。プロジェクト間のパリティを保つには、環境メタデータキーを設定し、起動時にそれを読み取って環境固有の構成を選択します。

モック、エミュレータ、フェイク、サンドボックスサービス

• モック/スタブ: 単体テストレベルで協調オブジェクトを置き換えて、ロジックを分離し、ネットワーク呼び出しを削減します。過度なモックは避けます。実装の詳細ではなく、振る舞いに対してアサーションを行います。
• エミュレータ: 統合テストには公式エミュレータの使用を推奨します。例：Firestore/Datastore、Pub/Sub、Spanner、Bigtableエミュレータ。これらはクラウド料金なしでAPIの忠実性を提供し、CIを高速化します。
• フェイク: エミュレータが存在しない場合、軽量なローカルフェイク（例：フェイクオブジェクトストア）や、強力な分離とクォータを持つ共有サンドボックスサービスを実行します。
• 外部依存関係のシミュレーション: サードパーティAPIについては、サービスメッシュやAPIゲートウェイの背後で契約ベースのフェイクを実行します。タイムアウト、リトライ、カオスインジェクションを設定して、障害処理をテストします。

一般的な障害モードとトレードオフ

• エンドツーエンドテストへの過度な依存はイテレーションを遅らせます。問題を早期に発見するために、単体テストと契約テストに投資します。
• 共有された長寿命のテスト環境は、ドリフトとデータの汚染を蓄積します。エフェメラルな環境と、べき等なセットアップ/ティアダウンを推奨します。
• エミュレータは本番環境を完全に模倣しない場合があります。プロモート前に、実際のサービスを使用したステージング環境でのE2Eテストを実施します。

失敗したステージを分離するためのCloud Buildの短い例

steps:
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make compile && make unit']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'docker build -t $IMAGE .']
- name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args: ['-c', 'make integration']  # run against emulators or ephemeral env
images: ['$IMAGE']

ステップを分離することで、ビルド履歴がコンパイル/単体テスト、ビルド、統合テストのいずれで失敗したかを特定できます。

非機能テストとコード品質

パフォーマンステスト

• 種類: 負荷（定常状態）、ストレステスト（ピーク超）、ソーク（長時間）、キャパシティテスト。
• ツール: SLOとアラートにはCloud Monitoringを、レイテンシーの内訳にはCloud Traceを、ホットパスの特定にはCloud Profilerを使用します。GKEではCluster AutoscalerとHPAでスケールし、Pub/Subワーカーでは外部メトリクスに対するHPAがスパイク駆動のスケーリングを処理します。
• 本番環境でのテスト: ダークローンチとリクエストミラーリングを使用して、本番トラフィックで新しいバックエンドを安全に評価します。External HTTP(S) Load Balancingはリクエストミラーリングをサポートし、Anthos Service Meshはトラフィックシャドウイングをサポートします。

セキュリティテスト

• SAST/シークレットスキャン: CIで静的アナライザを実行し、ハードコードされた認証情報を拒否します。シークレットは最小権限アクセスでSecret Managerに保存します。
• 依存関係とイメージのスキャン: Artifact RegistryでContainer Analysisを有効にします。デプロイ前に重大な脆弱性が存在しないことを証明するattestationを要求するBinary Authorizationでポリシーを強制します。
• DAST: 認証済みスキャナでステージング環境をスキャンし、重大な発見があった場合はリリースをブロックします。

アクセシビリティとリグレッション

• アクセシビリティ: 自動化されたa11yチェック（例：Lighthouse CI）を、ブロックしないマージ前チェックに統合し、リリース前に修正します。
• リグレッションスイート: 重要なジャーニーのために、厳選された安定したリグレッションスイートを維持します。すべてのデプロイでスモークテストを実行し、リリース候補で完全なリグレッションテストを実行します。

静的解析、品質ゲート、コードレビュー

• 静的解析: 言語に適したリンターとフォーマッターをサブミット前チェックとして設定します。Bazelなどを使用して並列化します。
• 品質ゲート: しきい値（カバレッジ、複雑度、リントエラー）を超えた場合はビルドを失敗させます。結果をCloud Buildのログに公開します。
• コードレビュー: リスクの高い変更には2人によるレビューを、重要なパスにはCODEOWNERSを、リリースに使用されるタグにはサブミット前CIを要求します。
• サプライチェーン: SBOMを生成し、アーティファクトに署名し、来歴を保存します。Binary Authorizationでattestationチェックを強制します。

プログレッシブデリバリーと安全なリリース

デプロイ戦略

• ローリング: Podやインスタンスを段階的に置き換えます。ステートレスサービスにとっては低リスクです。readiness probeやサージ/可用性の設定と組み合わせます。
• Blue/Green: 完全な新しい環境を立ち上げ、検証を実行してから、トラフィックを切り替えます。ロードバランサーを元に戻すことで、即時のロールバックが可能です。即時のフォールバックが必要な場合に最適です。
• カナリア: 主要なメトリクスを監視しながら、トラフィックの小さな割合を新しいバージョンに徐々に移行します。正常であれば昇格を自動化し、リグレッションが発生した場合はロールバックします。
• トラフィックスプリッティング: GKEとAnthos Service Meshを使用して、パーセンテージや属性（ヘッダー、Cookie、user-agent）によってルーティングします。または、Cloud RunやApp Engineの組み込みの分割機能を使用します。

機能フラグと実験

• 機能フラグ: デプロイとリリースを分離します。フラグは、段階的なロールアウト、キルスイッチ、実験用のトグルに使用します。一元的に保存します（例: マネージドフラグサービス、IAMで保護された設定ストア）。フラグのライフタイムは短く保ち、不要なものは削除します。
• ダークローンチ: 機能を無効にしてデプロイし、内部ユーザーや合成トラフィックを介して検証します。
• シャドートラフィック: ユーザーに影響を与えることなく、本番環境のリクエストを新しいサービスにミラーリングします。レスポンスを比較してリグレッションを検出します。
• 制御された実験: サービスメッシュのルールを使用して、A/Bテストや多変量ルーティングを実装します。user-agentベースの実験では、ヘッダーマッチによってルーティングします。

ゲート、承認、ロールバック、オブザーバビリティ

• デプロイメントゲート: デプロイ前の統合テストとデプロイ後のスモーク/ヘルスチェックを追加します。環境のプロモーションには、タグベースのトリガーを使用してビルドとリリースを分離します。
• 手動承認: ステージングから本番環境への移行などのマイルストーンで、人間の承認を要求します。Cloud Deployは、ターゲットごとの手動承認ステップをサポートしています。
• 自動ロールバック: SLOとアラートポリシーを定義します。カナリアがエラー率やレイテンシのしきい値に違反した場合、デプロイAPIを呼び出して自動的にロールバックします。ロールバックは迅速かつ十分に実践された状態に保ちます。
• リリースのオブザーバビリティ: メトリクスとログにバージョンラベルを付けてリリースを計測します。PrometheusメトリクスをCloud Monitoringにエクスポートし、エラーパターンのログベースのメトリクスを作成して、テレメトリーを費用対効果の高い方法で関連付けます。

ヘッダーベースのカナリアのための短いASMルーティングの例

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Android.*"
    route:
    - destination: { host: svc, subset: v2 }  # canary
  - route:
    - destination: { host: svc, subset: v1 }  # stable

テストの信頼性、フィードバックループ、リリース後の規律

フレーキーテストの管理と信頼性

• 検出と隔離: テストのフレーキーさ（不安定さ）を時系列で追跡し、既知のフレーキーテストを隔離します。修正を優先する間、それらのテストによってリリースがブロックされないようにします。
• タイムアウトとリトライ: 適切なタイムアウトを追加します。ロジックの失敗ではなく、インフラ起因のフレーキーさが疑われる場合は、1回のリトライを許可します。
• ハーメチックビルド: ユニットテストでのネットワーク呼び出しを避けます。アーティファクトを固定し、エミュレータを使用して非決定性を減らします。
• 並列化: フィードバックの遅延を最小限に抑えるため、Cloud Buildで複数のステップまたはワーカーにテストをシャーディングします。

フィードバックループ

• CIトリガー: mainブランチとプルリクエストへのすべてのコミットで、ユニットテストとインテグレーションテストを実行します。Cloud Buildのステップを分けることで、ビルド履歴で失敗したステージを特定できるようにします。デプロイを制御するため、すべてのコミットではなくGitタグに対してリリーストリガーを作成します。
• プログレッシブ検証: Cloud DeployのPub/Sub通知をサブスクライブし、SUCCEEDEDイベントでプロモーションを呼び出すことにより、デプロイ成功時に開発環境からテスト環境へ自動的にプロモートします。
• メトリクス駆動のプロモーション: カナリアリリースでは、Cloud MonitoringのメトリクスとSLOに基づいてトラフィックの増加をゲートします。

リリースのドキュメント、オーナーシップ、リリース後の検証

• ドキュメント: リリースノート、ランブック、ロールバック手順をコードの近くで管理します。コミット、イメージ、環境のバージョンへのリンクを含む変更チケットを追跡します。
• オーナーシップ: オンコールローテーションとコンポーネントのオーナーを定義します。機密性の高いエリアにはCODEOWNERSを強制します。本番環境へのプロモーションに対する明確な承認者を確保します。
• リリース後の検証: スモークスイートを実行し、エラーバジェットが健全な状態を維持していることを確認し、バージョンタグでダッシュボードを検証します。セキュリティおよび脆弱性レポートがポリシー内に収まっていることを確認します。問題が発生した場合は、まずロールバックし、次に根本原因を分析します。

実践的な問題シナリオ

Acme Retailのプラットフォームチームは、GKEベースのマイクロサービスアプリケーションのテストとリリースを標準化しています。このアプリケーションには、Cloud Run上のステートレスなWebフロントエンドも含まれています。彼らは、ライブトラフィックを使用してパフォーマンスを評価しつつ、迅速なフィードバックを確保し、リスクのあるビルドをブロックし、新機能を安全にロールアウトする必要があります。

アプローチ

1. Cloud Buildでビルドとテストのステージを分離する

• 根拠: コンパイル、ユニットテストの実行、コンテナのビルド、インテグレーションテストの実行に個別のステップを使用することで、ビルド履歴で失敗したフェーズを特定し、開発者が実用的なフィードバックを迅速に得られるようにします。
• 例:

steps:
- name: gcr.io/cloud-builders/docker
  args: ['build', '-t', '$IMAGE', '.']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make unit']
- name: gcr.io/cloud-builders/gcloud
  args: ['bash','-lc','make integration']  # against emulators
images: ['$IMAGE']

2. エミュレータとエフェメラルな名前空間に対してインテグレーションテストを実行する

• 根拠: Pub/SubワーカーとFirestoreを利用するサービスには、Pub/SubおよびFirestoreエミュレータを使用します。クラスタポリシーを必要とするサービスには、Workload Identityを介して一時的なトピックとサービスアカウントを持つエフェメラルなGKE名前空間をビルドごとに作成します。これにより、忠実度を維持しながら、分離性、速度、低コストを実現します。

3. Artifact RegistryとBinary Authorizationでセキュリティ品質ゲートを強制する

• 根拠: イメージのプッシュ時に脆弱性スキャンを有効にし、重大なCVEが見つかった場合はパイプラインを失敗させ、GKEにデプロイする前にBinary Authorizationで証明を要求します。これにより、既知の重大な脆弱性を持つイメージのデプロイを防ぎます。

4. Gitタグベースのリリーストリガーを使用する

• 根拠: Cloud Buildのタグ（例: vX.Y.Z）に対するトリガーにより、明示的にタグ付けされたコミットに対してのみリリースが自動化され、mainへのすべてのコミットから意図せず本番デプロイが行われるのを防ぎます。

5. Cloud DeployとAnthos Service Meshによるプログレッシブデリバリー

• 根拠: 開発、テスト、本番のターゲットを持つCloud Deployパイプラインを定義します。手動承認を使用して、本番環境へのプロモーションをゲートします。本番環境では、SLOを監視しながらASMを使用して5%、25%、50%、100%とトラフィックをシフトするカナリア戦略を使用します。Cloud Deployは検証フックをサブスクライブし、失敗した場合はAPI経由でカナリアを自動的に停止またはロールバックします。

6. 可観測性と自動ロールバックフック

• 根拠: PrometheusメトリクスをCloud Monitoringにエクスポートし、エラーシグネチャ用のログベースのメトリクスを作成します。バージョンラベル付きのメトリクスにアラートポリシーを設定します。アラートをサブスクライブしたCloud FunctionがCloud Deploy APIを呼び出し、ロールアウトを一時停止またはロールバックします。これにより、客観的な健全性シグナルをデプロイ制御に結びつけます。

7. Cloud RunフロントエンドのシャドートラフィックとA/B検証

• 根拠: 外部HTTP(S)ロードバランサでリクエストミラーリングを使用して、ユーザーに影響を与えることなく、本番リクエストを新しいCloud Runリビジョンに送信します。その後、Cloud Runのトラフィックスプリッティングを使用して、少量のパーセンテージをシフトし、完全な切り替えの前にレイテンシ/エラーメトリクスを比較します。

8. クリティカルなバックエンドサービスのブルーグリーンフォールバック

• 根拠: 即時のロールバックが必要なサービスについては、単一のバックエンドサービスの背後でブルーとグリーンのデプロイメントを維持します。スモークテストと契約テストでグリーンを検証した後、トラフィックを切り替えます。異常が検出された場合は即座に元に戻します。

9. リリース後の検証とドキュメント化

• 根拠: プロモーション後、自動化されたスモークテストを実行し、リリースバージョンでダッシュボードを検証し、アーティファクトのダイジェストとロールアウト履歴でリリースノートを更新します。オーナーシップとオンコール担当者が引き継ぎを受けます。エラーバジェットが消費された場合は、まずロールバックし、その後で非難のない分析を実施します。

このアプローチは、CIで高速かつ信頼性の高いフィードバックを提供し、セキュリティと品質を確保し、属性ベースの実験と必要な際の即時ロールバックの両方をサポートする、安全で可観測性の高いロールアウト戦略を使用します。

← パフォーマンス、スケーラビリティ、回復性エンジニアリング · すべてのドメイン · コスト、ガバナンス、持続可能なアプリケーション運用 →

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

Googleを閲覧 →