Kafka vs RabbitMQ — 메시지 큐 아키텍처 비교

Q: 두 시스템을 비교하면 어떻게 되나요?

| 항목 | Kafka | RabbitMQ | |------|-------|----------| | **아키텍처** | 이벤트 스트리밍(분산 로그) | 메시지 브로킹(라우팅) | | **처리량** | 초당 100만+ 메시지 | 초당 50만~100만 메시지 | | **지연시간** | ~10ms (배치 최적화) | ~1~10ms | | **메시지 보존** | 일정 기간/용량(설정 가능) | 소비 시 삭제(또는 수동 설정) | | **메모리 사용** | 메시지 크기 + 복제 인수 | 큐 크기에 직결 | | **라우팅 유연성** | 낮음(토픽 필터링) | 높음(여러 라우팅 방식) | | **복제 메커니즘** | 리더(leader)/팔로어(follower) | 미러링 또는 쿼럼 큐 | | **학습곡선** | 가파름(분산 개념 필수) | 완만(메시지 패턴 이해) |

Q: Kafka와 RabbitMQ는 어디에 사용되나요?

**Kafka 적용 분야**: - 실시간 이벤트 로깅 및 분석 시스템 - 금융 거래 데이터 스트림 처리 (초당 수백만 건) - 대규모 로그 수집 및 모니터링 - 머신러닝 피처 엔지니어링 파이프라인 LinkedIn은 하루 1조 개 이상의 메시지를 Kafka로 처리하며, 초당 200만 메시지 이상의 처리량을 유지한다. Netflix는 Kafka를 기반으로 실시간 스트림 처리 플랫폼을 운영하고 있다. **RabbitMQ 적용 분야**: - 작업 큐(task queue) 기반 백그라운드 작업 처리 - 마이크로서비스 간 비동기 통신 - 복잡한 라우팅 규칙이 필요한 워크플로우 - 낮은 지연시간과 높은 신뢰성이 필수적인 시스템 국내 전자상거래 기업들은 RabbitMQ를 기반으로 주문 처리, 재고 관리, 알림 발송 시스템을 구축했으며, 초당 10만~50만 건의 주문 트래픽을 안정적으로 처리하고 있다.

Q: 선택 기준은 무엇인가요?

**Kafka를 선택해야 할 때**: - 초당 수십만 개 이상의 메시지를 처리해야 함 - 오래된 메시지에 대한 재처리/재분석이 필요함 - 이벤트 소싱(event sourcing) 패턴을 적용함 - 실시간 스트림 처리 프레임워크(Spark, Flink)와 연동할 예정 **RabbitMQ를 선택해야 할 때**: - 초당 수만~십만 개 메시지 처리로 충분함 - 복잡한 라우팅 로직이 필요함 - 메시지 신뢰성 및 즉시 전달이 우선 - 빠른 구축과 운영 난이도 낮춤이 중요함

Q: 운영 복잡도는 어떻게 다른가요?

**Kafka 운영 난이도**: - 파티션 리밸런싱(rebalancing) 관리 - 브로커 스케일링 시 데이터 재분산 - 컨슈머 그룹 모니터링 및 지연 추적 - ZooKeeper 의존성 관리 (3.0 이상에서 개선) 일반적으로 중소 팀에서 Kafka 클러스터 운영에 필요한 전담 인력은 1~2명, 대규모 환경에서는 3~5명이다. **RabbitMQ 운영 난이도**: - 간단한 클러스터 설정 및 미러링 구성 - 웹 관리 UI(Management Plugin) 제공 - 토폴로지(topology) 관리 용이 - 메모리 알람(memory threshold) 모니터링 RabbitMQ는 운영 복잡도가 낮으므로 전담 인력 0.5~1명 수준으로 관리 가능하다.

Q: 정리하면 어떤가요?

