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）を設定し、許可された環境からのみアクセスできるようにします。