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。サブスクリプションのメッセージ保持は既定 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 deadline）までに応答できなければ再配信されるため、処理側は重複を前提にします。シャード（パーティション）という概念がなく、流量に応じて内部で自動的にスケールします。

Dataflow は Beam パイプラインを受け取り、各 PTransform をワーカー VM 群に分散実行します。Pub/Sub 入力では最初の結合済み処理段と副作用を永続化した後に確認応答を返し、失敗時は Pub/Sub の再配信を利用します。ストリーミングではウォーターマークでデータの進捗を追跡し、ウィンドウとトリガーで出力時点を決定。Streaming Engine は状態管理とシャッフルをワーカーから切り離し、オートスケールとリソース効率を高めます。

横にスクロール

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

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

運用・監視

• Cloud Monitoring でメトリクスを監視。Pub/Sub は subscription/num_undelivered_messages（未処理バックログ）と subscription/oldest_unacked_message_age（最古の未確認応答メッセージの経過時間 = 遅延の指標）が重要
• 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