Google PDE: メッセージング、イベントの取り込み、リアルタイムサービス — 学習ガイド

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

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

概要

Google Cloudにおけるメッセージング、イベント取り込み、リアルタイムサービスは、疎結合で耐久性のあるトランスポートのためのCloud Pub/SubとEventarc、ステートフルなストリーム処理のためのDataflow、そしてシンクとしてのBigQuery、Cloud Storage、運用データベースを中心に構成されます。at-least-once（少なくとも1回）配信、べき等な消費、オブザーバビリティを考慮して設計することで、障害、バックプレッシャー、スキーマの進化といった状況下でも正確性を維持しながら、弾力的にスケールする回復力のあるシステムを保証します。

Pub/Subによるコアメッセージング

• トピックとサブスクリプション
  • パブリッシャーはトピックにメッセージを送信し、サブスクライバーはサブスクリプションを介してアタッチします（複数のサブスクライバーが同じメッセージを独立して消費できます）。
  • サブスクリプションのタイプ:
    • Pull: クライアントが明示的にメッセージをプルします。最高のパフォーマンスと少ないラウンドトリップのためにはストリーミングプルを使用します。
    • Push: Pub/SubがHTTPS経由で配信します。エンドポイントは確認応答として2xxを返す必要があります。
    • BigQueryへのエクスポート: BigQueryサブスクリプションは、コードなしでメッセージをBigQueryテーブルに配信します。ペイロードが宣言されたスキーマと一致し、分析基盤への低レイテンシでの取り込みが必要な場合に最適です。
• 順序付けキー
  • トピックとサブスクリプションでメッセージの順序付けを有効にすると、順序付けキーごとに順序通りに配信されます。キーごとのスループットはシリアル化されます。キーごとに1つの処理中メッセージが後続のメッセージをブロックする可能性があるため、スケールさせるには多数のキー（例: hash(device_id)）を使用します。
• ファンアウトとリプレイ
  • 異なるコンシューマー用に個別のサブスクリプションを作成し、ワークロードと保持期間を分離します。
  • 復旧やバックフィルのために、タイムスタンプまたはスナップショットからリプレイするには、seekまたはsnapshotを使用します。

トレードオフ:

• 順序付けは、キーごとの並列処理とスループットを低下させます。厳密に必要でない限り、順序付けは無効にしてください。
• Pushはクライアントコードを簡素化しますが、HTTPエンドポイントのスケーリング、セキュリティ、バックオフに関する懸念が生じます。Pullは高スループット時に、より多くの制御と安定性を提供します。

配信セマンティクス、確認応答、保持、デッドレタリング

• 確認応答と期限
  • At-least-once（少なくとも1回）配信: 重複が発生する可能性があります。
  • 各配信にはack（確認応答）期限（デフォルト10秒）があります。長時間実行される処理中は、期限を延長（ModifyAckDeadline）します。期限内にackを返さないことが、push配信で重複が発生する最も一般的な原因です。
  • Nack（否定応答）または期限切れにより、メッセージは再配信の対象となります。
• 保持
  • 未確認のメッセージはサブスクリプションのack期限まで保持され、再試行されます。確認済みのメッセージは、リプレイのためにトピックのメッセージ保持期間まで保持できます。最大の停止時間と復旧時間をカバーするように保持期間を設定します。
• 再試行
  • Pull: ack期限が切れた後に再配信が行われます。フロー制御の制限で同時実行性を制御します。
  • Push: 指数関数的バックオフ。HTTP 2xxのみが成功と見なされます。3xx/4xx/5xxは再試行をトリガーします。繰り返しを許容するために、べき等なハンドラを実装します。
• デッドレタートピック（DLT）
  • ポイズンメッセージを隔離するために、サブスクリプションごとにDLトピックと最大配信試行回数を設定します。
  • DLQの量を監視し、トリアージワークフローを作成し、修正後にメインのトピックに再パブリッシュします。

例:

undefined

配信セマンティクスの概要:

• Pub/Sub: at-least-once（少なくとも1回）配信。順序付けキーが有効な場合、キー内でのベストエフォートでの順序付け。
• シンク: BigQueryのinsert APIは重複排除機能（insertIdまたはStorage Write APIのストリームオフセット）を提供しますが、それでもコンシューマーとライターはべき等になるように設計する必要があります。

スキーマ、互換性、検証

