Pub/Sub + Dataflow

解決する課題

• 大量データをリアルタイムに取り込み、プロデューサとコンシューマを疎結合にしたい
• ストリーム（無制限データ）とバッチ（有制限データ）を同じコードで処理したい
• 流量の変動に合わせてワーカーを自動でスケールさせ、サーバー管理から解放されたい
• 集計結果を BigQuery / Cloud Storage / Bigtable へ自動ロードしたい

主要概念と用語

• Pub/Sub トピック / サブスクリプション: パブリッシャがメッセージを送る宛先がトピック、コンシューマが受け取る口がサブスクリプション。1 トピックに複数サブスクリプションを付ければファンアウトでき、各コンシューマが独立に受信する
• Pull / Push サブスクリプション: コンシューマ側が取りに行く Pull と、Pub/Sub が HTTPS で押し込む Push。低レイテンシ・大量処理は通常 Pull（StreamingPull）
• Apache Beam: Dataflow が実行する統合プログラミングモデル。PCollection（データ集合）に PTransform（変換）を適用してパイプラインを記述する。同じコードがバッチでもストリーミングでも動く
• ランナー (Runner): Beam パイプラインの実行基盤。Dataflow ランナーを使うと GCP のマネージド環境で実行される（他に Flink / Spark ランナーもある）
• ウィンドウ / ウォーターマーク / トリガー: ストリームを時間で区切るウィンドウ（固定・スライディング・セッション）、データの進捗を表すウォーターマーク、結果を出すタイミングを決めるトリガー。遅延データの扱いを制御する
• イベント時刻 (event time) と処理時刻 (processing time): データが発生した時刻と、Dataflow が処理した時刻。正確な集計はイベント時刻を基準にする

仕様・制限・クォータ

• Pub/Sub はサーバーレスでシャード管理が不要。スループットは自動拡張し、メッセージは最大 10 MB。未確認(ack)メッセージの保持は既定 7 日（最大 7 日、トピック保持は最大 31 日）
• Pub/Sub は At-least-once（最低 1 回）配信が既定。順序は順序指定キーを付けた場合のみ保証される。リージョン内でExactly-once 配信を有効化することも可能
• Dataflow はジョブ単位で動き、ワーカー（Compute Engine VM）を水平オートスケール。Streaming Engine / Dataflow Prime を使うとシャッフルや状態をサービス側にオフロードできる
• バッチは有制限データ、ストリーミングは無制限データを処理。Flexible Resource Scheduling (FlexRS) でバッチをスポット VM 中心に安く実行できる

内部の仕組み

Pub/Sub はグローバルなメッセージバスで、パブリッシュされたメッセージをサブスクリプションごとに独立したキューとして保持します。コンシューマが ack するまで再配信されるため、処理が失敗しても消えません。シャード（パーティション）という概念がなく、流量に応じて内部で自動的にスケールします。

Dataflow は Beam パイプラインを受け取り、各 PTransform をワーカー VM 群に分散実行します。ストリーミングではウォーターマークでデータの進捗を追跡し、ウィンドウごとに集計を確定。Streaming Engine は状態管理とシャッフルをワーカーから切り離し、オートスケールとリソース効率を高めます。

設計パターン / ベストプラクティス

• 取り込み = Pub/Sub、処理 = Dataflow、保存先 = BigQuery / GCS / Bigtable の三段構成が王道
• 単純な「ストリームを BigQuery へ流すだけ」なら、自前パイプラインを書かず Dataflow テンプレート（Pub/Sub Subscription to BigQuery など）や Pub/Sub の BigQuery サブスクリプションを使うと最小運用
• 集計はイベント時刻ベースのウィンドウで行い、遅延データは許容遅延 (allowed lateness) とトリガーで制御
• 重複に備え、ダウンストリームを冪等に設計する（At-least-once が既定のため）。厳密性が必要なら Exactly-once 配信や Dataflow の重複排除を併用
• 失敗メッセージはデッドレタートピック (dead-letter topic) へ退避し、本流を止めない

運用・監視

• Cloud Monitoring でメトリクスを監視。Pub/Sub は subscription/num_undelivered_messages（未処理バックログ）と subscription/oldest_unacked_message_age（最古の未 ack 経過時間 = 遅延の指標）が重要
• Dataflow は システムラグ (System Lag) と データ鮮度 (Data Freshness) でストリーミングの遅延を検知。バックログが増え続けるならワーカー不足やホットキーを疑う
• Dataflow ジョブグラフ / 実行詳細 で各ステージのスループットとボトルネックを可視化
• バックログ増大時はオートスケールの上限（maxNumWorkers）やキー分散を見直す

コスト

セキュリティ

• サービスアカウントで Pub/Sub・Dataflow の権限を付与し、認証情報のハードコードを避ける（AWS の IAM ロール相当）。Dataflow ワーカーには専用のワーカーサービスアカウントを割り当てる
• IAM でパブリッシャ / サブスクライバ / ジョブ実行を最小権限に分離。roles/pubsub.publisher と roles/pubsub.subscriber を分ける
• 保存データは Google 管理鍵で既定暗号化。要件に応じ CMEK（顧客管理鍵, Cloud KMS） を Pub/Sub トピックや Dataflow に適用。外部流出対策に VPC Service Controls を併用

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 1) Pub/Sub のトピックとサブスクリプションを作成
gcloud pubsub topics create events

gcloud pubsub subscriptions create events-sub \
  --topic=events \
  --ack-deadline=30

# 2) メッセージをパブリッシュ / 取得して確認
gcloud pubsub topics publish events \
  --message='{"click":1}' \
  --attribute=user=user-123

gcloud pubsub subscriptions pull events-sub --auto-ack --limit=1

# 3) Google 提供テンプレートで Pub/Sub → BigQuery のストリーミングジョブを起動
gcloud dataflow jobs run ps-to-bq \
  --gcs-location=gs://dataflow-templates/latest/PubSub_Subscription_to_BigQuery \
  --region=asia-northeast1 \
  --parameters=inputSubscription=projects/MY_PROJECT/subscriptions/events-sub,outputTableSpec=MY_PROJECT:demo.events

# 4) 実行中の Dataflow ジョブを一覧
gcloud dataflow jobs list --region=asia-northeast1 --status=active