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パイプラインの構築
# 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型で読み出せる
非常に単純ですが、ここに非同期設計のエッセンスが凝縮されています。
4. 他サービスとの組み合わせ：より実用的に
| 組み合わせ | 用途 | 補足 |
|---|---|---|
| Cloud Functions | 軽量処理・通知 | Push型サブスクリプションで自動起動 |
| Cloud Run | バッチ・API処理 | 任意のランタイムで処理可能 |
| Dataflow | 高速・大規模ストリーム処理 | Pub/SubがDataflowの入力になる |
| BigQuery | ログ分析 | Dataflow → BigQuery連携構成が鉄板 |
| Workflows | 複数サービスの連携制御 | Pub/Subでイベント駆動化可能 |
5. 配信の保証とエラーハンドリング
Pub/Subは “少なくとも一度は届く（at-least-once delivery）” というポリシーです。
そのため：
重複処理に耐える設計が必要（冪等性が重要）
Dead-letterトピックの活用で、失敗メッセージを別途保存可能