KUKJIN LEE
posted 1 month ago
RabbitMQ와 Kafka 무엇을 선택해야할까?
RabbitMQ와 Kafka 모두 메시징 시스템 또는 메시지 브로커로 자주 언급되지만, 그 설계 철학과 사용 목적, 내부 구현 구조에서 차이가 있습니다.
RabbitMQ는 전통적인 메시지 큐(Message Queue) 모델에 가깝고, Kafka는 로그 기반 스트리밍 플랫폼에 가깝습니다. 즉 실제 사용 시나리오와 인프라 아키텍처 결정에 따라 적합한 시스템을 사용해야 됩니다.
-
메시징 패턴의 차이점
RabbitMQ는 메시지를 큐에 넣고, 소비 후 큐에서 메시지가 사라지는 형태고, Kafka는 소비 후에도 메시지가 사라지지 않고, 주어진 보존 기간 남아 있어 소비자가 다른 시점에 메시지를 재처리 할 수 있습니다. 따라서 Kafka는 스트림 처리에 많이 사용됩니다.-
RabbitMQ: RabbitMQ는 메시지를 큐에 넣고, 이를 소비자가 가져가는 전통적인 "큐 기반" 모델에 충실합니다. 한 번 소비된 메시지는 기본적으로 큐에서 사라지는 형태를 취합니다. 이 구조는 명령(Command) 처리나 비동기 태스크 처리에 적합하며, 요청-응답 패턴, RPC 스타일의 비동기 처리, 복잡한 라우팅(exchange를 통한 라우팅) 등에 유리합니다.
-
Kafka: Kafka는 메시지를 토픽(Topic)이라는 로그에 지속적으로 적재하고, 소비자는 해당 로그를 "구독"하는 방식으로 메시지를 가져갑니다. 메시지는 소비 후에도 사라지지 않고, 주어진 보존 기간(retention period) 동안 남아 있어 다양한 소비자가 서로 다른 시점에 메시지를 재처리할 수 있습니다. 이는 이벤트 소싱(Event Sourcing)이나 스트림 처리(Stream Processing)에 이상적이며, 데이터 파이프라인 구축 및 분석 작업 등에도 잘 맞습니다.
-
-
성능 특성 및 확장성
스트리밍과 같이 여러 사용자가 메시지 요청을 진행하는 경우 Kafka, 낮은 지연과 높은 처리량을 원한다면 RabbitMQ를 사용하는 것이 적합합니다.-
RabbitMQ: 전통적으로 낮은 지연(Latency)과 높은 처리량을 제공하며, 라우팅(exchange)를 통한 유연한 메시지 전달이 장점입니다. 하지만 대규모 데이터 스트리밍이나 장기적으로 메시지를 보관하면서 "재처리"하는 데는 부적합한 경우가 많습니다.
-
Kafka: 고성능, 고처리량, 파티션 기반 확장성에 매우 특화되어 있으며, 디스크에 지속적으로 메시지를 저장하기 때문에 데이터 파이프라인 구성 시 강력한 이점을 갖습니다. 특히 실시간 데이터 스트림을 처리하고, 여러 소비자가 다양한 시점에서 동일한 데이터 스트림을 재분석하는 경우에 유리합니다.
-
-
활용 시나리오
-
RabbitMQ 활용
-
마이크로서비스 간의 비동기 요청 처리
-
특정 워커(Worker)들에게 작업 할당
-
백엔드 연산을 비동기로 처리해 응답 속도 최적화
-
전통적 MSA에서 주문 처리, 이메일 알림 전송 등 단발성 이벤트 처리
-
-
Kafka 활용
-
실시간 로그 수집 및 분석 파이프라인
-
이벤트 소싱 기반 시스템 아키텍처
-
스트리밍 플랫폼(Kafka Streams, Flink 등) 연계로 실시간 데이터 변환 및 집계
-
높은 처리량이 필요한 IoT 센서 데이터 수집 및 분석
-
-
단순히 비동기 요청-응답이나 태스크 디스패칭에 초점을 두고 있다면 RabbitMQ가 더 직관적일 수 있습니다. 반면, 대량의 데이터 스트림, 이벤트 소싱, 여러 소비자가 재처리 가능한 로그 기반 메시징 환경이 필요하다면 Kafka가 더 적합합니다. 이벤트 중심적이고 재처리가 빈번하며, 분석 및 확장이 잦은 환경이라면 Kafka를 추천하고, 단순한 비동기 업무 분산과 서비스 간 결합도 해소 목적이라면 RabbitMQ가 좀 더 적합합니다.