• Pub/Subスキーマ
  • スキーマを中央で保存するAvroおよびProtocol Buffersをネイティブでサポート。
  • トピックレベルのスキーマ設定: エンコーディング（AvroまたはProtobuf）と適用（なし、検証のみ、または必須）。
  • プロデューサーはエンコードされたペイロードをパブリッシュします。適用が有効な場合、Pub/Subは現在のスキーマに対して検証します。
• 進化と互換性
  • 後方互換性のある変更を使用します（オプショナルなフィールドの追加、Avroでのデフォルト値を持つフィールドの追加、Protobufでのタグの再利用の禁止、フィールドの削除や名前変更の回避）。
  • スキーマを明示的にバージョン管理します。互換性のない変更の場合は、v1とv2のトピックにデュアルパブリッシュするか、バージョンフィールドを追加してそれに応じてルーティングします。
• プロデューサーとコンシューマーの契約
  • コンシューマーは未知のフィールドを無視し、欠落しているフィールドにはデフォルト値を使用すべきです。
  • 本番環境へのプロモーション前に、すべてのコンシューマーでスキーマの互換性をテストします。本番環境と同じスキーマ適用設定を持つステージングサブスクリプションで検証します。

短いAvroの例（抜粋）:

undefined

イベント駆動型インテグレーション、Eventarc、およびKafkaの相互運用性

• EventarcとCloudEvents
  • Eventarcは、CloudEvents仕様を使用して、Google Cloudサービス（およびPub/Sub経由のカスタムソース）からのイベントをCloud Run、GKE、またはWorkflowsにルーティングします。type、source、subjectなどの属性により、きめ細かなフィルタリングと監査性が可能になります。
  • 属性フィルタを使用してファンアウトを最小限に抑え、ダウンストリームの負荷を軽減します。
  • 配信はat-least-once（少なくとも1回）です。可能な限り、ハンドラをべき等かつステートレスにします。
• Eventarcトリガーの例: gcloud eventarc triggers create gcs-finalize-to-run
  –destination-run-service=ingestor
  –event-filters=“type=google.cloud.storage.object.v1.finalized”
  –event-filters=“bucket=my-data-bucket”
  –service-account=eventarc-sa@PROJECT_ID.iam.gserviceaccount.com
• Kafkaの相互運用性とマネージドマイグレーション
  • Dataflowテンプレートは、段階的な移行のためにKafkaとPub/Subを接続します。キーを保持したままトピックをミラーリングします。最初にコンシューマを切り替え、次にプロデューサーを切り替えるか、移行中にデュアルライト（二重書き込み）を行います。
  • Pub/Sub Liteは、キーベースのルーティングと低コストを備えた、パーティション分割された容量プロビジョニング型のストリーミングを提供します。リージョン/ゾーン単位であり、予測可能な容量とパーティションごとの順序性が主な関心事であるKafkaのようなワークロードに適しています。
  • 移行に関する考慮事項:
    • 順序性: KafkaのキーをPub/Subの順序付けキーまたはLiteのパーティションにマッピングします。
    • オフセット: 診断のためにオフセットをメッセージ属性として保持します。移行後、コンシューマはKafkaのオフセットに依存できません。
    • 配信: at-least-once（少なくとも1回）の配信を受け入れ、ダウンストリームでべき等性を強制します。
    • スキーマ: Confluent Schema Registryの定義をPub/Subスキーマに移行するか、互換性のある進化ルールを持つProtobuf/Avroで標準化します。

ストリーミング取り込みパターン、スループット、スケーリング、セキュリティ、および運用

• リアルタイム取り込みパターン
  • Pub/Sub -> Dataflow -> BigQuery: 高スループットとストリームオフセットによるべき等性を実現するために、BigQuery Storage Write API シンクを使用します。失敗したデータは調査のためにデッドレターテーブルにルーティングします。
  • Pub/Sub -> Dataflow -> Cloud Storage: 再処理のために生のイベントをアーカイブします。コストとレイテンシのバランスを取るために、ウィンドウ化および圧縮された書き込みを使用します。
  • Pub/Sub -> オペレーショナルストア: 低レイテンシのルックアップには Bigtable、強整合性のトランザクションには Spanner、またはワークロードのニーズに応じて Cloud SQL/Firestore に書き込みます。一意のイベント ID をキーとするべき等なアップサートを保証します。
• at-least-once (少なくとも1回)、重複防止、およびべき等性
  • すべてのメッセージに一意の event_id と event_time を含めます。プロデューサー側で UUID を強制します。
  • BigQuery ストリーミングの重複排除: insertId を設定するか、順序付きストリームで Storage Write API を使用します。それでもクエリは重複排除ロジックで保護します。
  • クエリ時の重複排除の例: WITH ranked AS ( SELECT t.*, ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time DESC) AS rn FROM dataset.events t ) SELECT * EXCEPT(rn) FROM ranked WHERE rn = 1;
  • プッシュエンドポイントの場合、処理が成功した後にのみ 2xx を返します。それ以外の場合は再配信を想定します。
