[메시지 브로커] rabbitMQ vs activeMQ vs kafka

 

spring을 이용한 캡스톤 프로젝트 진행 중 요구사항 중 채팅 기능이 있었다. 이를 구현하기 위해 spring에서 webSocket과 stomp를 사용해 구현했다.

이때 기본 내장 브로커는 안정성, 확장성 측면에서 단점이 많아 외부 브로커를 도입했다.

(장애 발생시 메시지 유실, 수용가능한 세션 크기 제한, 모니터링이 어려움, 서버 분리,확장이 안됨)

찾아보니 많이 사용하는 것들이 아래의 3개이기 때문에 각각의 특징을 알아보려고 한다.

 

우선 아래의 세가지 모두 비동기 메시지를 사용하는 서비스들 사이에서 데이터 송수신을 의미하는 MOM(메시지 지향 미들웨어)를 구현한 메시지큐이다.

메시지 큐의 특징으로는

• 큐를 사용한 비동기 처리
• 어플리케이션과의 분리
• 실패에도 전체에 영향을 주지 않음
• 여러 프로세스가 큐에 메시지를 보낼 수 있음

등 이 있다.

 

• rabbitMQ

AMQP기반의 오픈소스 메시지 브로커

AMQP는 ISO 응용 계층의 MOM표준 프로토콜

direct,fanout,topic 등 다양한 기능과 라우팅 키로 유연한 라우팅 가능

빠르고 쉬운 구성.

실시간 모니터링 용이.

관리 UI 등 다양한 플러그인 제공으로 편의성과 확장성.

작업자간 부하를 공유

 

-> 복잡한 라우팅이 필요하고, 신속한 요청-응답이 필요한 곳, 안정적인 백으라운드 작업 등에 적합

• activeMQ

자바로 만든 JMS기반의 오픈소스 메시지 브로커.

JMS는 자바 어플리케이션에서 MOM을 지원하는 표준 api

Java외의 언어도 지원하지만 JMS가 아닌 다른 MOM과는 통신이 불가능하다.

 

rabbitMQ와 유사한 방식이고 현재의 요구사항에서 rabbitMQ에 비해 크게 의미있는 장점을 찾지 못했다.

 

• kafka

이벤트 브로커.(메시지 브로커의 역할 가능) 소비자가 필요한 시점에 이벤트를 pull 해오는 방식으로 동작.

별도의 라우팅이 없음

대용량 데이터 병렬 처리에 특화 (특화되어있기 때문에 제공해주는 기능 자체는 적음)

분산시스템

단순한 헤더를 가진 TCP 기반 메시지 큐, 오버헤드가 적음

메시지를 파일시스템에 저장하여 메시지 유실 위험이 적음.

 

-> 복잡한 라우팅 필요없이 최대 처리량으로 이벤트 소싱, 스트리밍 등에 적합

 

 

 

간단한 특징들을 알아보았는데 채팅을 구현하기에는 kafka보다는 메시지 브로커가 어울려 보였고, 두가지 메시지 브로커중 호환성이 높고 직관적인 ui도 제공해주는 rabbitMQ를 선택했다.

 

 

참고:

https://heeveloper.github.io/2021/10/05/study-Kafka/#rabbitmq%EA%B0%80-%EC%A0%81%EC%A0%88%ED%95%9C-%EA%B3%B3