Pub/Sub

解決する課題

物理的なメッセージブローカーの構築・運用やスケール調整を待たずに、グローバルに分散したメッセージ配信をすぐ使えます。

• アクセス急増でバックエンドが詰まる → サブスクリプションがバッファして処理側のペースで捌く
• 送信側と処理側を 疎結合 にして独立にスケールしたい
• 1 件のイベントを 複数の処理系へ同報（ファンアウト） したい（在庫更新・通知・分析へ同時配信など）
• 失敗したメッセージを 安全に退避・再試行 したい（デッドレタートピック）
• リージョンをまたいでも 同一エンドポイント で発行・購読したい（グローバルサービス）

主要概念と用語

• トピック（Topic）: メッセージの発行先。AWS の SNS トピックに相当
• サブスクリプション（Subscription）: トピックに紐づくメッセージの受け取り口。1 トピックに複数のサブスクリプションを付けるとファンアウトになり、各サブスクリプションが独立したコピーを受け取る
• パブリッシャー / サブスクライバー: 発行側 / 購読側のクライアント
• Pull サブスクリプション: サブスクライバーが API でメッセージを取得し、ack（確認応答）で削除。AWS SQS のポーリングに近い
• Push サブスクリプション: Pub/Sub が HTTPS エンドポイント（Cloud Run / Cloud Functions / 任意の URL）へメッセージを POST する
• 確認応答（ack）と ackDeadline: 取得したメッセージを処理し終えたら ack。ackDeadline（既定 10 秒、最大 600 秒）までに ack しないと 再配信 される（SQS の可視性タイムアウト相当）
• メッセージ保持（retention）: ack 前のメッセージの保持期間。サブスクリプション既定 7 日（最大 7 日）。トピック側でも保持を有効化でき、シーク（Seek） で過去へ巻き戻して再処理できる
• 順序指定キー（ordering key）: 同一キーのメッセージを 発行順 に届ける（FIFO 的な順序保証）
• デッドレタートピック（Dead-letter topic）: 規定回数（maxDeliveryAttempts）失敗したメッセージの退避先トピック
• スキーマ（Schema）: Avro / Protocol Buffers でメッセージ構造を検証
• Pub/Sub Lite: 低コスト・ゾーン単位の派生サービス（スループットを事前プロビジョニング）。※2024 年に新規提供は終了予定がアナウンスされており、新規は通常の Pub/Sub を推奨

仕様・制限・クォータ

• 少なくとも 1 回（at-least-once）配信 が基本。まれに重複 するため処理は 冪等 に作る
• メッセージ本文は 最大 10 MB（SQS の 256KB より大きい）
• ack 前メッセージの保持は 最大 7 日（既定 7 日）。トピック保持を使えばシークで再処理可能
• ackDeadline は 10〜600 秒。modifyAckDeadline で延長（リース延長）できる
• グローバルサービス: トピック/サブスクリプションは単一のグローバルなエンドポイントを持ち、配信はメッセージストレージポリシーに従う
• 1 トピックに対して 多数のサブスクリプション（既定上限はあるが大規模利用可）を作成しファンアウトできる
• exactly-once 配信 はオプションで有効化可能（リージョン内・Pull で、ack の重複排除を保証）

内部の仕組み

パブリッシャーがトピックへ発行すると、メッセージは Pub/Sub の 分散ストレージへ複数コピーで永続化 され、その時点で各サブスクリプションのキューへ振り分けられます。サブスクライバーは Pull なら API で取得、Push なら Pub/Sub からの POST を受信します。取得したメッセージは ackDeadline の間 “処理中” として保持 され、その間は再配信されません。

• 処理に成功して ack すると、そのサブスクリプションからメッセージが削除される
• ackDeadline 内に ack できなければ 再配信（＝少なくとも 1 回配信。冪等処理が前提）
• 規定回数（maxDeliveryAttempts）失敗すると デッドレタートピック へ移動する
• 順序指定キー を付けると、同一キーのメッセージは前のメッセージが ack されるまで次を送らず、発行順を保つ

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

