Google PCD: API設計、統合、イベント駆動開発 — 学習ガイド

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

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

概要

Google Cloudにおけるモダンなアプリケーション統合は、適切に設計された同期APIと、回復力のある非同期およびイベント駆動パターンを融合させます。その目的は、明確な契約、強力なアイデンティティ、一貫したエラーハンドリング、そして運用制御を提供し、障害、スケーリング、または変更の状況下でも、低レイテンシと高可用性を維持することです。このセクションでは、プロトコルとAPIの選択、ゲートウェイと認証、メッセージングとイベントルーティング、バックグラウンドワーク、オーケストレーション、サービス間のアイデンティティと信頼、信頼性パターン、セキュアなWebhook、そして安全なスキーマ進化について説明します。

APIの設計と管理

適切なプロトコルの選択:

REST: 人間が読みやすく、HTTP経由でキャッシュ可能であり、パブリックAPIやパートナーAPIに適しています。リソース指向の設計、標準メソッド、ETag、そして価値がある場合にのみHATEOASを使用します。トレードオフ: Protobufよりも契約の精度が低く、オーバーフェッチング/アンダーフェッチングの可能性があります。
gRPC: Protobufによる契約、双方向ストリーミング、効率的なバイナリ転送。低レイテンシの内部サービス間呼び出しに非常に適しています。トレードオフ: ブラウザサポートにはgRPC-Webが必要で、パブリッククライアントに対する可観測性や互換性の確保がより困難になる場合があります。
GraphQL: 複合ビューのためのラウンドトリップを削減する柔軟なクエリ。トレードオフ: 複雑なリゾルバ、N+1問題のリスク、キャッシングの課題、そしてアクセス制御の微妙なニュアンス。

バージョニングとページネーション:

追加的で後方互換性のある変更を推奨します。URIベースのメジャーバージョン（例: /v1）を使用し、マイナーな改訂はフィールドや機能フラグを介して行います。明確なタイムラインをもって非推奨とします。
頻繁な更新下でのページの不整合を避けるため、安定したカーソルまたはnextPageTokenでページ分割します。大規模なデータセットでのオフセットの使用は避けます。

バリデーションとエラー:

RESTのリクエスト/レスポンススキーマにはOpenAPIを、gRPCにはprotobufのバリデーションルールを使用します。
一貫したエラーモデルを採用します。標準的なHTTPステータスコードにマッピングし、gRPCではgoogle.rpc.Status（code, message, details）を使用します。機械が解析可能なエラー理由と相関IDを含めます。内部情報を漏洩させないようにします。

API管理の選択肢:

API Gateway: OpenAPI/gRPCバックエンド（Cloud Run, Cloud Functions, GKE, Compute Engine）向けの軽量なマネージドゲートウェイ。認証、APIキー、JWTバリデーション、クォータをサポートします。サーバーレスや単純なコントロールプレーンに適しています。
Cloud Endpoints (ESPv2): サービスと共にデプロイされます。OpenAPIまたはgRPCのトランスコーディング、認証、クォータ、メトリクスをサポートします。プロキシをワークロードと同じ場所に配置することが望ましい場合に適しています。
Apigee: 高度なポリシー（スパイクアレスト、クォータ、メディエーション、変換、OAuthプロバイダ、収益化、開発者ポータル）を備えたフルライフサイクルのAPI管理。複雑なパートナーエコシステムやノースサウス（外部-内部間）の制御に最適です。

認証とクォータ:

エンドユーザー向けにはOAuth 2.0またはFirebase Authenticationを、サービス向けにはGoogle署名付きIDトークン（OIDC）またはOAuthサービスアカウントトークン（2-legged）を使用します。
バックエンドを保護するために、クライアントに近い場所（Apigee）で、かつコンシューマーごと（APIキーまたはクライアント認証情報）にクォータとスパイクアレストを適用します。

Cloud RunバックエンドとOIDCを使用した、最小限のAPI Gateway OpenAPIの例:

openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
  /v1/orders:
    get:
      security: [{firebase: []}]
      x-google-backend: {address: https://orders-xyz-uc.a.run.app}
      responses: {"200": {description: OK}}
components:
  securitySchemes:
    firebase:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-issuer: https://securetoken.google.com/PROJECT_ID
      x-google-audiences: PROJECT_ID

非同期メッセージングとイベント処理

Pub/Subの基礎:

トピックとサブスクリプションがパブリッシャーとコンシューマーを分離します。配信はat-least-once（少なくとも1回）であり、重複や順序の入れ替わりが発生する可能性があります。
確認応答（ack）を使用し、処理が長い場合はackの期限を延長します。クライアントのフロー制御を適用して、メモリの圧迫を避けます。
順序付け: メッセージの順序付けを有効にし、順序付けキーを提供することで、キーごとの順序通りの配信を保証します。可能な限り、キーごとにアクティブなパブリッシャーを1つに保ちます。
デッドレター: 処理不可能なメッセージ（poison message）を格納し、無限リトライを防ぐためにデッドレタートピックを設定します。監視し、トリアージします。

トピック、サブスクリプション、DLQの作成:

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
  --topic=orders \
  --dead-letter-topic=orders-dlq \
  --max-delivery-attempts=5 \
  --ack-deadline=30

コンシューマー側の考慮事項: べき等なハンドラと重複排除（例: messageIdやアプリケーションレベルのべき等キーによる）を実装します。一時的なエラーはバックオフ付きでリトライし、回復不可能なメッセージはDLQに移動してアラートを送信します。

EventarcとCloudEvents:

Eventarcは、Google Cloudサービス、カスタムソース、監査ログからのイベントをCloud Run、Cloud Functions、またはGKEにルーティングします。イベントはCloudEventsエンベロープ（id, source, type, subject, time）を使用します。
ノイズとコストを削減するために、トリガーで属性（type, subject, location）によってフィルタリングします。最小権限のために専用のサービスアカウントを使用します。

Cloud Storageオブジェクトのファイナライズに対するEventarcトリガーの作成:

gcloud eventarc triggers create index-new-objects \
  --destination-run-service=media-indexer \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-assets-bucket" \
  --service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com

トレードオフ:

Pub/Subはプル型に最適化されており、高スループットに対して回復力があります。Eventarcは、自身で制御できないプロデューサーからのルーティングを簡素化し、標準化されたメタデータと共にサービスへプッシュします。
厳密な順序付けや厳格なコスト上限が必要な場合は、パブリッシャー側でのパーティショニングやレート制限を検討します。非常に低レイテンシのファンアウトには、サブスクライバーの同時実行数を慎重に調整します。

オーケストレーション、バックグラウンドワーク、長時間実行プロセス

Cloud Tasks:

信頼性の高いバックグラウンドHTTP呼び出しのためのプッシュキュー。バックエンドを保護するために、キューごとにディスパッチレートと同時実行数を設定します。指数バックオフと最大試行回数でリトライを設定します。
決定論的なタスク名またはIdempotency-Keyヘッダーでべき等性を確保し、サーバー側で重複排除します。迅速に応答（2xx）し、重い処理は必要に応じて非同期で実行します。

レート制限とリトライを設定したキューの作成:

gcloud tasks queues create payments-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=200 \
  --max-attempts=10 \
  --min-backoff=5s \
  --max-backoff=300s

Workflows:

HTTPおよびGoogle Cloudコネクタを横断する複数ステップのビジネスプロセスをオーケストレーションします。部分的な障害に対しては、補償アクション（Sagaパターン）をモデル化します。分散トランザクションは避けます。
ステップレベルのタイムアウトとリトライポリシーを使用します。リトライをまたいで状態を永続化させることで、障害からの再開を可能にします。長時間実行されるオペレーションをポーリングし、期限切れでキャンセルします。

補償処理のスケッチ:

main:
  params: [orderId]
  steps:
  - charge:
      call: http.post
      args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      result: chargeRes
  - reserveInventory:
      try:
        steps:
        - reserve:
            call: http.post
            args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      except:
        as: e
        steps:
        - refund:
            call: http.post
            args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
        - raise: ${e}

運用上のガイダンス:

1つのサービスへの正確なレート制御を伴う「撃ちっぱなし」のバックグラウンドHTTPにはCloud Tasksが適しています。ファンアウトや複数のコンシューマーにはPub/Subを使用します。分岐ロジックや補償処理を伴う複数の呼び出しを調整する必要がある場合はWorkflowsを使用します。

アイデンティティ、信頼性、および統合

サービス間のアイデンティティとトークン伝播：

Cloud Run/Functions/Compute Engine/GKEのワークロードは、最小権限のサービスアカウントを使用する必要があります。GKEでは、ノードレベルの認証情報を避けるためにWorkload Identityを使用します。
Cloud RunからCloud Runを呼び出すには、オーディエンスがターゲットURLと一致するIDトークンを使用します。ダウンストリームが呼び出し元の代わりに動作する必要がある場合にのみアイデンティティを伝播させ、それ以外の場合は呼び出し先のサービスアカウントを使用します。

Cloud RunでIDトークンを取得する：

AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"

同期的な依存関係と回復性：

クライアントのタイムアウトをアップストリームのタイムアウトより低く設定し、ホップごとに予算を割り当てます。べき等な操作のみ、切り捨て指数バックオフとジッターを用いてリトライします。リトライの合計時間を制限することで、リトライストームを回避します。
アップストリームが不健康な場合は、サーキットブレーカーを使用してフェイルファストします。GKE/Apigee/Envoyでは、最大保留リクエスト数、障害時の切り離し、ヘルスプローブを設定できます。適切なフォールバックを提供するか、グレースフルにデグレードします。
一時的なエラー（429、408、500–503）をリトライ可能な動作にマッピングし、4xx（408/429を除く）はリトライ不可として扱います。

Webhookとサードパーティ統合：

共有シークレットまたは署名付きJWTを使用したHMAC署名ヘッダーでインバウンドリクエストを検証します。より高い保証が必要な場合は、mTLSを使用します。シークレットはSecret Managerに保存し、定期的にローテーションします。
迅速に応答を返し、Cloud Tasksにエンキューするか、Pub/Subにパブリッシュして重い処理を分離します。バックエンドを保護するために、インバウンドのIPやキーをレート制限します。
アウトバウンドのWebhookでは、安全なリトライを可能にするためにIdempotency-Keyを含め、リモートのTLS証明書とホスト名を検証します。

スキーマの進化と互換性：

REST/JSON：フィールドの追加は安全です。既存のフィールドを再利用したり、型や意味を変更したりしないでください。非推奨のフィールドにはマークを付け、一定期間は提供を続けます。
Protobuf/gRPC：フィールド番号を再利用せず、予約済みタグを使用します。オプショナルフィールドを優先します。デフォルト値と存在セマンティクスは互換性にとって重要です。
イベント：dataVersionを含め、CloudEventsの属性を安定させます。拡張用の余地を確保します。Pub/Subでは、Pub/Sub Schema（Avro/Protobuf）を使用してパブリッシュ時に検証することを検討します。
テスト：コンシューマー駆動契約テスト、エミュレータ（Pub/Sub、Datastore/Firestore）または隔離されたプロジェクト、カナリアリリースを使用します。CIで一時的な環境と現実的な割り当てを使用して統合テストを実行し、潜在的な障害を明らかにします。

スタック全体でのセキュリティと割り当て：

エッジ（API Gateway/Apigee/Endpoints）とサービスの両方で認証を強制します。コンシューマーごとの割り当てとスパイク防止を適用します。401/403の急増と429のレートを監視して、クライアントのバックオフと割り当てを調整します。
コンポーネント間でリクエストIDをログに記録し、トレースヘッダー（TraceparentまたはX-Cloud-Trace-Context）を伝播させて、エンドツーエンドの可観測性を実現します。

実践的な問題シナリオ

AcmeRetailは、Google Cloud上でクリック＆コレクトサービスを構築しています。ReactのWebアプリが公開APIを呼び出して注文を行い、バックエンドサービスは在庫の確保、支払い処理、店舗への通知を行う必要があります。チームは、低レイテンシーAPI、信頼性の高いバックグラウンド処理、イベント駆動の更新、部分的な障害発生時の安全なロールバックを必要としています。

アプローチ：

Cloud Runの注文サービスの前にAPI Gatewayを配置し、公開REST APIを公開します。

根拠：RESTとJSONはブラウザにとってシンプルです。API GatewayはFirebase AuthからのJWTを検証し、クライアントごとのAPIキーと割り当てを強制し、エッジで終端します。Cloud Runはトラフィックの急増に応じて自動スケールします。

内部のホットパス（注文から在庫、価格設定）には、gRPCを使用してサービス間呼び出しを実装します。

根拠：gRPCはシリアライゼーションのオーバーヘッドを削減し、厳密な契約を提供します。Workload Identity（GKE）またはサービスアカウント（Cloud Run）と、サービス間のOIDCを使用します。タイムアウトは300msに設定し、べき等な読み取りには2回のリトライとジッターを適用します。

Workflowsを使用して注文のサーガ（支払い処理、在庫確保、集荷タスク作成）をオーケストレーションし、障害時には補償処理を行います。

根拠：中央集権的なオーケストレーションにより、長時間実行されるステップと補償処理を管理します。在庫確保に失敗した場合、Workflowsは返金処理をトリガーし、クライアントに409を返します。

ドメインイベントをPub/Subのトピックordersとinventoryにパブリッシュし、ダウンストリームのコンシューマー（分析、店舗通知）に提供します。

根拠：密結合なしでのファンアウト。サブスクライバーはorderIdをキーとするべき等性を実装します。サブスクリプションにはmax-delivery-attempts=10のデッドレタートピックがあり、DLQの増加に対してアラートが発火します。

関連するCloud StorageとFirestoreの変更に応じて、Eventarcを介してCloud Runの通知サービスへのトリガーを設定し、店舗への通知を行います。

根拠：Eventarcは属性フィルターを使用して必要なイベントのみをルーティングします。CloudEventsは一貫したメタデータを保証します。通知サービスは、レートとリトライを制御するためにCloud Tasksを使用して、サードパーティのSMS/Emailプロバイダーに投稿します。

支払いプロバイダーからのWebhookを、API Gatewayの前面にある専用のCloud Runエンドポイントで処理し、HMAC署名を検証し、処理にはCloud Tasksを使用します。

根拠：迅速な200 OK応答はプロバイダーのリトライを減らします。Tasksはバックオフ付きのリトライを保証します。シークレットはSecret Managerに保存され、リクエストボディはOpenAPIスキーマに対して検証されます。

信頼性パターンを強制します：支払いプロバイダーへのアウトバウンド呼び出しにはApigeeまたはEnvoyでサーキットブレーカーを導入し、クライアントのタイムアウトはプロバイダーのSLAより低く設定し、429/5xxエラーには切り捨て指数バックオフ付きのリトライを適用します。

根拠：連鎖的な障害やリトライストームを防ぎ、サードパーティの制限を尊重し、一時的な過負荷をグレースフルなデグレードに転換します。

スキーマの進化に関する管理策を採用します：内部gRPCには予約済みフィールドを持つProtobufを使用し、RESTレスポンスは追加的なJSONの変更を使用し、Pub/Subはパブリッシュ時にProtobufスキーマ検証を使用します。

根拠：コンシューマーの互換性を維持します。契約テストと統合テストはマージごとにCloud Buildで実行され、カナリアデプロイは実際のトラフィックを安全に検証します。

観測と運用：API Gatewayとサービス間でトレースヘッダーを伝播させ、エラー率とDLQサイズのためにCloud Loggingメトリクスをエクスポートし、SLOバーンと429/5xxの異常に対してアラートを設定します。

根拠：リグレッション、割り当ての問題、またはプロバイダーのインシデントを迅速に検出し、SREは割り当てとバックオフポリシーを迅速に調整できます。

← コンピューティング、コンテナ、サーバーレスランタイムプラットフォーム · すべてのドメイン · アプリケーションデータ、状態、ストレージパターン →

これらの問題を練習する → · 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を閲覧 →