🔹 Kafka vs RabbitMQ
Kafka와 RabbitMQ는 모두 메시지 브로커(message broker)로, 분산 시스템 간의 데이터 전달을 돕는 역할을 한다.
그러나 설계 목적과 내부 동작 방식이 다르기 때문에 사용 시나리오도 크게 달라진다.
🔸 핵심 목적 및 사용 방식
| 구분 | Kafka | RabbitMQ |
|---|
| 주 사용 목적 | 대용량 실시간 데이터 스트리밍, 로그 수집, 이벤트 저장 | 요청/응답 기반 메시지 전달, 작업 큐(Work Queue) |
| 처리 방식 | Publish-Subscribe 모델 + 분산 로그 저장 | 메시지 큐 기반 브로커 패턴 |
| 메시지 전달 보장 방식 | Pull 방식 (소비자가 가져감) | Push 방식 (브로커가 푸시) |
🔹 아키텍처 구조 및 동작
🔸 Kafka
- 분산 로그 저장 시스템과 메시지 브로커 역할을 동시에 수행
- 메시지를 파일 시스템에 파티션 단위로 저장하여 대량의 이벤트 스트리밍 처리에 최적화
- 소비자는 오프셋(offset)을 기준으로 원하는 위치의 데이터를 다시 읽을 수 있음 → 재처리가 매우 용이
- 메시지 보존 기간을 지정하여 오래된 메시지도 유지 가능
🔸 RabbitMQ
- AMQP 프로토콜 기반 메시지 브로커
- Queue-Exchange-Binding 구조로 유연한 라우팅 지원 (Direct, Fanout, Topic 등)
- 메시지는 소비 후 삭제되는 방식이 일반적 → 작업 큐 기반 처리에 적합
- 메시지를 즉시 전달(Push)하고, 필요 시 ACK/NACK를 통한 신뢰성 보장
🔹 처리 성능 및 확장성
| 구분 | Kafka | RabbitMQ |
|---|
| 처리량 (Throughput) | 매우 높음 (수백만 TPS까지 확장 가능) | 중간~높음 (수만~수십만 TPS 정도) |
| 확장성 | Broker + Partition 수평 확장 용이 | 클러스터링 제공하지만 확장성 면에서 Kafka에 비해 제한적 |
| 지연 시간 | 낮은 지연, 고성능 실시간 처리 | 일반적으로 낮지만 Kafka 대비 고성능 스트리밍엔 부적합 |
🔹 주요 사용 사례
| Kafka | RabbitMQ |
|---|
| 로그 수집 (ELK Stack), IoT 이벤트 처리, Streaming Analytics, MSA 이벤트 버스, CDC 데이터 파이프라인 | 주문 처리 큐, 이메일/알림 처리, 비동기 요청/응답 처리, 작업 분배 (Worker Queue) |
🔹 운영 관점
| 구분 | Kafka | RabbitMQ |
|---|
| 구축 난이도 | 비교적 어려움 (Zookeeper 필요 / Kafka KRaft 모드 도입 중) | 비교적 쉬움 |
| 관리 도구 | Kafka UI, Prometheus, Grafana 등 별도 툴 필요 | 기본 제공 UI, 플러그인 활용 쉬움 |
| 메시지 재처리 | 매우 쉬움 (Offset 기반) | 구현 난이도 중간 (Dead Letter Queue 등 필요) |
🔹 정리
- Kafka는 이벤트 스트림과 데이터 파이프라인 중심의 고성능, 대용량 로그 및 실시간 처리에 특화.
- RabbitMQ는 전통적인 메시지 큐잉 시나리오, 예: 비동기 요청/응답 처리, 백그라운드 작업 처리 등에 적합.
필요에 따라 두 시스템을 함께 사용하는 것도 가능하다.
예를 들어, Kafka로 실시간 이벤트를 수집하고, RabbitMQ로 사용자 알림 전달을 처리하는 방식처럼.
🔸 선택 기준 조언
| 상황 | 추천 |
|---|
| 대규모 로그/이벤트 수집 및 분석이 필요 | ✅ Kafka |
| 단순한 비동기 작업 처리, 작업 분배 | ✅ RabbitMQ |
| 메시지를 다시 읽고 재처리해야 하는 경우 | ✅ Kafka |
| 복잡한 라우팅 규칙 필요 (Direct, Topic 등) | ✅ RabbitMQ |
