Kafka vs RabbitMQ — 메시지 큐 시스템 기술 비교

두 시스템의 근본적 설계 목표는 무엇이 다른가요?

Kafka는 초당 수백만 건의 메시지 처리를 목표로 설계된 로그 기반 메시지 큐이며, RabbitMQ는 안정적인 메시지 전달을 중심으로 설계된 범용 메시지 브로커입니다. Kafka는 메시지를 디스크에 순차 기록하는 append-only log 구조를 사용하고, RabbitMQ는 메시지를 메모리와 디스크에 저장하는 큐 기반 구조를 사용합니다. 따라서 처리량 요구가 높은 시스템에는 Kafka가, 신뢰성 있는 1회 전달(exactly-once delivery)이 필요한 시스템에는 RabbitMQ가 적합합니다.

Kafka의 기술적 작동 메커니즘은 어떻게 되나요?

Kafka는 분산 메시지 플랫폼으로, 생산자(Producer)에서 발생한 데이터를 Topic이라는 논리적 채널로 수집합니다. 각 Topic은 여러 Partition으로 분할되며, 각 Partition은 Broker 노드에 저장됩니다. Partition 내 메시지는 Offset이라는 일련번호가 부여되어 순서가 보장됩니다. 소비자(Consumer)는 특정 Offset부터 메시지를 읽으므로, 메시지 손실 없이 재처리가 가능합니다.

Kafka의 기본 성능 스펙

  • 처리량: 단일 Broker당 초당 100만~300만 메시지 처리 (메시지 크기 1KB 기준)
  • 지연시간(Latency): 중앙값 10ms 이하 (내부 네트워크)
  • 메시지 보관 기간: 기본 7일, 디스크 용량에 따라 무제한 설정 가능
  • 복제 인자(Replication Factor): 기본값 3 (3개 Broker에 중복 저장)
  • Partition 수: 일반적으로 데이터 처리량 기준 Consumer 수와 동일하게 설정

Kafka의 내구성 메커니즘

Kafka는 In-Sync Replica(ISR) 개념을 사용합니다. Producer가 메시지를 전송할 때 acks 파라미터를 설정하면, 1개 이상의 Replica가 메시지를 수신했을 때만 전송 성공으로 인정합니다. acks=all 설정 시 모든 ISR Replica에 기록되어야 성공으로 처리되며, 이 경우 메시지 손실 위험은 거의 0입니다. 다만 지연시간은 5~20ms 증가합니다.

RabbitMQ의 기술적 작동 메커니즘은 어떻게 되나요?

RabbitMQ는 AMQP(Advanced Message Queuing Protocol) 기반 메시지 브로커입니다. Producer가 메시지를 Exchange로 전송하면, Exchange는 라우팅 규칙(Binding)에 따라 메시지를 Queue에 전달합니다. 각 Queue는 Consumer가 처리할 때까지 메시지를 메모리에 보관하며, 선택적으로 디스크에도 저장합니다.

RabbitMQ의 기본 성능 스펙

  • 처리량: 단일 노드당 초당 50만~150만 메시지 처리 (메시지 크기 1KB 기준)
  • 지연시간(Latency): 중앙값 20~50ms (내부 네트워크)
  • 메모리 사용량: Queue 길이와 메시지 크기의 곱에 비례
  • 디스크 동기화: Durable Queue 설정 시 모든 메시지가 디스크에 기록
  • 클러스터링: 최대 권장 노드 수 5~7개

RabbitMQ의 내구성 메커니즘

RabbitMQ는 Publisher Confirm과 Consumer Acknowledgment 개념을 사용합니다. Producer는 Broker에서 메시지 수신을 명시적으로 확인받으며, Consumer는 메시지 처리 완료 후 Broker에 확인(ACK)을 전송합니다. Broker는 ACK를 받아야만 Queue에서 메시지를 제거합니다. 따라서 Consumer 처리 실패 시 메시지는 Queue에 남아 재처리됩니다.

두 시스템의 기술 스펙 비교는 어떻게 되나요?

항목 Kafka RabbitMQ
아키텍처 Log 기반 분산 스트림 플랫폼 Queue 기반 메시지 브로커
초당 처리량 (1KB 메시지) 100만~300만 50만~150만
평균 지연시간 5~15ms 20~50ms
메모리 효율성 우수 (로그만 메모리에 유지) 중간 (Queue 길이에 의존)
메시지 순서 보장 Partition 단위로 보장 Queue 단위로 보장
메시지 재처리 용이 (Offset으로 접근) 제한적 (Queue 구조상 불리)
클러스터 확장성 매우 우수 (수백 개 Broker) 중간 (5~7개 노드 권장)
메시지 TTL(Time To Live) 시간 기반 또는 크기 기반 메시지별 또는 Queue별 설정
운영 복잡도 높음 (튜닝 파라미터 많음) 낮음 (기본 설정으로도 안정적)
라이센스 Apache 2.0 (오픈소스) Mozilla Public License (오픈소스)

의료 데이터 시스템에서 실제 적용 사례는 어떻게 되나요?

