メッセージキューとイベントストリーミング

文書基準: 2026年8月

概要

メッセージキューはレストランの注文伝票のようなものです。ホール(生産者)が伝票を挿すと、厨房(消費者)が忙しいときは伝票が積み上がり、余裕ができれば順番に処理します。ホールは厨房の状態を知らなくても構いません。

イベントストリーミングはラジオ放送のようなものです。放送局(生産者)は一度送出し、複数のリスナー(消費者)がそれぞれ異なるタイミングで聴くことがあります。録音(保存)しておけば後で再度聴くこともできます。

注文サービスが決済 → 在庫 → 通知を同期で呼び出すと:

メッセージキューを入れると: 注文は即座に完了し、残りはそれぞれの速度で処理します。障害が隔離されます。

クラウドサービス	オンプレミス対応
SQS、Service Bus Queue	IBM MQ(MQ Series)、RabbitMQ、ActiveMQ
MSK、Event Hubs	Apache Kafka(自前運用)
SNS、Event Grid	RabbitMQ Exchange(fanout)、TIBCO
EventBridge、Eventarc	ESB(Enterprise Service Bus) — ただしESBより軽量

マイクロサービス間の直接呼び出し(同期)は結合度を高め、障害が伝播します。メッセージキューとイベントストリーミングはサービス間通信を非同期に分離し、疎結合、負荷緩衝、障害隔離を提供します。

領域	AWS	Azure	Google Cloud	OCI
メッセージキュー	SQS	Service Bus Queue	Cloud Tasks	OCI Queue
Pub/Sub	SNS	Service Bus Topic	Pub/Sub	OCI Streaming
イベントルーティング	EventBridge	Event Grid	Eventarc	OCI Events
ストリーミング(Kafka互換)	MSK	Event Hubs(Kafkaプロトコル互換)	Pub/Sub + Dataflow	OCI Streaming(Kafka互換)

要件	推奨
シンプルな作業キュー(非同期処理、リトライ)	SQS、Service Bus Queue、Cloud Tasks、OCI Queue
イベントファンアウト(1:N通知)	SNS、Service Bus Topic、Pub/Sub
イベント駆動アーキテクチャ(ルーティング、フィルタリング)	EventBridge、Event Grid、Eventarc
大容量リアルタイムストリーミング(ログ、クリックストリーム)	MSK/Kafka、Event Hubs、Pub/Sub、OCI Streaming
イベントソーシング(履歴再生が必要)	Kafka(MSK)、Event Hubs(Capture)
ベンダー中立(マルチクラウド)	Apache Kafka(自前運用またはConfluent Cloud)

メッセージキューとイベントストリーミングを混同して選択 — 1:1の作業キューが必要なのにKafkaを導入したり、イベント再生が必要なのにSQSを選択すると、アーキテクチャが合いません。
Dead Letter Queue(DLQ)を設定しない — 処理失敗メッセージが無限リトライされるとキューが詰まり、正常なメッセージも処理されなくなります。
メッセージ順序保証が必要なのに一般的なキューを使用 — 標準キューは順序を保証しません。順序が重要な場合はFIFOキューまたはパーティションキーベースのストリーミングを選択してください。