Google PCD: コンピューティング、コンテナ、サーバーレスランタイムプラットフォーム — 学習ガイド

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

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

概要

Google Cloudは、サーバーレス、コンテナ、仮想マシンにまたがる複数のランタイムプラットフォームを提供しています。適切なプラットフォームの選択は、リクエストパターン、状態管理、ビルドとリリースの規律、運用モデル、ネットワークの制約といったワークロードの特性に依存します。このセクションでは、Cloud Run、App Engine、Cloud Functions、Google Kubernetes Engine (GKE)、Compute Engineの設計原則、障害モード、トレードオフについて、またイメージ、ID、ネットワーキング、構成、運用をサポートするサービスとともに解説します。

サーバーレスランタイム: Cloud Run, App Engine, Cloud Functions

Cloud Run

モデル: HTTPリクエストを処理するフルマネージドコンテナ、または完了まで実行されるコンテナ化されたジョブ。
リビジョンとトラフィック: デプロイごとに不変のリビジョンが作成されます。リビジョン間でトラフィックをパーセンテージで分割することにより、カナリアパターンやブルーグリーンパターンが可能になり、即時ロールバックも実現できます。例:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

同時実行数とスケーリング: デフォルトの同時実行数は80です。CPUバウンドまたはスレッドセーフでないコードの場合は1に設定します。同時実行数を高くすると、コールドスタートの増幅とコストを削減できますが、リクエストあたりのCPU/メモリが不十分な場合、テールレイテンシが増加する可能性があります。Cloud Runは受信リクエストレートに基づいてゼロまで、またゼロからスケールします。コールドスタートを削減し、コストを抑制するために、最小/最大インスタンス数で制御します。
CPU割り当て: リクエスト間のバックグラウンド処理を行う場合は、追加の課金を許容して「CPUを常に割り当てる」を選択します。それ以外の場合、CPUはリクエスト処理中にのみ割り当てられます。
ジョブ: Cloud Runジョブは、タスクごとの最大再試行回数と全体のタイムアウトを設定して、完了するまでN個のタスクを並列実行します。ETL、バッチ、ファンアウト処理に適しています。障害モードには、多くのタスクが同じ依存関係をターゲットにする際のバックエンドのホットスポット化が含まれます。レート制限とバックオフ付きの再試行を追加してください。
ネットワーキング: パブリック、IAMによる認証、またはServerless VPC AccessとPrivate Service Connectを介したVPC背後のプライベート。

App Engine

環境:
- Standard: サンドボックス化され、迅速なスケールが可能で、言語ごとに固定のランタイム。自動スケーリングによる低いコールドスタートレイテンシ。ファイルシステムへのアクセス、リクエストタイムアウト、受信リクエストサイズに制限があります。大きなアップロードにはCloud Storageの署名付きURLを使用します。
- Flexible: Dockerベースで、VMのような機能、カスタムランタイム、Standardより遅いスケールアップ、バックグラウンドスレッドとローカルディスクへの書き込みをサポートします。
サービスとバージョン: 1つのサービス（マイクロサービス）は複数のバージョンをホストできます。Cloud Runと同様に、バージョン間でトラフィックをパーセンテージでルーティングします。外部ロードバランサーなしでシンプルかつ集中化されたルーティングを行うには、dispatch.yamlを使用して特定のパスやホストをサービスにルーティングします。
スケーリング: Standardでは手動、基本、または自動。FlexibleではVM数ベースのスケーリング。トレードオフ: アグレッシブなオートスケーリングは応答性を向上させますが、コストとバックエンドの競合を増加させる可能性があります。
よくある落とし穴: クォータなしでインスタンス規模を無制限にすると、ダウンストリームシステムに過負荷をかける可能性があります。クォータとサーキットブレーカーを適用してください。

Cloud Functions

