Enjoy IT Life

Pub/Subとは何か: Publisher・Topic・Subscription・Subscriberの基本

インフラ

Pub/Sub は、処理同士を直接つなげずに、メッセージを中継するための設計パターンです。

正式には Publish/Subscribe パターン と呼ばれます。送信側である Publisher はメッセージを Topic に publish し、受信側である Subscriber は Subscription を通じてそのメッセージを受け取ります。

Publisher
  ↓ publish
Topic
  ↓ deliver
Subscription
  ↓ pull / push
Subscriber

この記事では、Pub/Sub の基本構造、登場人物、Topic と Subscription の関係を整理します。

Pub/Subが解決する問題

Pub/Sub を使わない同期処理では、処理同士が直接つながります。

注文API → メール送信API

この構成では、メール送信APIが遅い場合や一時的に落ちている場合に、注文APIも影響を受けます。

Pub/Sub を挟むと、注文APIは「注文が作成された」というイベントを送るだけでよくなります。

注文API → Pub/Sub → メール送信処理

注文APIはメール送信処理を直接呼びません。後続処理が一時的に落ちていても、メッセージは Subscription 側に残り、復旧後に処理できます。

Pub/Sub の主な価値は以下です。

  • 送信側と受信側を疎結合にする
  • 重い処理を非同期化する
  • 下流障害の影響を上流に伝播させにくくする
  • スパイクしたリクエストをバッファする
  • 1つのイベントを複数の処理に配る

Pub/Subの主要な用語

Pub/Sub を理解するうえで、まず押さえる用語は以下です。

名前役割例
Publisherメッセージを送る側注文API、決済API、センサー、バッチ処理
MessagePublisher が publish し、Subscriber が処理するデータorder.created イベント、決済完了イベント
TopicPublisher が publish する名前付きの配信経路order-created、payment-completed
SubscriptionTopic のメッセージを Subscriber に届ける配信設定send-email-sub、save-analytics-sub
SubscriberSubscription から読んで処理するプログラムメール送信Worker、分析保存Worker

重要なのは、Publisher は Message を Topic という経路に publish する、Subscriber は Subscription を経由して Message を受け取るという点です。

Topic や Subscription は、アプリケーションのデータを保存するDBのような箱ではありません。Topic はイベントの流し先を表す名前で、Subscription はその Topic のイベントをどの Subscriber にどう届けるかを表す設定です。

Subscriber が Topic を直接読むわけではありません。

PublisherとProducerの違い

Pub/Sub の文脈では、メッセージを送る側を Publisher と呼びます。

一方、メッセージングシステム全般では Producer という言葉もよく出てきます。意味としてはほぼ同じで、「メッセージを作って送る側」を指します。

この記事では GCP Pub/Sub の用語に合わせて Publisher を使います。

SubscriberとConsumerの違い

Pub/Sub の文脈では、メッセージを受け取って処理する側を Subscriber と呼びます。

一方、Kafka など他のメッセージングシステムでは Consumer という言葉がよく使われます。Consumer は「メッセージを消費する側」という一般的な呼び方です。

この記事では GCP Pub/Sub の用語に合わせて Subscriber を使います。ただし、他の記事やドキュメントで Consumer と書かれている場合は、この記事でいう Subscriber に近い役割だと考えると読みやすくなります。

注文作成を例にした流れ

ECサイトで注文が作成されたケースを考えます。

Client
  ↓ POST /orders
Order API
  ↓ publish
Topic: order-created
  ↓
Subscription: send-email-sub
  ↓
Email Worker

Order API は注文作成後に、以下のようなイベントを publish します。

{
  "event_id": "evt-001",
  "event_type": "order.created",
  "order_id": "order-123",
  "user_id": "user-456",
  "total_amount": 9800,
  "created_at": "2026-07-10T10:00:00+09:00"
}

Order API はメール送信処理を直接呼びません。order-created Topic に「注文が作られた」という事実を流します。

send-email-sub は、order-created Topic に届いたメッセージを受け取るための Subscription です。

Email Worker は、この send-email-sub を経由してメッセージを受け取り、メールを送信します。

受け取り方は Subscription の種類によって変わります。Pull 型なら Email Worker が send-email-sub に取りに行き、Push 型なら Pub/Sub が Email Worker や Email API のHTTPエンドポイントに送ります。