Kafka와 RabbitMQ는 서로 다른 설계 철학을 따른다. **Kafka는 대규모, 고처리량 이벤트 스트림 처리에 최적화**되었으며 초당 100만 개 이상의 메시지를 안정적으로 처리할 수 있다. 반면 **RabbitMQ는 유연한 메시지 라우팅과 낮은 지연시간이 장점**이며, 초당 수십만~100만 개 메시지 처리에 적합하다. 기술 선택은 다음 세 가지 기준으로 판단된다: (1) 예상 메시지 처리량, (2) 라우팅 복잡도, (3) 운영 난이도와 팀 역량이다. 초당 수백만 건의 로그 수집이나 실시간 분석이 필요하면 Kafka, 낮은 지연시간과 복잡한 워크플로우가 중요하면 RabbitMQ를 선택하는 것이 일반적이다.

Q: Kafka의 파티션 수는 어떻게 결정하나요?

파티션 수는 컨슈머 병렬성과 처리량을 결정하는 핵심 파라미터다. 일반적으로 다음 공식을 사용한다: `파티션 수 = (목표 처리량 MB/s) / (단일 컨슈머 처리량 MB/s)`. 예를 들어 목표 처리량 1,000 MB/s이고 단일 컨슈머가 100 MB/s를 처리하면 최소 10개 파티션이 필요하다. 너무 많은 파티션은 브로커 메모리 사용과 모니터링 복잡도를 증가시키므로, 일반적으로 브로커당 2,000~4,000개 파티션 범위를 권장한다.

두 메시지 큐 시스템은 어떻게 다른가요?

Kafka(아파치 카프카)와 RabbitMQ는 서로 다른 아키텍처 원칙으로 설계됐다. Kafka는 높은 처리량(throughput)의 이벤트 스트리밍에 최적화된 발행-구독(pub-sub) 모델이며, RabbitMQ는 메시지 라우팅 유연성과 신뢰성 있는 전달을 우선한 메시지 브로커다. 두 시스템 모두 분산 환경에서 동작하지만 메모리 사용 패턴, 메시지 보존 기간, 확장 방식이 근본적으로 다르다.

Kafka는 어떻게 작동하나요?

Kafka는 분산 이벤트 스트리밍 플랫폼으로, 토픽(topic) 단위로 메시지를 분할(partition)하여 저장한다. 각 파티션은 브로커(broker) 노드에 분산되며, 메시지는 디스크 기반의 append-only 로그(log)로 기록된다. 프로듀서(producer)는 메시지를 토픽에 발행하고, 컨슈머(consumer)는 독립적으로 오프셋(offset)을 관리하여 메시지를 소비한다.

처리 성능: Kafka의 처리량은 초당 100만 개 메시지(1M msg/sec) 이상에 도달할 수 있다. 배치 처리(batch processing)와 압축(compression)을 통해 네트워크 대역폭을 효율적으로 사용한다. 메시지 보존 기간은 설정 가능하며, 기본값은 7일이다. 메모리 사용량은 초기 컨슈머 크기에 따라 다르지만, 메시지 복제(replication factor) 설정에 의존한다.

아키텍처 특성:

파티션 수: 병렬 처리 성능 선형 증가(각 파티션당 최대 1개 컨슈머)
복제 인수: 일반적으로 3 (가용성과 내결함성 확보)
지연시간(latency): 일반적으로 10ms 이상 (배치 지연)
메시지 순서 보장: 파티션 단위로 순서 보장

RabbitMQ는 어떻게 작동하나요?

RabbitMQ는 메시지 브로커로서 AMQP(Advanced Message Queuing Protocol) 0.9.1 표준을 구현한다. 익스체인지(exchange)가 메시지를 받아 라우팅 규칙(routing rule)에 따라 큐(queue)로 전달하고, 컨슈머가 큐에서 메시지를 소비한다. 각 메시지는 수신 확인(acknowledgment)을 받을 때까지 큐에 유지된다.

처리 성능: RabbitMQ의 처리량은 초당 50만~100만 개 메시지 범위이며, Kafka 대비 낮지만 복잡한 라우팅 로직 처리에 강점이 있다. 메모리 기반 메시지 저장소를 기본으로 하므로, 메모리 사용량이 메시지 큐 크기에 직결된다. 디스크 퍼시스턴시(persistence) 설정 시 I/O 오버헤드가 발생한다.

아키텍처 특성:

