パブリッシュ／サブスクライブパターン＠通信方式¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. パブリッシュ／サブスクライブパターン¶
パブリッシュ／サブスクライブパターンとは¶
送信元から複数の宛先に非同期的に単方向で通信する。
送信元と宛先で通信処理が独立して実行されるため、メッセージ中継システムを経由した非同期通信を実行することになる。
送信元はメッセージ中継システムにメッセージをパブリッシュする。
プル型のサブスクライブの場合、サブスクライバーはメッセージ中継システムにポーリング受信を実行し、メッセージの取得を待機する。
プッシュ型のサブスクライブの場合、メッセージ中継システムはメッセージをサブスクライバーに送信する。
プル型¶
▼ プル型とは¶
メッセージの宛先は、メッセージ中継システムにポーリング受信を実行し、メッセージを受信する。
宛先で障害が起こっていても、障害の回復後にメッセージを処理すればよいため、耐障害性が高い。
▼ 例¶
RabbitMQのプル型では、RabbitMQにポーリング (HTTP、AMQPなど) を実行し、メッセージの取得を待機する（購読予約は無い）。
Apache Kafkaのプル型では、サブスクライブによる購読予約をKafkaに実行し、その上でポーリング受信をKafkaに実行する必要がある。
- RabbitMQ (プル型だけでなく、プッシュ型も選べる)
- Apache Kafka
| メッセージブローカー | プル型のSubscribe | サブスクライブのポーリング受信 |
|---|---|---|
| Apache Kafka | 必要 | 必要 |
| RabbitMQ | 不要 | 必要 |
プッシュ型¶
▼ プッシュ型とは¶
メッセージ中継システムはサブスクライバーにメッセージを送信する。
宛先で障害が起こっていると、メッセージが損失する可能性があるため、耐障害性が低い。
これに対処するために、メッセージ中継システムで、リトライやデッドレターキューが必要になる。
▼ 例¶
- RabbitMQ (プッシュ型だけでなく、プル型も選べる)
- AWS SNS
- AWS EventBridge
| メッセージブローカー | プッシュ型のSubscribe | サブスクライブへの送信 |
|---|---|---|
| Apache Kafka | 非対応 | 非対応 |
| RabbitMQ | 必要 | 自動 |
| AWS EventBridge | 必要 | 自動 |
02. プロデュース/コンシュームパターン¶
プロデュース/コンシュームパターンとは¶
送信元から単一の宛先に非同期的に単方向で通信する。
プル型¶
双方向通信 (クライアント → サーバー → クライアント) である。
- AWS SQS
プッシュ型¶
単方向通信 (サーバー → クライアント) である。
03. メッセージ中継システム¶
メッセージブローカー¶
- Apache Kafka
- AWS SNS
- Google Cloud Pub/Sub
- RabbitMQ
メッセージキュー¶
- AWS SQS
- EMQX
イベントバス¶
- AWS EventBridge
- CloudEvents
04. メッセージに使用するプロトコル¶
| プロトコル | 通信方式 | 対応するメッセージ中継システム例 | 一般的 |
|---|---|---|---|
| AMQP | バイナリ | RabbitMQ、Apache Qpid | ✅ |
| MQTT | バイナリ | EMQX | ✅ |
| Kafka Protocol (Kafka独自プロトコル) | バイナリ | Apache Kafka | ✅ |
| STOMP | テキスト | RabbitMQ | |
| HTTP/1.1、Webhook | テキスト (例：JSON、XMLなど) | AWS SQS、AWS SNS、Google Cloud Pub/Sub | |
| HTTP/2 (例：gRPC、GraphQLなど) | バイナリ (例：Protocolbuf) | 調査中... | |
| WebSocket | テキスト、バイナリ | 調査中... |