どちらの場合も、Email Worker が Topic を直接見に行くのではなく、Topic に紐づいた Subscription を経由して受け取る、という関係です。

より詳細なメッセージの動きは『Pub/Subのデータの流れをシーケンス図で理解する』で扱います。

関連記事Pub/Subのデータの流れをシーケンス図で理解する2026-07-10

TopicとSubscriptionの関係

Pub/Sub で特に混乱しやすいのは、複数 Subscription と複数 Subscriber の違いです。

1 Topicに複数Subscriptionを作る場合

1つの Topic に複数の Subscription を作ると、同じメッセージがそれぞれの Subscription に届きます。

Topic: order-created
├─ Subscription: send-email-sub
│  └─ メール送信
├─ Subscription: save-analytics-sub
│  └─ 分析保存
└─ Subscription: update-inventory-sub
   └─ 在庫更新

これは ファンアウト です。

1つの注文作成イベントを、メール送信、分析保存、在庫更新にそれぞれ使いたい場合は、Subscription を用途ごとに分けます。

1 Subscriptionを複数Subscriberで読む場合

一方、1つの Subscription を複数の Subscriber で読む場合、同じメッセージが全員に届くわけではありません。

Subscription: send-email-sub
├─ Email Worker 1
├─ Email Worker 2
└─ Email Worker 3

この場合は、メール送信処理を複数 Worker で分担します。

  • Worker 1 が msg-1 を処理する
  • Worker 2 が msg-2 を処理する
  • Worker 3 が msg-3 を処理する

同じ処理を高速化したい場合は、Subscription を増やすのではなく、同じ Subscription を読む Subscriber を増やします。

ファンアウトと並列処理の違い

違いを整理すると以下のようになります。

やりたいこと作り方
同じイベントを複数用途に配りたい1 Topic に複数 Subscription を作る
同じ処理を複数台で分担したい1 Subscription を複数 Subscriber で読む

この違いが分かると、Pub/Sub の構成図を読みやすくなります。

Pub/Subは保存先ではない

Pub/Sub はメッセージを一定期間保持しますが、永続的な保存先ではありません。

役割としては、データを「保管する場所」ではなく、イベントを「伝える場所」です。

場所役割
DB / Storageデータを保存する場所
Pub/Subデータが発生したこと、変更されたことを伝える場所

たとえば、注文データそのものはDBに保存します。一方で「注文が作成された」というイベントを Pub/Sub に流します。

Order API
├─ DB に注文を保存
└─ Pub/Sub に order.created を publish

Pub/Subで設計時に考えること

Pub/Sub を使うときは、単にメッセージを送れば終わりではありません。

実装・運用では以下を考える必要があります。

論点内容
AckSubscriber が処理完了を Pub/Sub に伝える仕組み
再配信Ack されなかったメッセージが再度届く仕組み
重複処理同じメッセージが複数回届く可能性を前提にする
冪等性同じ処理を2回実行しても結果が破綻しない性質
Dead Letter Topic失敗し続けるメッセージを隔離する逃がし先
順序保証同じキーに属するメッセージの順序を守るかどうかの論点
Push / PullPub/Sub から押すか、Subscriber が取りに行くかの違い

これらは Pub/Sub の概要というより、Pub/Sub を使って壊れにくい処理を設計するための論点です。詳しくは『Pub/Subを設計するときに考えること』で整理します。

関連記事Pub/Subを設計するときに考えること2026-07-10

まとめ

Pub/Sub は、Publisher と Subscriber を直接つなげず、Topic と Subscription を介してメッセージを受け渡す仕組みです。

基本の理解では、以下を押さえます。

  • Publisher は Topic に publish する
  • Subscriber は Subscription から読む
  • 複数 Subscription はファンアウトを表す
  • 複数 Subscriber は処理の分担を表す
  • Pub/Sub は保存先ではなく、イベントの伝達層である
あわせてよみたい Pub/Subのデータの流れをシーケンス図で理解する 2026-07-10
あわせてよみたい Pub/Subのユースケースとアーキテクチャパターン 2026-07-10
あわせてよみたい GCP Pub/Subと周辺サービスの役割分担 2026-07-10
タグ: PubSub, メッセージング