라우팅 방식: Direct, Fanout, Topic, Headers 등 4가지 유형
큐 복제: 클러스터 내 미러링(mirroring) 또는 Quorum Queue (3.8 이상)
지연시간: 일반적으로 1~10ms (메모리 기반)
메시지 순서: 단일 큐 내에서만 순서 보장

두 시스템을 비교하면 어떻게 되나요?

항목	Kafka	RabbitMQ
아키텍처	이벤트 스트리밍(분산 로그)	메시지 브로킹(라우팅)
처리량	초당 100만+ 메시지	초당 50만~100만 메시지
지연시간	~10ms (배치 최적화)	110ms
메시지 보존	일정 기간/용량(설정 가능)	소비 시 삭제(또는 수동 설정)
메모리 사용	메시지 크기 + 복제 인수	큐 크기에 직결
라우팅 유연성	낮음(토픽 필터링)	높음(여러 라우팅 방식)
복제 메커니즘	리더(leader)/팔로어(follower)	미러링 또는 쿼럼 큐
학습곡선	가파름(분산 개념 필수)	완만(메시지 패턴 이해)

Kafka와 RabbitMQ는 어디에 사용되나요?

Kafka 적용 분야:

실시간 이벤트 로깅 및 분석 시스템
금융 거래 데이터 스트림 처리 (초당 수백만 건)
대규모 로그 수집 및 모니터링
머신러닝 피처 엔지니어링 파이프라인

LinkedIn은 하루 1조 개 이상의 메시지를 Kafka로 처리하며, 초당 200만 메시지 이상의 처리량을 유지한다. Netflix는 Kafka를 기반으로 실시간 스트림 처리 플랫폼을 운영하고 있다.

RabbitMQ 적용 분야:

작업 큐(task queue) 기반 백그라운드 작업 처리
마이크로서비스 간 비동기 통신
복잡한 라우팅 규칙이 필요한 워크플로우
낮은 지연시간과 높은 신뢰성이 필수적인 시스템

국내 전자상거래 기업들은 RabbitMQ를 기반으로 주문 처리, 재고 관리, 알림 발송 시스템을 구축했으며, 초당 10만~50만 건의 주문 트래픽을 안정적으로 처리하고 있다.

선택 기준은 무엇인가요?

Kafka를 선택해야 할 때:

초당 수십만 개 이상의 메시지를 처리해야 함
오래된 메시지에 대한 재처리/재분석이 필요함
이벤트 소싱(event sourcing) 패턴을 적용함
실시간 스트림 처리 프레임워크(Spark, Flink)와 연동할 예정

RabbitMQ를 선택해야 할 때:

초당 수만~십만 개 메시지 처리로 충분함
복잡한 라우팅 로직이 필요함
메시지 신뢰성 및 즉시 전달이 우선
빠른 구축과 운영 난이도 낮춤이 중요함

임상 및 산업 데이터로 검증된 성능은 어떻게 되나요?

ConfluentInc의 2023 성능 벤치마크에 따르면, Kafka는 8개 브로커 클러스터 환경에서 초당 1,650만 메시지 처리를 기록했다. 메시지 크기 1KB 기준, 네트워크 처리량은 약 16.5GB/s에 도달한다. 메시지 지연시간(p99)은 약 15ms 수준이다.

RabbitMQ 벤치마크(RabbitMQ 3.12 기준)에서는 3개 노드 클러스터 환경에서 초당 120만 메시지 처리량을 달성했으며, 메시지 지연시간(p99)은 약 5ms이다. 메모리 사용량은 큐 길이에 따라 선형 증가하며, 10만 개 메시지 보관 시 약 500MB~1GB 범위이다.

신뢰성 측면에서 Kafka는 복제 인수 3 설정 시 99.99% 가용성(4개월당 약 43분 다운타임)을 보장하며, RabbitMQ의 Quorum Queue는 유사한 수준의 내결함성을 제공한다.

운영 복잡도는 어떻게 다른가요?

Kafka 운영 난이도:

파티션 리밸런싱(rebalancing) 관리
브로커 스케일링 시 데이터 재분산
컨슈머 그룹 모니터링 및 지연 추적
ZooKeeper 의존성 관리 (3.0 이상에서 개선)