イベント駆動ハンドラ: HTTP、Pub/Sub、Cloud Storage、またはEventarcイベントによってトリガーされます。第2世代を使用して、Cloud Runの実行モデル、VPC egress制御、同時実行数を活用します。第1世代は一度に1つのリクエストを処理します。
再試行とべき等性: バックグラウンド関数は失敗時に再試行される可能性があります。二重処理を避けるために、べき等なハンドラを設計し、重複排除キーを使用してください。HTTPトリガーはプラットフォームによって再試行されません。クライアント側で指数バックオフ付きの再試行を実装してください。
ランタイム構成: 環境変数、Secret Managerとの統合、関数ごとの同時実行数/最大インスタンス数。暴走コストを抑制するためにタイムアウトを設定します。依存関係が大きい場合の長いコールドスタートに注意し、パッケージをスリムに保ってください。

Google Kubernetes Engine上のコンテナ

ワークロード

Deployments: ローリングアップデートを伴うステートレスなPod。サージ/利用不可の上限を設定して安全なロールアウトを確保します:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

StatefulSets: 順序付けられ、安定したネットワークIDと永続ボリュームを持つステートフルサービス用。
DaemonSets, Jobs, CronJobs: ノードレベルのエージェントとバッチワークロード。

ServiceとIngress

Serviceタイプ:
- ClusterIP (内部専用)。
- NodePort (シンプルな外部アクセス用、運用上の制限あり)。
- LoadBalancer (リージョン単位の外部/内部ロードバランシング用)。
Ingress: HTTP(S)ルーティングとTLS終端。L7ポリシーには、マネージドコントローラを備えたGateway APIまたはIngressを推奨します。障害モード: ファイアウォールによるヘルスチェックの失敗。ロードバランサーのIP範囲からバックエンドノードへのアクセスを許可してください。

オートスケーリングとノードプール

Horizontal Pod Autoscaler (HPA): CPU、メモリ、またはカスタムメトリクスに基づいてPodをスケールします。可用性を保護するためにPod Disruption Budgetsと組み合わせます。
Vertical Pod Autoscaler (VPA): Podのリクエスト/リミットを適正なサイズにします。フィードバックループを防ぐため、同じディメンションでHPAとVPAを同時に使用することは避けてください。
Cluster Autoscaler: 保留中のPodのリソースリクエストを満たすためにノードを追加/削除します。
ノードプール: ワークロードクラスごとにプールを分離します。スケジューリングにはtaints/tolerationsとラベルを使用します。中断耐性のあるコスト重視のワークロードには、スポット/プリエンプティブルVMを混在させます。スロットリングを避けるため、Podごとのリミットに対して十分なメモリ帯域幅/CPUを持つマシンタイプを選択してください。

ヘルスチェックとロールアウト

Liveness、readiness、startupプローブは、準備ができていないPodへのトラフィック送信を防ぎ、デッドロックしたコンテナを再起動します。厳しいlivenessプローブはカスケード的な再起動を引き起こす可能性があります。初期遅延と失敗のしきい値を調整してください。
kubectl rollout undoでロールバックします。カナリアリリースには、複数のDeploymentとIngress/Gatewayを介したServiceレベルのトラフィック分割を使用します。

アプリケーションワークロードのための Compute Engine

VM の設計

インスタンステンプレートは、マシンタイプ、イメージ、ディスク、サービスアカウントのスコープ、起動スクリプト、メタデータを定義します。イメージは最小限に保ち、起動スクリプトや Packer で作成したイメージを使用して、決定論的な起動を実現します。
ディスク: レイテンシに敏感なアプリには、バランス永続ディスクまたは SSD 永続ディスクを使用します。大規模な読み取り専用データセットは、読み取り専用の永続ディスクを複数のインスタンスにアタッチしてマネージドインスタンスグループ全体で共有し、低レイテンシと迅速な起動を実現します。
ネットワーキング: ロードバランサを使用する場合は、ヘルスチェッカー用のファイアウォールルールを作成します。例:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

マネージドインスタンスグループ (MIG)

CPU、ロードバランサの秒間リクエスト数、カスタム指標、またはスケジュールによるオートスケーリング。スラッシングを防ぐためにクールダウン期間を設定します。
ヘルスチェックによる自動修復は、異常な VM を再起動します。500 エラーを返さないように、ヘルスチェックのパスではポートの到達可能性だけでなく、アプリケーションの準備状況をテストするようにしてください。
ローリングアップデートとブルーグリーン: 新しいインスタンステンプレートを作成し、インスタンスのサブセットに対してカナリアアップデートを開始します。エラーが増加した場合は、前のテンプレートにロールバックします。稼働時間チェックと SLO ベースのアラートにより、パフォーマンスの低下を迅速に検出します。