• メッセージのスループット、割り当て、およびスケーリング
  • パブリッシャー: メッセージをバッチ処理し、接続を再利用します。複数のクライアントで並列化します。順序付きワークロードをスケーリングするには、多数の ordering key を使用します。
  • サブスクライバー: フロー制御付きのストリーミング pull (未処理の最大バイト数/メッセージ数) を優先します。確認応答の期限 (ack deadline) を処理時間に合わせて設定し、必要に応じて延長します。
  • データ量の増加に伴い、パブリッシュおよびサブスクライブのスループットの割り当て増加を監視し、リクエストします。バーストを吸収するために、ヘッドルーム (例: 予想されるピークの2倍) を設けて設計します。
• 整合性と可用性
  • BigQuery ストリーミングは、クエリの可視性に関して結果整合性です。ストリーミングされた行を含める必要があるインタラクティブなクエリの場合、観測されたレイテンシ (例: P50 可用性遅延の2倍) に基づいて待機するか、Dataflow でウォーターマークに合わせた集計を使用して設計し、マテリアライズされた結果をクエリします。
• セキュリティ
  • IAM: 最小権限のロール (トピックのプロデューサーには pubsub.publisher、サブスクリプションのコンシューマーには pubsub.subscriber) を付与します。各ワークロードに専用のサービスアカウントを使用します。
  • プッシュ認証: プッシュサブスクリプションがサービスアカウントから OIDC トークンを添付するように構成します。エンドポイントで audience の検証を強制します。組み込みの認証と TLS のために、Cloud Run のプライベートエンドポイントを優先します。
  • 暗号化: Pub/Sub は転送中および保存中のデータを暗号化します。顧客管理のキーには、トピックで CMEK を使用します。データ漏洩リスクを低減するために VPC Service Controls を適用します。必要に応じて、機密性の高いペイロードフィールドにはクライアントサイド暗号化を使用します。
• ラグ、再配信、およびサブスクライバー障害の運用診断
  • Cloud Monitoring で監視:
    • バックログには subscription/num_undelivered_messages と oldest_unacked_message_age。
    • 確認応答の失敗による重複を検出するには expired_ack_deadline_count。
    • スループットには publish_request_count と pull_request_count。
  • ダッシュボードに表示されないイベントを調査するには、既知のデータセットをパイプラインで再生し、ステージごとの出力を比較して、障害のある変換またはシンクを特定します。
  • Dataflow ストリーミングの場合:
    • 多くのソースからの負荷を吸収するために、適切な maxWorkers を設定した自動スケーリングを使用します。
    • 互換性のない更新を行う場合は、パイプラインをドレインして、処理中の作業を完了させ、データ損失を防ぎます。
  • BigQuery の挿入通知については、Cloud Logging の監査エントリを、特定のテーブルにフィルタリングされたシンクを介して、アラート用の Pub/Sub トピックにルーティングします。

実践的な問題シナリオ

Contoso Freight 社は、トラックから毎分10,000件の IoT テレメトリメッセージを取り込み、イベントをエンリッチし、インタラクティブな分析を可能にし、外部パートナーからのファイルドロップをトリガーとするワークフローを起動するための、グローバルなリアルタイムイベントプラットフォームを必要としています。一部のパートナーの CSV には不正な形式の行が含まれており、分析チームはストリームをブロックすることなくエラーを調査する必要があります。

1. コアメッセージングとスキーマレイヤーの作成

• アクション: テレメトリ用の Avro スキーマを定義し、それを Pub/Sub トピック telemetry にアタッチして、スキーマ適用を必須に設定します。メッセージの順序付けを有効にし、ordering_key = hash(device_id) でパブリッシュします。
• 理由: トピックレベルのスキーマ適用により、不正な形式のイベントを早期に拒否します。デバイスごとの順序付けは、必要な場合に順序付き処理をサポートし、ハッシュ化によってキーが分散されるためスループットが維持されます。

2. 分離とデッドレタリングを備えたサブスクリプションのプロビジョニング

