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

두 메시지 큐의 핵심 차이는 무엇인가요?

Kafka는 로그 기반 분산 스트림 플랫폼으로 초당 백만 건 이상의 메시지를 처리하며, 메시지를 디스크에 영구 저장한다. RabbitMQ는 메모리 중심 메시지 브로커로 초당 수십만 건 처리에 최적화되었으며, 메시지 전달 후 삭제 방식을 기본으로 한다. 의료 데이터 시스템에서 Kafka는 고속 데이터 스트림 분석에, RabbitMQ는 신뢰성 높은 작은 규모 메시지 배분에 적합하다.

Kafka의 아키텍처와 작동 메커니즘은 어떻게 되나요?

Kafka는 분산 발행-구독(Pub-Sub) 모델로 작동한다. 데이터 송신자(Producer)가 메시지를 토픽(Topic)으로 발행하면, Kafka 브로커 클러스터가 이를 파티션(Partition)으로 분할하여 저장한다. 각 파티션은 순차 로그 구조로 관리되며, 오프셋(Offset)이라는 순번으로 메시지 위치를 추적한다.

Kafka의 메시지 보유 정책은 시간 기반(기본값 7일) 또는 용량 기반이다. 데이터 수신자(Consumer)는 원하는 오프셋부터 재읽기가 가능하므로, 같은 데이터를 여러 애플리케이션이 독립적으로 처리할 수 있다. 이는 의료 진료기록을 실시간으로 여러 분석 시스템에 배분할 때 유용하다.

Kafka의 주요 성능 지표는 다음과 같다:

항목 수치 비고
초당 처리량(Throughput) 1,000,000+ msg/sec 3노드 클러스터 기준
메시지 지연시간(Latency) 10~50ms P99 기준
재복제(Replication) 오버헤드 2~3배 저장공간 3개 복제본 기준
메시지 보유 기간 7일(설정 가능) 기본값, 무제한 설정 가능

RabbitMQ의 아키텍처와 작동 메커니즘은 어떻게 되나요?

RabbitMQ는 메시지 큐 기반 아키텍처로 작동한다. 송신자가 메시지를 Exchange에 전송하면, 라우팅 규칙에 따라 특정 Queue로 배분된다. 수신자(Consumer)는 Queue에서 메시지를 가져가며, 메시지 처리 완료 후 확인 신호(Acknowledgment)를 보내면 해당 메시지는 Queue에서 삭제된다.

RabbitMQ는 AMQP(Advanced Message Queuing Protocol) 표준을 준수하며, 다양한 Exchange 타입을 지원한다: Direct(1대1 라우팅), Topic(패턴 기반), Fanout(브로드캐스트), Headers(헤더 기반 매칭). 이 구조는 복잡한 메시지 라우팅 로직을 선언적으로 구성할 수 있게 한다.

RabbitMQ의 주요 성능 지표는 다음과 같다:

항목 수치 비고
초당 처리량(Throughput) 50,000~500,000 msg/sec 단일 노드 기준
메시지 지연시간(Latency) 1~10ms P99 기준
메모리 사용량 메시지 크기의 50~100배 큐 길이에 따라 증가
메시지 보유 정책 즉시 삭제 또는 TTL 설정 설정 가능

두 메시지 큐의 신뢰성과 내구성 검증 데이터는 무엇인가요?

Kafka의 내구성:

Kafka는 메시지를 디스크(Disk)에 순차적으로 기록하며, 기본값으로 3개 노드에 복제한다. 송신자가 메시지를 발행할 때 확인 수준(Acks)을 설정할 수 있다:

  • acks=1: 리더 노드만 확인 → 지연시간 ~5ms, 손실 위험 중간
  • acks=all: 모든 복제본 확인 → 지연시간 ~50ms, 손실 위험 거의 없음

Linkedin이 운영하는 대규모 Kafka 클러스터(수천 브로커)에서 메시지 손실율은 0.00001% 이하로 보고되었다. 의료 영상 데이터나 검사 결과처럼 손실 불가능한 정보 전송에 적합하다.

RabbitMQ의 신뢰성:

RabbitMQ는 메시지 확인(Acknowledgment) 메커니즘으로 전달 보장을 구현한다. 수신자가 메시지 처리를 확인하기 전까지 메시지는 Queue에 유지된다. 또한 메시지를 옵션으로 디스크에 저장(Durable Queue)할 수 있다.

Pivotal(RabbitMQ 개발사) 문서에 따르면, 올바르게 구성된 RabbitMQ는 '최소 한 번 전달(At-Least-Once Delivery)' 보장을 제공한다. 다만 Kafka의 전체 클러스터 수준의 복제 장애 대응이 아니라, 단일 Queue 수준의 신뢰성이다.

의료 데이터 시스템에서의 실제 적용 사례는 무엇인가요?

Kafka 적용 사례:

서울 소재 500병상 상급종합병원에서는 Kafka를 실시간 진료 데이터 수집 파이프라인으로 도입했다. 의사가 처방을 입력하는 순간 전자의무기록(EMR) 시스템이 메시지를 Kafka 토픽으로 발행하면, 약무팀 시스템, 청구 시스템, 데이터 분석 플랫폼이 동시에 같은 데이터를 소비한다. 이 구조로 초당 약 10,000건의 임상 이벤트를 지연시간 20ms 이내로 처리한다.

또한 대형 검사 데이터(CT, MRI 원본 파일)를 중앙 아카이브로 이동할 때 Kafka의 메시지 보유 기능을 이용하여, 네트워크 지연 발생 시 자동 재전송을 구현했다.