• ファンアウト: 1 トピックに複数サブスクリプションを付け、通知・分析・在庫更新などへ同報（AWS の SNS → 複数 SQS のパターンを 1 サービスで実現）
• Push → Cloud Run / Cloud Functions: メッセージ到着でサーバーレスを起動。受信側が 2xx を返すと ack 扱い
• デッドレタートピック で失敗を退避し、原因調査・再投入。再配信回数は maxDeliveryAttempts で制御
• 指数バックオフの再試行ポリシー を設定し、ダウンストリーム障害時のリトライ嵐を抑制
• Pub/Sub → BigQuery サブスクリプション / Cloud Storage サブスクリプション: サブスクライバーのコードを書かずに、メッセージを直接 BigQuery テーブルや GCS に取り込む
• 大きいペイロードや厳密な順序が要る場合は 順序指定キー や スキーマ検証 を併用
• ストリーミング集計が必要なら Dataflow（Apache Beam） と組み合わせる

運用・監視

• Cloud Monitoring のメトリクスで滞留を監視:
  • subscription/num_undelivered_messages（未配信メッセージ数。SQS の ApproximateNumberOfMessagesVisible 相当）
  • subscription/oldest_unacked_message_age（最古の未 ack メッセージの経過秒。SQS の ApproximateAgeOfOldestMessage 相当）
• 滞留増 → サブスクライバー不足や ダウンストリーム障害、ack 失敗を疑う
• デッドレタートピックに溜まる → 処理ロジック / 権限（IAM）/ メッセージ形式 を確認
• シーク（Seek） でタイムスタンプ／スナップショットに巻き戻し、再処理やバグ修正後のリプレイが可能
• Push の 4xx/5xx は再配信されるため、受信側エンドポイントの可用性とレイテンシを監視

コスト

課金はおもに メッセージのスループット量（取り込み・配信・保持のデータ量） に対して発生します。リクエスト単位ではなく転送バイト量が中心で、最小課金メッセージサイズの考え方があります。

セキュリティ

• IAM でトピック/サブスクリプション単位の権限を制御（roles/pubsub.publisher、roles/pubsub.subscriber など）。最小権限を徹底
• パブリッシャー/サブスクライバーには サービスアカウント を使い、鍵のハードコードを避ける（AWS の IAM ロール相当）
• 転送中は TLS、保存時は Google 管理鍵で既定暗号化。要件次第で CMEK（Cloud KMS の顧客管理鍵） を指定
• VPC Service Controls で境界を作り、データの持ち出しを防止
• Push サブスクリプションは OIDC トークン認証 を有効化し、エンドポイント側で発行元（サービスアカウント）を検証する

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

ハンズオン / CLI例

# トピックを作成
gcloud pubsub topics create jobs

# Pull サブスクリプションを作成（ack 期限 30 秒、デッドレターも設定）
gcloud pubsub subscriptions create jobs-sub \
  --topic=jobs \
  --ack-deadline=30 \
  --dead-letter-topic=jobs-dlq \
  --max-delivery-attempts=5

# メッセージを発行（属性付き）
gcloud pubsub topics publish jobs \
  --message='{"id":"job-1"}' \
  --attribute=source=cli

# メッセージを取得して即 ack（手動確認）
gcloud pubsub subscriptions pull jobs-sub --auto-ack --limit=10

# ファンアウト: 同じ jobs トピックにもう 1 本サブスクリプションを追加
gcloud pubsub subscriptions create jobs-analytics --topic=jobs

# Push サブスクリプション（Cloud Run などへ OIDC 認証付きで配信）
gcloud pubsub subscriptions create jobs-push \
  --topic=jobs \
  --push-endpoint=https://example-xxxx.a.run.app/ \
  --push-auth-service-account=pubsub-pusher@PROJECT_ID.iam.gserviceaccount.com