일반적으로 중소 팀에서 Kafka 클러스터 운영에 필요한 전담 인력은 12명, 대규모 환경에서는 35명이다.

RabbitMQ 운영 난이도:

간단한 클러스터 설정 및 미러링 구성
웹 관리 UI(Management Plugin) 제공
토폴로지(topology) 관리 용이
메모리 알람(memory threshold) 모니터링

RabbitMQ는 운영 복잡도가 낮으므로 전담 인력 0.5~1명 수준으로 관리 가능하다.

정리하면 어떤가요?

Kafka와 RabbitMQ는 서로 다른 설계 철학을 따른다. Kafka는 대규모, 고처리량 이벤트 스트림 처리에 최적화되었으며 초당 100만 개 이상의 메시지를 안정적으로 처리할 수 있다. 반면 RabbitMQ는 유연한 메시지 라우팅과 낮은 지연시간이 장점이며, 초당 수십만~100만 개 메시지 처리에 적합하다.

기술 선택은 다음 세 가지 기준으로 판단된다: (1) 예상 메시지 처리량, (2) 라우팅 복잡도, (3) 운영 난이도와 팀 역량이다. 초당 수백만 건의 로그 수집이나 실시간 분석이 필요하면 Kafka, 낮은 지연시간과 복잡한 워크플로우가 중요하면 RabbitMQ를 선택하는 것이 일반적이다.

자주 묻는 질문

Kafka의 파티션 수는 어떻게 결정하나요?

파티션 수는 컨슈머 병렬성과 처리량을 결정하는 핵심 파라미터다. 일반적으로 다음 공식을 사용한다: 파티션 수 = (목표 처리량 MB/s) / (단일 컨슈머 처리량 MB/s). 예를 들어 목표 처리량 1,000 MB/s이고 단일 컨슈머가 100 MB/s를 처리하면 최소 10개 파티션이 필요하다. 너무 많은 파티션은 브로커 메모리 사용과 모니터링 복잡도를 증가시키므로, 일반적으로 브로커당 2,000~4,000개 파티션 범위를 권장한다.

RabbitMQ에서 메시지 유실을 방지하려면 어떻게 해야 하나요?

RabbitMQ에서 메시지 유실을 방지하려면 다음 세 가지 설정이 필수다: (1) 큐를 durable로 선언, (2) 메시지를 persistent 플래그로 발행, (3) 컨슈머에서 수신 확인(ack) 모드 활성화. Durable 큐는 브로커 재시작 후에도 메시지가 유지되며, persistent 메시지는 디스크에 기록된다. 수신 확인을 받을 때까지 메시지는 큐에서 제거되지 않으므로, 컨슈머 크래시 시에도 메시지 손실이 발생하지 않는다.

Kafka와 RabbitMQ를 함께 사용할 수 있나요?

기술적으로 가능하지만 권장되지 않는다. 두 시스템의 메시지 모델과 전송 보장 방식이 다르므로, 메시지 복제 및 순서 보장에 복잡성이 증가한다. 필요한 경우 Kafka 컨슈머에서 메시지를 가져와 RabbitMQ 프로듀서로 전달하거나, 별도의 메시지 변환 레이어(예: Kafka Connect)를 구성하는 방식을 사용한다. 일반적으로 하나의 시스템으로 통일하는 것이 운영 효율성 측면에서 더 낫다.

메시지 큐 시스템의 비용은 어떻게 비교하나요?

Kafka와 RabbitMQ는 오픈소스이므로 라이선스 비용이 없으나, 인프라 비용이 다르다. Kafka는 일반적으로 더 많은 디스크 공간(메시지 보관)과 네트워크 대역폭을 소비하므로, 장기적 운영 비용이 높을 수 있다. RabbitMQ는 메모리 집약적이므로 RAM 비용이 더 클 수 있다. 클라우드 환경(AWS, Azure, GCP)에서는 관리형 서비스를 이용할 수 있으며, Kafka는 AWS MSK(Managed Streaming for Apache Kafka), RabbitMQ는 AWS MQ 서비스로 제공된다. 월 비용은 처리량과 보관 기간에 따라 수천~수십만 원 범위이다.