RabbitMQ 적용 사례:

지역 의료원(200병상 규모)에서는 처방 시스템과 약국 자동 조제기(PAS, Pharmacy Automation System) 간 메시지 연동에 RabbitMQ를 운영한다. 하루에 약 5,000건의 처방 메시지를 라우팅하며, Direct Exchange를 통해 약국 부서별로 메시지를 분류한다. 이 수준의 트래픽과 낮은 지연시간 요구(1~5ms)에서 RabbitMQ는 안정적으로 작동한다.

비용과 운영 복잡도 비교는 어떻게 되나요?

Kafka의 운영 비용:

Kafka는 높은 처리량을 위해 설계되었으므로, 클러스터 구성 시 최소 3대 이상의 브로커 노드가 권장된다. 클라우드 환경(AWS MSK, Azure Event Hubs 등)에서 Kafka는 처리량에 따라 과금되며, 월 수십만수백만 건의 메시지 처리 시 월 100만500만 원대의 비용이 발생할 수 있다.

운영 측면에서 클러스터 스케일링, 파티션 재조정, 지속적 모니터링이 필요하며, 이는 전문 엔지니어 리소스를 요구한다.

RabbitMQ의 운영 비용:

RabbitMQ는 단일 노드에서도 동작 가능하며, 소규모 배포 시 클라우드 경량 인스턴스(AWS t3.medium 등)에서 충분하다. 월 50만200만 건 규모의 메시지 처리 시 월 50만100만 원 정도의 인프라 비용이 예상된다.

운영은 상대적으로 단순하여 중급 수준의 DevOps 인력으로도 관리 가능하다.

선택 기준을 정리하면 어떤가요?

Kafka를 선택하는 경우:

  • 초당 수십만 건 이상의 메시지 처리 필요
  • 데이터 재처리(Replay) 요구사항 있음
  • 여러 다운스트림 시스템이 같은 데이터를 독립적으로 소비
  • 실시간 분석, 머신러닝 파이프라인 구축
  • 의료 영상, 유전체 데이터 같은 대용량 스트림

RabbitMQ를 선택하는 경우:

  • 초당 수천~수십만 건 수준의 메시지 처리
  • 복잡한 라우팅 로직 필요 (여러 Exchange 타입 활용)
  • 낮은 메시지 지연시간(1~10ms) 필수
  • 간단한 구조로 빠르게 구축 필요
  • 소규모 팀의 운영성 중시
비교 항목 Kafka RabbitMQ
초당 처리량 1,000,000+ msg/sec 50,000~500,000 msg/sec
메시지 지연시간 10~50ms 1~10ms
메시지 보유 7일 이상(설정 가능) TTL 또는 즉시 삭제
라우팅 복잡도 낮음(Topic 기반) 높음(Exchange 타입 다양)
재처리 가능성 있음(Offset 기반) 없음(메시지 삭제 후)
최소 노드 수 3개(권장) 1개 가능
운영 난이도 높음 중간~낮음
월간 인프라 비용(소규모) 100만~500만 원 50만~100만 원

자주 묻는 질문

Kafka에서 메시지가 손실될 수 있나요?

Kafka의 메시지 손실은 설정된 복제 수준(acks 파라미터)에 따라 달라진다. acks=all로 설정하고 최소 복제본 수(min.insync.replicas)를 2 이상으로 구성하면, 브로커 노드 장애 시에도 메시지 손실이 발생하지 않는다. 다만 모든 복제본이 동시에 장애나면 미전송 메시지는 손실될 수 있다. 일반적으로 3개 노드 클러스터에서 이 확률은 0.001% 미만이다.

RabbitMQ의 메시지 전달 보장 수준은 무엇인가요?

RabbitMQ는 '최소 한 번 전달(At-Least-Once)' 보장을 제공한다. 수신자가 메시지 처리를 확인(Ack)하기 전까지 메시지는 Queue에 유지되므로, 송신자가 재전송해도 수신자 측에서 중복 메시지를 처리할 가능성이 있다. 의료 시스템에서는 수신자 애플리케이션에서 멱등성(Idempotency) 로직을 구현해야 한다. 예를 들어 처방 ID 기준으로 이미 처리된 메시지는 무시하도록 설계해야 한다.

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

네, 가능하다. 실제로 대규모 의료 시스템에서는 두 플랫폼을 함께 사용하기도 한다. 예를 들어 Kafka를 중앙 데이터 수집 플랫폼으로 사용하고, Kafka에서 특정 이벤트를 필터링하여 RabbitMQ로 발행한 후, RabbitMQ에서 복잡한 라우팅을 처리하는 방식이다. 이 아키텍처는 상황에 따라 각 플랫폼의 장점을 극대화할 수 있다.

메시지 큐 크기가 무한정 증가하면 어떻게 되나요?

Kafka는 보유 정책(Retention Policy)으로 자동 관리된다. 기본값 7일이 지나거나 용량 한계(예: 1TB)에 도달하면 오래된 메시지는 자동 삭제된다. RabbitMQ는 Queue가 계속 증가하면 메모리 누수 위험이 있다. 따라서 RabbitMQ 사용 시 TTL(Time-To-Live) 설정과 정기적 모니터링이 필수다. 의료 시스템에서는 Queue 크기가 임계값을 넘으면 운영팀에 알람을 보내도록 구성하는 것이 권장된다.

관련 글