💡

非同期APIのその先へ：メッセージキュー・Pub/Sub・イベントストリームを整理する

に公開
Pub/Sub
Web API
非同期処理
メッセージキュー
イベントストリーム
idea

はじめに

非同期APIを学んでいると、次にこんな言葉が出てきます。

  • メッセージキュー
  • Pub/Sub
  • イベントストリーム

どれも「非同期っぽい」けど、

何が違うの？
どれを使えばいいの？

と混乱しがちです。

この記事では、非同期APIを起点にして、
これらの関係を1つの整理された図として理解することを目的にします。

まず前提：非同期APIとは？

非同期APIとは、

処理の完了を待たずに、すぐレスポンスを返すAPI

です。

リクエスト → 受付完了
      ↓
  （裏で処理）
  • APIは「処理を始める」だけ
  • 結果はあとで知る

非同期APIの次に考えること

非同期APIを作ると、次に出てくる課題があります。

「裏で動く処理を、どう安全に・拡張しやすくつなぐか？」

ここで登場するのが、

  • メッセージキュー
  • Pub/Sub
  • イベントストリーム

です。

一番下の土台：メッセージキュー

メッセージキューとは？

処理したいメッセージを一度ためて、あとで処理する仕組み

  • 送る側と受ける側を分離できる
  • 非同期処理の基本インフラ

例：

  • Amazon SQS
  • RabbitMQ

👉 これは「仕組み」そのもの
👉 API設計スタイルではありません

Pub/Sub（Publish / Subscribe）

何をしている仕組み？

イベントを、複数の購読者に配る設計パターン

登場人物は3つ。

  • Publisher：イベントを出す
  • Subscriber：イベントを受け取る
  • Broker：仲介役（多くの場合メッセージキュー）

ポイント

  • 誰が受け取るかを気にしなくていい
  • 後から購読者を増やせる

👉 Pub/Subは「使い方（パターン）」
👉 メッセージキューの上に成り立つことが多い

イベントストリーム

Pub/Subとの違いは？

イベントを「通知」ではなく「履歴」として扱う

  • イベントは保存される
  • 何度でも読み直せる
  • 時系列ログとして扱える

代表例：

  • Apache Kafka

👉 イベントが「流れるログ」になる

違いを一発で整理

項目 メッセージキュー Pub/Sub イベントストリーム
立場 仕組み 設計パターン アーキテクチャ
主な目的 非同期処理 通知・連携 記録・再生
複数購読 △ ◎ ◎
再読 × △ ◎

非同期APIとの関係

ここが一番大事です。

HTTP 非同期API
        ↓
   イベント発行
        ↓
キュー / Pub/Sub / ストリーム
  • APIは「入口」
  • キューやストリームは「内部のつなぎ役」

👉 役割が違うので競合しません

Webhookとの違い（よくある疑問）

  • Webhook：特定のURLに直接通知
  • Pub/Sub：仲介を挟んで配信

Webhookはシンプル、
Pub/Subはスケーラブル。

用途が違います。

どう選べばいい？

ざっくり指針はこれです。

  • 処理を安全に非同期化したい → メッセージキュー
  • 複数サービスに通知したい → Pub/Sub
  • 履歴を残して再処理したい → イベントストリーム

迷ったら、

まずはキュー or Pub/Subで十分

です。

まとめ（超重要）

  • 非同期API：入口の設計
  • メッセージキュー：非同期処理の土台
  • Pub/Sub：イベントの配り方
  • イベントストリーム：イベントの残し方

全部「非同期」だけど、役割は全然違う

参考リンク（一次情報）

Discussion