はじめに
最近、個人的にKafkaの話をする機会が増えてきて、
「MQとkafkaって何が違うのですか」とご質問をいただくことがありました。
一方で、これまで長く使われてきたMQも、今なお多くの現場で重要な役割を担っています。
どちらも「メッセージング」と呼ばれる技術ですが、
同じ土俵で比較すると、かえって混乱することが多いと感じています。
この記事では、
「機能比較」や「性能比較」ではなく、
実際にどう使われているかという視点で
MQとKafkaの違いを整理してみます。
一言で言うと何が違う？
まずはかなり雑にまとめると、こんな違いになります。
| 観点 | MQ | Kafka |
|---|---|---|
| 基本思想 | 確実に届ける | 流れを止めない |
| 主な用途 | 業務処理・基幹連携 | イベント・データストリーム |
| メッセージの扱い | 処理後に消える | ログとして残る |
この時点で、
「似ているようで、考え方が結構違う」
という雰囲気が伝われば十分です。
処理モデルの違い
ここが一番イメージしやすいポイントです。
MQの場合
- Producerがメッセージをキューに送る
- Consumerがそれを受け取り、処理する
- 処理が完了したらメッセージは消える
MQは、
「1メッセージ＝1業務処理」
という考え方がとてもはっきりしています。
この処理を、確実に一度だけ完了させたいという業務に向いています。
Kafkaの場合
- Producerがデータをトピックに書き込む
- データはログとして一定期間保持される
- Consumerは必要なタイミング・位置から読む
Kafkaでは、
データを処理するというより、流れとして残す
という考え方が中心になります。
同じデータを、
- あるサービスはリアルタイム処理に使い
- 別のサービスは後から分析に使う
といった使い方が自然にできます。
実務ではどう使い分けているか
「じゃあどっちを使えばいいの？」と聞かれることも多いですが、
実際には使い分けるケースがほとんどです。
MQが向いているケース
- 基幹系システムの連携
- バッチ処理や業務トランザクション
- 失敗したら困る処理
- 処理順序が重要なケース
Kafkaが向いているケース
- イベント通知
- リアルタイム分析
- 複数システムで同じデータを使いたい場合
- 将来の用途がまだ見えていないデータ
「どちらか一方を選ぶ」というより、
役割に応じて組み合わせるのが自然だと感じています。
まとめ
MQとKafkaは、
同じ「メッセージング」という言葉で語られがちですが、
根底にある思想はかなり異なります。
- MQは 確実な業務処理 のための仕組み
- Kafkaは 流れとしてのデータを活かす ための仕組み
この違いを意識できると、
技術選定の議論がぐっと整理しやすくなります。
軽めな整理として誰かの理解の助けになれば嬉しいです。