メッセージキュー めっせーじきゅー
簡単に言うとこんな感じ!
郵便ポストみたいなものだよ!送り手が手紙(メッセージ)をポストに入れておけば、受け取り手は自分のタイミングで取り出せる。お互いに「同時に対面しなくていい」から、片方が忙しくても処理が滞らないんだ!
メッセージキューとは
メッセージキューとは、システムやアプリケーション同士が「メッセージ」という単位でデータをやり取りする際に使う「一時的な待ち行列(キュー)」のことです。送り手(プロデューサー)がメッセージをキューに送り込むと、受け手(コンシューマー)は自分の処理が終わったタイミングでキューから取り出して処理します。
ポイントは「非同期処理」にあります。通常の関数呼び出しやAPIリクエストは「送ったらすぐ返事が来るまで待つ」同期処理ですが、メッセージキューを使うと送り手と受け手が直接つながらなくてよくなる(疎結合)ため、片方が遅くても・落ちていても、もう片方は影響を受けにくくなります。
たとえば、ECサイトで注文を受けた瞬間に「在庫引き当て」「メール送信」「請求処理」をすべて同時にやろうとすると処理が重くなります。メッセージキューを使えば、注文受付だけ即座に完了させ、残りの処理はキューに積んで順番にこなすことができます。これがシステムのスケーラビリティ(拡張性)と安定性を高める理由です。
メッセージキューの仕組みと構造
登場人物と役割
| 役割 | 別名 | 説明 |
|---|---|---|
| プロデューサー | Publisher / Sender | メッセージを生成してキューに送り込む側 |
| キュー(Queue) | ブローカー | メッセージを一時的に保持する待ち行列 |
| コンシューマー | Subscriber / Receiver | キューからメッセージを取り出して処理する側 |
| メッセージブローカー | — | キューを管理するミドルウェア全体(RabbitMQ, Kafkaなど) |
処理の流れ
[プロデューサー] → [キュー] → [コンシューマー]
注文受付アプリ 待ち行列 在庫・メール・請求の各処理
(すぐ返る) (溜めておく) (順番に処理)
キューの特性:FIFO(先入れ先出し)
基本的にFIFO(First In, First Out)で動作します。最初に入ったメッセージが最初に取り出されます。「行列に並んだ順に処理される」という直感的な動きです。一部のシステムでは優先度付きキューもサポートし、重要なメッセージを先頭に割り込ませることもできます。
覚え方:「郵便ポスト」で記憶する
プロデューサー=差出人、キュー=郵便ポスト、コンシューサー=宛先の人
差出人はポストに投函したら終わり。受取人はいつ取り出すかを自分で決められる。これがメッセージキューの本質です。
歴史と背景
- 1960〜70年代 — IBMのメインフレーム時代に「ジョブキュー」として非同期処理の概念が登場
- 1993年 — IBMが MQ Series(現 IBM MQ)をリリース。エンタープライズ向けメッセージキューの先駆け
- 2000年代前半 — JMS(Java Message Service)がJava EEの標準APIとして策定され、メッセージングが標準化される
- 2007年 — RabbitMQ がオープンソースとして公開。AMQP(Advanced Message Queuing Protocol)を実装し広く普及
- 2011年 — Apache Kafka がLinkedInで開発され、OSSとして公開。大量ログ・イベントストリーミング向けに台頭
- 2010年代後半〜 — クラウド各社がマネージドサービスを提供(AWS SQS / Google Pub/Sub / Azure Service Bus)し、開発現場への普及が加速
- 現在 — マイクロサービスアーキテクチャの普及とともにメッセージキューは現代システムの必須コンポーネントとなっている
主要なメッセージキュー製品・サービスの比較
| 製品・サービス | 種別 | 特徴 | 向いているユースケース |
|---|---|---|---|
| RabbitMQ | OSS | AMQP準拠・柔軟なルーティング | 汎用的なタスクキュー |
| Apache Kafka | OSS | 高スループット・ログ保持 | イベントストリーミング・ログ収集 |
| AWS SQS | クラウド | フルマネージド・低運用コスト | AWSシステムとの連携 |
| Google Pub/Sub | クラウド | グローバルスケール | GCPとの統合・リアルタイム分析 |
| Azure Service Bus | クラウド | エンタープライズ向け機能豊富 | Microsoftエコシステム |
| Redis(Streams) | OSS | 超高速・軽量 | リアルタイム性重視の小規模処理 |
メッセージキューと同期APIの違い
メッセージングパターンの種類
| パターン | 説明 | 例 |
|---|---|---|
| Point-to-Point | 1対1。1つのメッセージを1つのコンシューマーが処理 | タスクキュー・注文処理 |
| Pub/Sub(発行・購読) | 1対多。1つのメッセージを複数のコンシューマーが受け取る | 通知・イベント配信 |
| Request/Reply | キューを使いつつ返信も期待するパターン | 非同期RPC |
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| RFC 4627 | JSON形式(メッセージのペイロード形式として広く利用) |
| RFC 5321 | SMTP(メールキューの原型となったプロトコル) |
関連用語
- 非同期処理 — 処理の完了を待たずに次の操作へ進む実行モデル
- API — システム間の連携インターフェース全般
- マイクロサービス — 機能ごとに独立したサービスに分割するアーキテクチャ
- イベント駆動アーキテクチャ — イベント発生を起点にシステムが動くアーキテクチャ設計
- Pub/Subモデル — 発行者と購読者を分離したメッセージング方式
- Apache Kafka — 大量イベントを高スループットで処理するメッセージストリーミング基盤
- スケーラビリティ — システムが負荷増大に対応して拡張できる性質
- 疎結合 — コンポーネント間の依存度を低く保つ設計原則