ロギングとモニタリング

エージェントをインストールして、コードを変更せずにアプリのログを収集します。Cloud Logging に転送し、Cloud Monitoring を介してアラートを送信します。本番環境での診断には、中断を最小限に抑える Debug Logpoints を使用します。

ビルド、ID、ネットワーキング、シークレット、運用

Artifact Registryとイメージ

コンテナイメージと言語アーティファクトにはArtifact Registryを使用します。脆弱性スキャンと来歴生成を有効にします。イメージは小さく保ちます：
- ビルドとランタイムを分離するためのマルチステージビルド。
- 最終イメージに開発ツールを含めないようにし、OSとパッケージのバージョンを固定します。例：

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

プロモーション：イメージには不変のタグ（例：app:1.3.7, app:prod-20240901）を付け、Artifact Registryで再タグ付けしてプロモートします。本番環境では可変のlatestタグの使用を避けます。統合テストとカナリアテストの結果でプロモーションをゲートします。

ランタイムIDと最小権限

ワークロードごとに専用のサービスアカウントを割り当て、必要最小限のIAMロールを付与します。Editorのような広範なロールは避けます。GKEでは、Workload Identityを介してKubernetesのServiceAccountをGoogleのサービスアカウントにマッピングします。サーバーレスでは、ランタイムサービスアカウントを明示的に設定し、default-tokenスコープを削除します。

VPCコネクタとサービスネットワーキング

Serverless VPC Accessコネクタは、Cloud Run、Cloud Functions、App Engineからの下り（egress）トラフィックをVPCにルーティングします。下りモードを選択します：
- プライベートレンジのみ：RFC1918およびVPC接続サービスに到達するために使用し、パブリックへの下りトラフィックは直接送信されます。
- すべてのトラフィック：コネクタ経由で送信し、Cloud NATを併用して決定論的な下りIPと制限付きアウトバウンドポリシーを実現します。
プライベートな依存関係：Cloud SQLにはプライベートIPを、Google APIやパートナーサービスにはPrivate Service Connectを優先的に使用します。コネクタがリージョンと一致し、スループットに合わせてサイズ設定されていることを確認します。スロットリングを避けるためにコネクタのCPUを監視します。

設定、シークレット、ヘルスチェック

機密でない設定には環境変数を使用します。シークレットはSecret Managerに保存し、ランタイムにマウントまたは注入します。キーは定期的にローテーションします。GKEでは、Secret Manager用のSecretsとCSIドライバを使用します。App EngineとCloud Runでは、サービスアカウントに特定のシークレットへのアクセス権を付与します。
ヘルスチェック：
- Cloud Run：クラッシュ時にインスタンスが再起動します。リクエストレベルのチェックとレイテンシーSLIを使用します。
- App Engine：組み込みのヘルスチェック。Flexible Environmentではliveness/readinessをカスタマイズします。
- GKE：liveness/readiness/startupプローブを設定します。
- LB配下のCompute Engine：アプリケーション固有のエンドポイントを持つHTTP(S)ヘルスチェックを使用します。

トラブルシューティング、ロールバック、リリースパターン

Cloud RunとApp Engineではトラフィックスプリッティングによるブルーグリーンおよびカナリアリリース。GKEでは、並列のDeploymentまたはプログレッシブデリバリーコントローラーを使用。MIGでは、インスタンスのカナリアサブセットを使用します。常にSLOのエラーバジェットとレイテンシーに基づいて中止基準を定義します。
一般的な障害モード：
- スケールトゥゼロ後や大規模なロールアウト後のサンダリングハード現象。最小インスタンス、ウォームアップ、レート制限で緩和します。
- バックエンドのクォータや接続制限の超過。エクスポネンシャルバックオフとサーキットブレーカーを適用します。
- 大きなイメージや依存関係によるコールドスタート。イメージをスリム化し、クライアントを事前初期化します。

実践的な問題シナリオ