• アクション: Dataflow 用に pull サブスクリプション telemetry-stream-sub を作成し、デッドレタートピック telemetry-dlt と max_delivery_attempts=10 を設定します。リネージとリプレイのために、生のイベントを時間パーティション分割テーブルに取り込む BigQuery サブスクリプション telemetry-raw-bq を追加します。
• 理由: DLQ は、調査のためにポイズンメッセージを分離します。別の BigQuery サブスクリプションは、処理パイプラインとは独立して、生のイベントを保存するための運用負荷の低いエクスポートパスを提供します。

3. エンリッチメントとシンクのための Dataflow ストリーミングパイプラインの構築

• アクション: フロー制御付きのストリーミング pull を使用して telemetry-stream-sub から取り込みます。スキーマに対して検証し、参照データでエンリッチし、ウィンドウ化された集計を計算します。名前付きストリームと insertId = event_id を使用して Storage Write API で BigQuery に書き込みます。生のバックアップを1時間ごとに Cloud Storage に書き込みます。不正/失敗したレコードはデッドレターの BigQuery テーブルにリダイレクトします。
• 理由: Storage Write API は、insertId/ストリームオフセットによるべき等性を備えた、高スループット、低レイテンシの書き込みを実現します。デッドレターテーブルはストリームをブロックせずに調査をサポートし、Cloud Storage アーカイブはリプレイを可能にします。

4. 分析における重複と結果整合性の処理

• アクション: 重複を除外する必要があるインタラクティブなクエリのために、すべてのレコードに event_id と event_time をパブリッシュし、重複排除ビューを使用します: CREATE OR REPLACE VIEW analytics.latest_events AS SELECT * EXCEPT(rn) FROM ( SELECT e.*, ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time DESC) rn FROM analytics.events e ) WHERE rn = 1; 観測された BigQuery ストリーミングの可用性 (例: レイテンシの中央値の2倍) に基づいて、クエリに短い遅延を導入します。
• 理由: at-least-once 配信には、べき等な書き込みとクエリ時の重複排除が必要です。待機することで、ストリーミングの可視性レイテンシを考慮して、処理中の行の見逃しを減らします。

5. Eventarc を使用したパートナーのファイルドロップの統合

• アクション: バケット partner-drops の Cloud Storage object.finalized イベントを Cloud Run サービスにルーティングするように Eventarc を構成します。このサービスは、CSV を BigQuery にロードするためのバッチ Dataflow ジョブを起動し、解析エラーをデッドレターテーブルに送信します。
• 理由: Eventarc は、バケットとオブジェクトプレフィックスでのフィルタリングを備えた、CloudEvents によるイベント駆動型のオーケストレーションを提供します。バッチ Dataflow ジョブは、正常なデータを迅速にロードしながら、不正な形式の行を分析のために分離します。

6. プラットフォームの保護

• アクション: 個別のサービスアカウントを使用します: プロデューサーは telemetry トピックに対する pubsub.publisher 権限を取得します。Dataflow ワーカー SA は telemetry-stream-sub に対する pubsub.subscriber 権限と、ターゲットの BigQuery データセットおよび Cloud Storage への書き込みアクセス権を取得します。Eventarc トリガーは、Cloud Run に対する invoker 権限を持つ専用の SA を使用します。telemetry トピックと BigQuery データセットで CMEK を有効にします。プッシュエンドポイントがある場合は、OIDC と audience チェックで構成します。
• 理由: 最小権限の IAM と CMEK は、セキュリティとコンプライアンスの要件を満たします。認証された配信は、なりすましを防ぎます。

7. 信頼性の高い運用とスケーリング

• アクション: ピークを吸収するために、十分な maxWorkers を設定して Dataflow の自動スケーリングを設定します。subscription/oldest_unacked_message_age と expired_ack_deadline_count を監視し、しきい値を超えた場合にアラートを発します。互換性を損なうパイプラインの変更については、メッセージの損失を避けるためにドレインしてデプロイします。ラグが増加した場合は、サブスクライバーの並列処理を増やし、処理時間に比例して ack deadline を延長します。
• 理由: プロアクティブな監視により、ラグと再配信を早期に検出します。自動スケーリングと調整された ack deadline は、重複の嵐を防ぎます。ドレインは、アップグレード中に処理中のメッセージを保護します。

この設計は、イベント駆動型のバッチ統合を備えた、回復力があり、安全で、観測可能なリアルタイム取り込みを実現し、重複の許容とスキーマの進化をサポートし、不正なデータを分離して対象を絞った修正を行いながら、高速な分析を提供します。

← Dataflow と Apache Beam によるストリーム処理 · すべてのドメイン · Spark、Dataproc、分散データ処理 →

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

Googleを閲覧 →