Kafka 적용 사례: 다중 병원 통합 의료 데이터 수집

대규모 의료 네트워크에서는 Kafka를 사용하여 여러 병원의 전자의무기록(EHR) 데이터, 의료 이미징 메타데이터, 실시간 모니터링 신호를 중앙 시스템으로 수집합니다. 예를 들어 초당 500,000건의 생체신호(심전도, 혈산소포화도, 혈압) 데이터를 수십 개 병원에서 동시 수집할 때, Kafka의 높은 처리량과 확장성이 필수적입니다. 각 병원은 개별 Partition을 할당받아 데이터를 전송하고, 중앙 분석 시스템은 Topic에서 병렬로 데이터를 읽어 실시간 이상 탐지를 수행합니다.

RabbitMQ 적용 사례: 병원 내부 작업 흐름 자동화

단일 병원의 진료 예약 시스템, 검사실 검사 결과 전달, 약물 배약 자동화 등 중요도 높은 작업에는 RabbitMQ를 사용합니다. 예를 들어 의사의 처방이 입력되면 이를 RabbitMQ Queue에 저장한 후, 약국 자동 배약 시스템이 순차적으로 처리합니다. Publisher Confirm과 Consumer ACK를 통해 약물 배약 누락이 발생하지 않도록 보장합니다. 처리량이 시간당 수천~수만 건 수준이므로 RabbitMQ의 낮은 운영 복잡도가 이점입니다.

선택 기준을 정리하면 무엇인가요?

Kafka 선택 기준:

  • 초당 메시지 처리량이 100만 건 이상
  • 메시지 재처리 또는 과거 데이터 재분석이 필요
  • 여러 Consumer 그룹이 동일 Topic을 다목적으로 소비
  • 대규모 분산 시스템(수십 개 이상 노드)

RabbitMQ 선택 기준:

  • 초당 메시지 처리량이 50만~150만 건
  • 메시지 1회 전달이 중요한 작업(exactly-once delivery)
  • 복잡한 라우팅 규칙 필요
  • 운영 팀의 Kafka 튜닝 경험 부족

자주 묻는 질문

Kafka에서 메시지 손실이 발생할 수 있나요?

Kafka는 기본 설정(acks=1)에서 Leader Broker만 메시지 수신을 확인한 후 Producer에 응답합니다. 이 경우 Leader 노드 장애 시 아직 Replica에 복제되지 않은 메시지는 손실될 수 있습니다. 메시지 손실을 방지하려면 acks=all, min.insync.replicas=2 이상으로 설정하여 최소 2개 Replica에 기록되도록 해야 합니다. 이 경우 메시지 손실 위험은 0.01% 이하로 감소합니다.

RabbitMQ는 메시지 손실 위험이 없나요?

RabbitMQ도 기본 설정에서는 메시지 손실 위험이 있습니다. 메시지가 메모리에만 저장되고 있다가 Broker 장애 발생 시 손실됩니다. 손실 방지를 위해서는 Queue를 Durable로 설정하고, Producer는 Publisher Confirm을 활성화, Consumer는 명시적 ACK를 보내도록 구성해야 합니다. 이 경우 메시지 손실 위험은 거의 0에 가까워집니다.

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

네, 가능합니다. 실무에서는 Kafka를 고처리량 데이터 수집 계층으로, RabbitMQ를 중요한 작업 흐름 자동화 계층으로 활용하는 하이브리드 구조를 채택하기도 합니다. 예를 들어 병원에서 초당 수만 건의 생체신호는 Kafka로 수집하고, 의사 처방 데이터는 RabbitMQ로 전달하는 방식입니다. 다만 두 시스템의 모니터링, 장애 대응이 복잡해지므로 운영 팀의 규모가 충분할 때만 권장됩니다.

클라우드 환경에서는 어느 것이 더 적합한가요?

AWS, Azure, GCP 등 주요 클라우드는 Kafka와 RabbitMQ 관리형 서비스(Managed Service)를 제공합니다. AWS의 Amazon MSK(Managed Streaming for Kafka)는 Kafka 클러스터를 자동 구축·확장하며, Azure Service Bus와 RabbitMQ 관리형 서비스도 존재합니다. 클라우드 환경에서는 두 시스템 모두 쉽게 배포 가능하며, 초기 비용(하드웨어 구입)은 발생하지 않습니다. 다만 월간 데이터 처리량에 따라 요금이 결정되므로, 처리량 예측이 중요합니다.

오픈소스 버전과 상용 버전의 차이는 무엇인가요?

Kafka와 RabbitMQ는 모두 Apache 2.0 또는 Mozilla 라이센스의 완전 오픈소스이므로, 상용 버전은 존재하지 않습니다. 다만 Confluent사는 Kafka를 기반으로 Schema Registry, Kafka Connect, Control Center 등의 부가 기능을 포함한 Confluent Platform을 유료로 제공합니다. RabbitMQ는 VMware에서 지원하지만, 핵심 기능은 오픈소스로 무료로 사용할 수 있습니다.

관련 글