Post
카프카 (Kafka)와 래빗MQ (RabbitMQ) 상세 비교 분석
카프카(Kafka)와 래빗MQ(RabbitMQ)는 분산 시스템에서 비동기 통신을 처리하는 가장 널리 사용되는 두 가지 솔루션입니다. 하지만 둘은 설계 철학과 강점에 명확한 차이가 있어, 시스템의 목적에 따라 적합한 선택이 달라집니다.
1. 근본적인 아키텍처 및 철학 비교
| 구분 | 래빗MQ (RabbitMQ) | 카프카 (Kafka) |
|---|---|---|
| 핵심 역할 | 전통적인 메시지 브로커 (Message Broker) | 분산 이벤트 스트리밍 플랫폼 (Event Streaming Platform) |
| 메시지 모델 | 큐 (Queue) 기반 | 분산 커밋 로그 (Log) 기반 |
| 메시지 소비 | Push (푸시) 모델 브로커가 소비자에게 메시지를 즉시 전달하고, 소비자가 처리 확인 응답(ACK)을 보내면 브로커가 메시지를 삭제. | Pull (풀) 모델 소비자가 원하는 속도로 브로커에 접속하여 특정 **오프셋(Offset)**부터 메시지를 가져감. |
| 데이터 보관 | 소비 후 즉시 삭제 (작업 큐 형태) | 영구 보관 (설정 기간 또는 용량 기반 보존) |
| 주요 장점 | 낮은 지연 시간 (Latency), 복잡한 라우팅 유연성 | 압도적인 처리량 (Throughput), 데이터 영속성, 재생 가능성 |
아키텍처 심화 설명
래빗MQ: 우체국 모델
- 래빗MQ는 메시지를 Exchange(교환소)로 보내고, Exchange는 Binding Rule(바인딩 규칙)에 따라 하나 이상의 Queue(큐)로 메시지를 라우팅합니다.
- 메시지는 큐에 도착하는 즉시 이를 구독하는 소비자에게 푸시됩니다. 소비자가 메시지를 성공적으로 처리했다는 응답을 보내면 해당 메시지는 큐에서 삭제됩니다.
- 이 모델은 메시지가 한 번에 한 명의 소비자에게 안정적으로 전달되어야 하는 작업 큐(Task Queue)나 P2P 통신에 최적화되어 있습니다.
카프카: 도서관 모델
- 카프카는 메시지를 Topic(토픽)에 발행하고, 토픽은 여러 개의 Partition(파티션)으로 나뉘어 클러스터에 분산 저장됩니다.
- 메시지는 파티션에 순차적으로 로그 형태로 기록됩니다. 소비자는 브로커로부터 메시지를 풀 방식으로 가져가며, 오프셋(Offset)이라는 인덱스를 통해 어디까지 읽었는지 직접 관리합니다.
- 메시지는 소비자가 읽었는지 여부와 관계없이 설정된 기간 동안 보존되므로, 여러 소비자가 같은 데이터를 독립적으로 다시 읽거나 소비할 수 있습니다. 이는 이벤트 소싱(Event Sourcing)이나 로그 분석에 이상적입니다.
2. 주요 기능 및 성능 비교
| 기능 | 래빗MQ (RabbitMQ) | 카프카 (Kafka) |
|---|---|---|
| 처리량 | 중간 (초당 수만 건) | 매우 높음 (초당 수십만~수백만 건) |
| 지연 시간 | 매우 낮음 (1~5ms 내외) | 상대적으로 높음 (10~100ms 내외) |
| 메시지 라우팅 | 복잡하고 유연함 (Direct, Topic, Fanout 등 Exchange 타입 지원) | 단순함 (Topic-Partition 기반) |
| 메시지 순서 보장 | 단일 큐에 단일 소비자일 때 보장. 다중 소비자 시 보장 어려움. | 파티션 내에서는 엄격하게 순서 보장 (여러 파티션 간 순서는 보장하지 않음). |
| 확장성 | 수직 확장(Scale-up) 중심, 수평 확장이 비교적 복잡함 | 수평 확장(Scale-out)에 최적화 (파티션 추가를 통한 선형적 확장) |
| 메시지 우선순위 | 지원 가능 | 지원하지 않음 (모든 메시지는 시간순으로 처리) |
| 메시지 프로토콜 | AMQP, STOMP, MQTT 등 다양한 프로토콜 지원 | 자체 바이너리 프로토콜 (TCP) 사용 |
3. 적합한 사용 사례 분석
두 기술 중 어떤 것을 선택할지는 시스템이 메시징 시스템에 요구하는 철학과 우선순위에 따라 달라집니다.
카프카 (Kafka)를 선택해야 하는 경우
카프카는 대규모 데이터 스트림의 영속적인 저장, 높은 처리량, 그리고 여러 시스템의 데이터 재활용이 핵심일 때 적합합니다.
- 대규모 로그 및 메트릭 수집: 사용자 활동 로그, 애플리케이션 로그, 서버 메트릭 등을 안정적으로 수집하고 여러 분석 시스템에 전달해야 할 때.
- 이벤트 소싱 (Event Sourcing): 모든 상태 변화를 이벤트(메시지)로 저장하고, 필요할 때 이벤트를 재생하여 상태를 복구하거나 변경해야 할 때.
- 실시간 스트림 처리: Flink, Spark Streaming 등과 연동하여 메시지를 실시간으로 분석하고 변환하는 파이프라인을 구축할 때.
- 데이터 파이프라인 구축: 데이터 레이크로 데이터를 이동시키거나 여러 마이크로서비스가 동일한 데이터를 독립적으로 소비해야 할 때.
✅ 래빗MQ (RabbitMQ)를 선택해야 하는 경우
래빗MQ는 낮은 지연 시간, 복잡한 라우팅, 그리고 메시지 처리 후 삭제되는 작업 큐가 핵심일 때 적합합니다.
- 작업 큐 (Task Queues): 웹 요청의 결과로 시간이 오래 걸리는 작업을 비동기적으로 처리할 때 (예: 이미지 처리, 이메일 발송, 파일 변환).
- 응답 시간이 중요한 통신: 메시지가 즉시 처리되고 응답해야 하는 시스템 간의 통신이 필요할 때.
- 복잡한 메시지 라우팅: 메시지의 속성(헤더, 라우팅 키)에 따라 동적으로 메시지를 여러 개의 다른 목적지(큐)로 분배해야 할 때.
- 레거시 시스템 통합: AMQP, MQTT 등 다양한 표준 프로토콜을 사용하여 기존 시스템이나 IoT 장치와 연동해야 할 때.
The big difference between Kafka, RabbitMQ, and Redis Queue! Let’s learn about event brokers and … 이 영상은 카프카와 래빗MQ의 근본적인 차이점(이벤트 브로커 vs 메시지 브로커)을 유명한 도구들을 중심으로 시각적으로 이해하는 데 도움을 줄 수 있습니다.