Pub/Sub

Pub/Sub（Publish/Subscribe）は、Google Cloud のイベント駆動設計を支えるメッセージング基盤です。

AWSで相当するのは、SNS + SQSの組み合わせになります。

1. Pub/Subの思想：なぜ存在するのか？

Pub/Subの設計思想を一言で言えば、

「サービス間の独立性を保ちながら、情報を柔軟に中継する」

です。

マイクロサービス時代において、以下のような課題が増えています：

サービス同士が密結合になって変更に弱い
同じ情報を複数の場所で処理したいが冗長な連携が必要
非同期処理が必要なのに、都度HTTP連携している

Pub/Subはこうした構造の“ねじれ”を解消します。

2. ユースケース：こんなときに使える

例1：GCSにファイルがアップロードされたときに処理を走らせる

構成：
[ Cloud Storage ] → [ Pub/Sub ] → [ Cloud Function / Cloud Run ]

内容：

バケットに画像がアップロードされる
Pub/Subが通知メッセージを発行
Cloud Functionがトリガされ、画像のリサイズやメタデータ抽出などを実行

例2：ユーザーのアクションをリアルタイム分析に回す

構成：
[ アプリ / API ] → [ Pub/Sub ] → [ Dataflow ] → [ BigQuery ]

内容：

アプリケーションがユーザーイベント（例：クリック）をPub/Sub経由で送信
DataflowがPub/Subのストリームを受信し、整形
BigQueryに蓄積されてリアルタイム分析が可能に

3.Pub/Subの基本構成要素

用語	役割
Publisher（パブリッシャー）	メッセージを発行するクライアントアプリやサービス
Topic	Publisher がメッセージを送信する宛先（論理的なメッセージキュー）
Subscriber（サブスクライバー）	メッセージを受け取るクライアントアプリやサービス
Subscription	Topic からメッセージを受信するための設定（Pull型やPush型など）

4.配信の保証とエラーハンドリング

Pub/Subは “少なくとも一度は届く（at-least-once delivery）” というポリシーです。

そのため：

重複処理に耐える設計が必要（冪等性が重要）

Dead-letterトピックの活用で、失敗メッセージを別途保存可能

5.PullとPush

5.1.Push サブスクリプション

仕組み：Pub/Sub がエンドポイント（HTTPS）に直接メッセージを POST する。

オフライン時の挙動：

エンドポイントがダウンしていると、Pub/Sub は一定間隔で再試行する（最大 7 日間保持）。
7日以内に復旧すれば再送されるが、それまでに ACK 相当のレスポンスを返さなければ期限切れで削除される。
エンドポイントが長時間オフラインだとメッセージが失われる可能性あり。

5.2.Pull サブスクリプション

仕組み：クライアントが Pub/Sub にポーリングしてメッセージを取得する。

オフライン時の挙動：

サブスクリプションのバックログとして最大 7 日間保持される。
クライアントはオンラインに戻ったときにまとめて pull できる。
オフライン期間中も Pub/Sub 側で保持されるので、push より安心。

6. 最小構成を実際に作ってみる

ここでは、手元で試せる最小構成の例を紹介します。

手順：シンプルなPub/Subパイプラインの構築

# 1. Topic作成
gcloud pubsub topics create my-topic

# 2. Subscription作成（Pull型）
gcloud pubsub subscriptions create my-sub --topic=my-topic

# 3. メッセージをPublish
gcloud pubsub topics publish my-topic --message="Hello, PubSub!"

# 4. メッセージをPullして読む
gcloud pubsub subscriptions pull my-sub --limit=1 --auto-ack

この例で確認できること：

Topicにメッセージを送り

Subscriptionがそれを受信・保持し

Pull型で読み出せる

7.ACK（Acknowledgement）

ACK（Acknowledgement）は Pub/Sub でメッセージを「確実に受信・処理した」と通知するための仕組みです。

Cloud Functions が Pub/Sub（pull型）でメッセージを受け取る場合、

メッセージ処理後に acknowledge を呼び出して ACK を送信する必要があります。
ACK を送る際には、受信時に一緒に渡される ACK ID を指定します。

8.処理レート

Pub/Sub の Pull subscriber では未ackのメッセージの総量が10MBを超えると、配信がブロックされ、これにより処理速度が落ちますが、エラーではないためログに出ません。

9.Max latency

Max latency は、受信したメッセージをバッファリングする最大時間を制御するパラメータです。この時間が経過すると、バッファが満たされていなくても処理が開始されます。

10.リクエストの再試行

10.1.指数バックオフ

指数バックオフを使用すると、再試行の間の遅延を徐々に長くすることができます。

10.2.Seek操作

Seek操作を使えば、スナップショット時点にサブスクリプションを「巻き戻す」ことができます。

11. 他サービスとの組み合わせ

組み合わせ	用途	補足
Cloud Functions	軽量処理・通知	Push型サブスクリプションで自動起動
Cloud Run	バッチ・API処理	任意のランタイムで処理可能
Dataflow	高速・大規模ストリーム処理	Pub/SubがDataflowの入力になる
BigQuery	ログ分析	Dataflow → BigQuery連携構成が鉄板
Workflows	複数サービスの連携制御	Pub/Subでイベント駆動化可能

12.異なるプロジェクト間での利用

異なるプロジェクト間で Pub/Sub を安全に利用する場合、VPC Service Controls を使ってセキュリティ境界（perimeter）を設定し、許可された環境からのみアクセスできるようにします。

13.Pub/Sub Lite

2026年3月18日に終了予定。

14.リンク

公式ドキュメント