[RabbitMQ] 다른 메시지 큐 간 차이 (MQTT, ZeroMQ, Kafka)

RabbitMQ

• AMQP 프로토콜을 구현해 놓은 프로그램
• 신뢰성, 안정성과 성능을 충족할 수 있도록 다양한 기능 제공
• 유연한 라우팅: Message Queue가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능
• 클러스터링: 로컬 네트워크에 있는 여려 RabbitMQ 서버를 논리적으로 클러스터링 할 수 있고 논리적인 브로커도 가능 함.
• 오픈 소스로 상업적 지원이 가능

Kafka

• 대용량 실시간 로그 처리에 특화되어 설계된 메시징 시스템
• 기좀 범용 메시징 시스템 대비 TPS(Transaction Per Second)가 매우 우수함
• 특화된 시스템이기 때문에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공 되지 않음
• AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지는 TCP 기반 프로토콜을 사용함으로써 오버헤드 감소
• 다수의 메시지를 batch 형태로 Broker에게 한번에 전달 가능
  • 기존 시스템(AMQP 등)은 Producer가 Broker에게 다수의 메시지를 전송 할 때, 각 메시지를 개별적으로 전송해야 함. 이와 비교 하면 Kafka는 TCP/IP Round Trip 횟수를 줄여 성능을 향상 시킴.
• Consumer에 의해 처리된(acknowledged message)를 곧바로 삭제 하지 않음
  • ACK 처리된 메시지를 삭제 하지 않고, 파일 시스템에 그대로 두었다가 설정된 수명이 지나면 삭제하도록 처리함.
  • 메시지 처리 도중 문제가 발생 하였거나 처리 로직이 변경되었을 경우, Consumer가 메시지를 처음부터 다시 처리 (rewind) 할 수 있음.
• Consumer가 Broker로 부터 직접 메시지를 가지고 가능 PULL 방식으로 동작
  • 기존 메시징 시스템에서는 Broker가 Consumer에게 메시지를 Push 해주는 방식인데 반해, Consumer가 자신의 처리 능력 만큼의 메시지만 Broker에게 가져 오기 때문에 최적으 성능을 낼 수 있음
  • Broker의 Consumer와 메시지 관리에 대한 부담이 줄어 듬
  • 메시지를 쌓아 두었다가 주기적으로 처리하는 batch consumer의 구현이 가능
• 큐의 기능은 RbbitMQ, JMS등에 비해 많이 부족하지만, 대용량 메시지를 지원 할 수 있는 것이 가장 큰 특징

MQTT

• 초 경량 메시지 큐 프로토콜로 발행-구독(Pub/Sub) 방식에 초첨을 두고 있음
• AMQP와 마찬가지로 상호 운용이 가능하며, 임베디드 시스템에서 대규모 배포에 매우 적합
• AMQP 처럼 구독 관리와 메시지 라우팅을 위해 브로커에 의존 함

ZeroMQ

• 중앙 집중형 브로커 없이 메시지 전달 가능
• 하지만 브로커가 제공하는 영속성 및 전달 보장성은 없음
• 요청-응답(REQ-REP) 패턴, 발행-구독(PUB-SUB) 패턴 제공
• PUSH-PULL 방식을 제공해, 단 방향으로 흐르는 데이터 스트림을 다루는데 효과적
• 장점
  • 속도가 빠르고 가벼움
  • 브로커 필요 없음
  • 상호 운용 가능
• 단점
  • 메시지 내구성이 없고 신뢰성이 다소 떨어짐

 

 

참고

https://www.educba.com/amqp-vs-mqtt/

https://www.codetd.com/ko/article/6701106

https://12bme.tistory.com/176