Acme Retail社は、画像リサイズAPIを自己管理のVMから、低レイテンシー応答、リージョンCloud Storageバケットへのプライベートアクセス、安全なカナリアリリースが可能な、スケーラブルでコスト効率の高いプラットフォームに移行する計画を立てています。

アプローチ

サービスを小さなコンテナイメージとしてパッケージ化し、Artifact Registryに公開します。

理由：スリムなマルチステージのDockerビルドは、コールドスタートとネットワーク転送を最小限に抑えます。Artifact Registryは、スキャンとプロモーションのワークフローを一元化します。

APIをCloud Runにデプロイし、最小インスタンス数を2、同時実行数を40に設定し、CPUの常時割り当てを無効にします。

理由：Cloud Runは、即時の水平スケーリングとマネージドHTTPSを提供します。小さな最小インスタンスプールは、日中のピーク時のコールドスタートレイテンシーを削減します。同時実行数40は、I/Oバウンドな画像変換におけるコストとテールレイテンシーのバランスを取ります。CPUの常時割り当てを無効にすることで、リクエスト間のアイドルなコンピューティングに対する支払いを回避できます。

Serverless VPC Accessコネクタを作成し、下り（egress）をプライベートレンジのみに設定します。サブネットでPrivate Google Accessを有効にし、必要に応じてCloud Storage用のVPC-SCまたはPrivate Service Connectエンドポイントを設定します。

理由：APIは、パブリックな下りトラフィックなしで、プライベートに画像をフェッチおよび書き込みする必要があります。プライベートレンジモードは、VPCトラフィックのみがコネクタを通過することを保証し、パブリックな呼び出しは直接かつ効率的に保ちます。Private Google AccessまたはPrivate Service Connectは、VPCからGoogle APIへのプライベートアクセスを提供します。

専用のランタイムサービスアカウントに、対象のCloud Storageバケットと必要なシークレットに対する最小権限のアクセスを付与します。

理由：最小権限の原則は、影響範囲（blast radius）を限定します。ランタイムIDは、特定のバケットに対するstorage.objectViewerとstorage.objectAdmin、および必要なSecret Managerのシークレットに対するaccessorロールを受け取ります。

APIキーと環境ごとの設定をSecret Managerと環境変数に保存し、ランタイムにシークレットを注入します。

理由：一元化されたシークレットのローテーションと監査可能なアクセス。環境変数による機密でない設定は、12-factorの実践をサポートします。

Cloud Storageからの429/5xxエラーを処理するために、エクスポネンシャルバックオフとべき等の書き込みを実装します。

理由：バースト時やリージョンイベント中には、一時的なエラーが発生する可能性があります。ジッター付きのバックオフは、APIとCloud Storageの両方をリトライの嵐から保護します。

カナリアリビジョンを設定し、トラフィックの10%をそれに分割します。エラー率、P95レイテンシー、飽和度を監視します。

理由：Cloud Runでのトラフィックスプリッティングは、安全なプログレッシブロールアウトを可能にします。SLOベースのモニターは、エラーバジェットが急速に消費された場合に自動的なロールバックトリガーを提供します。

下流の依存関係をテストするHTTPヘルスエンドポイントを追加します。Cloud Monitoringの稼働時間チェックとログベースのメトリクスにアラートを設定します。

理由：エンドツーエンドのヘルスチェックは、依存関係の障害を早期に検出します。稼働時間チェックは外部からの視点を提供し、ログベースのメトリクスはアプリケーション固有の障害パターンをキャプチャします。

自動スケーリングの制限と予算を設定します。最大インスタンス数を設定して支出に上限を設け、過負荷に対する429の処理を定義します。

理由：スケールを制限することで、コストの暴走とバックエンドの枯渇を防ぎます。優雅な過負荷処理は、サービスの安定性を維持します。

ロールバック手順を文書化します：単一のコマンドでトラフィックの100%を以前のCloud Runリビジョンに戻します。

理由：不変のリビジョンにより、ロールバックは安全かつ迅速になり、平均修復時間（MTTR）を最小限に抑えます。

← クラウドネイティブアプリケーションアーキテクチャとサービス選択 · すべてのドメイン · API設計、統合、イベント駆動開発 →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

試験に合格する →

Googleを閲覧 →