[Kafka 초보자 가이드 Ep.02] 메시지 큐와 Kafka의 차이점

이 글에서는 전통적인 메시지 큐(RabbitMQ, ActiveMQ 등)와 Apache Kafka 간의 핵심적인 차이점을 살펴봅니다. 아키텍처, 성능, 활용 사례, 데이터 처리 방식 등 여러 측면에서 두 시스템을 비교하여 각각 어떤 상황에서 더 적합한지 이해할 수 있도록 도와드립니다.

---

📌 메시지 큐와 Kafka: 개념 비교

메시지 큐와 Kafka는 모두 애플리케이션 간 비동기 통신을 지원하는 미들웨어지만, 근본적인 설계 철학과 목적에 차이가 있습니다.

 

✅ 메시지 큐(Message Queue)란?

• 애플리케이션 간 메시지를 전달하는 중간 저장소 역할
• 주로 작업 부하 분산, 비동기 처리, 시스템 간 결합도 감소를 위해 설계
• AMQP(Advanced Message Queuing Protocol)와 같은 표준 프로토콜 기반
• 대표적 구현체: RabbitMQ, ActiveMQ, IBM MQ, Amazon SQS

✅ Kafka란?

• 분산 이벤트 스트리밍 플랫폼으로 설계
• 높은 처리량의 실시간 데이터 파이프라인 구축 목적
• 자체 프로토콜로 구현되며 분산 커밋 로그 아키텍처 채택
• LinkedIn에서 개발, 현재는 Apache 프로젝트로 발전

✅ 근본적인 차이점

• 메시지 큐: 메시지를 소비하면 큐에서 제거(일회성 소비 모델)
• Kafka: 메시지(이벤트)를 로그에 추가하며 소비 후에도 데이터 유지(로그 기반 모델)

▶️ 설계 목적의 차이

메시지 큐: "작업을 다른 시스템에 위임하고 부하를 분산한다"
Kafka: "데이터의 흐름을 중앙화하고 다양한 시스템이 접근할 수 있게 한다"

---

📌 아키텍처 차이점 비교

메시지 큐와 Kafka는 메시지 저장 및 전달 방식에서 근본적인 아키텍처 차이를 보입니다.

✅ 메시지 큐 아키텍처

• Exchange와 Queue: 메시지는 Exchange를 통해 Queue로 라우팅됨
• Point-to-Point: 하나의 메시지는 하나의 소비자만 처리 가능
• Publish-Subscribe: 토픽 구독 모델로 여러 소비자에게 메시지 복제 가능
• Push 기반: 브로커가 소비자에게 메시지를 적극적으로 전달
• 단일 노드 또는 클러스터: 주로 Active-Passive 구성의 장애 대응

✅ Kafka 아키텍처

• 토픽과 파티션: 토픽은 여러 파티션으로 분할되어 병렬 처리 가능
• Producer-Consumer: 모든 메시지는 항상 토픽에 기록되고 소비자는 자유롭게 소비
• Pull 기반: 소비자가 브로커로부터 능동적으로 메시지를 가져감
• 분산 커밋 로그: 추가 전용(append-only) 로그 구조로 순차적 읽기/쓰기에 최적화
• 수평적 확장: 브로커 추가만으로 선형적 성능 향상 가능

메시지 큐와 Kafka의 아키텍처 차이

 

✅ 토폴로지 비교

• 메시지 큐: 복잡한 라우팅 규칙 지원, 메시지 변환, 필터링 등 다양한 패턴 적용 가능
• Kafka: 단순한 파티션 기반 라우팅으로 확장성과 처리량 극대화

✅ 데이터 지속성 처리

• 메시지 큐: 메모리 중심, 필요에 따라 디스크에 저장
• Kafka: 기본적으로 디스크 저장, 순차적 I/O와 페이지 캐시 활용으로 성능 최적화

▶️ 복제 및 장애 복구 모델

• 메시지 큐:

  - 주로 Master-Slave 구성으로 장애 시 Slave가 인계- 개별 메시지 수준의 승인 및 복구 메커니즘
  

• Kafka:

  - 파티션 단위의 복제 모델(리더-팔로워 구조)- ISR(In-Sync Replicas) 그룹을 통한 데이터 일관성 보장- 자동화된 리더 선출 메커니즘
  

---

📌 성능 및 확장성 비교

메시지 처리량, 지연 시간, 확장성 측면에서 두 시스템은 뚜렷한 차이를 보입니다.

 

✅ 처리량(Throughput)

• 메시지 큐: 초당 수천~수만 건 처리 (시스템 구성에 따라 다름)
• Kafka: 초당 수백만 건 이상 처리 가능 (대용량 처리에 최적화)

✅ 지연 시간(Latency)

• 메시지 큐: 밀리초 단위의 낮은 지연 시간 제공 (실시간 작업에 적합)
• Kafka: 일반적으로 10ms 이상, 처리량 최적화로 약간 높은 지연 시간

✅ 확장 모델

• 메시지 큐:
  • 수직적 확장(Scale-up) 경향
  • 복잡한 라우팅 로직으로 인한 확장 제한
  • 클러스터 노드 추가 시 선형적 성능 향상이 어려움
• Kafka:
  • 수평적 확장(Scale-out) 중심
  • 브로커 및 파티션 추가로 거의 선형적 성능 확장
  • ZooKeeper(또는 KRaft) 기반 클러스터 조정

✅ 대규모 배포 비교

• 메시지 큐: 일반적으로 수~수십 노드 규모
• Kafka: 수백 노드 규모의 대형 클러스터 운영 사례 다수

▶️ 벤치마크 예시

메시지 큐(RabbitMQ) 기준:
- 단일 큐: ~20,000 메시지/초
- 클러스터(3노드): ~50,000 메시지/초

Kafka 기준:
- 단일 브로커(3파티션): ~100,000 메시지/초
- 클러스터(3브로커, 15파티션): ~1,000,000 메시지/초 이상

---

📌 메시지 소비 패턴 비교

메시지가 소비되는 방식과 메시지 생명주기 관리에 큰 차이가 있습니다.

 

✅ 메시지 소비 모델

• 메시지 큐:
  • 소비 시 메시지 삭제(Consume and Delete)
  • 한 메시지는 기본적으로 하나의 소비자만 처리
  • 작업 큐(Work Queue) 패턴으로 부하 분산
• Kafka:
  • 소비 후에도 메시지 유지(Retain after Consume)
  • 여러 소비자 그룹이 독립적으로 같은 데이터 소비 가능
  • 오프셋(Offset) 기반 소비 위치 추적

✅ 메시지 순서 보장

• 메시지 큐: 단일 큐 내에서 엄격한 FIFO(First-In-First-Out) 순서 보장
• Kafka: 파티션 내에서만 순서 보장, 파티션 간에는 순서 보장 없음

✅ 소비자 그룹 동작

• 메시지 큐:
  • 컴피팅 컨슈머(Competing Consumers) 패턴: 동일 큐에서 소비자들이 메시지 분배
  • 메시지별 명시적 확인(Ack)으로 처리 완료 표시
• Kafka:
  • 소비자 그룹 내 파티션 자동 할당
  • 소비자가 파티션의 오프셋을 관리하며 자유롭게 위치 이동 가능
  • 배치 처리 최적화로 높은 처리량 달성

✅ 재처리 메커니즘

• 메시지 큐:
  • 실패 시 Dead Letter Queue로 이동
  • 명시적인 메시지 거부(Nack)로 재처리 요청 가능
• Kafka:
  • 오프셋 재설정으로 언제든 과거 데이터 재처리 가능
  • 소비자 책임 하에 오프셋 관리 및 커밋

메시지 큐와 Kafka 메시지 소비 패턴 비교

---

📌 데이터 보존 및 처리 보장 비교

데이터를 얼마나 오래 보존하는지, 그리고 메시지 전달을 어떻게 보장하는지에 차이가 있습니다.

 

✅ 데이터 보존 정책

• 메시지 큐:
  • 기본적으로 소비 후 즉시 삭제
  • 필요 시 TTL(Time To Live) 설정으로 짧은 기간 보존 가능
  • 메모리 중심 설계로 장기 보존에 부적합
• Kafka:
  • 기본 보존 기간 7일 (설정 변경 가능)
  • 시간 또는 크기 기반 보존 정책 지원
  • 로그 로테이션으로 오래된 데이터 자동 삭제
  • 장기 보존(수개월/수년)도 가능한 설계

✅ 전달 보장(Delivery Guarantees)

• 메시지 큐:
  • at-most-once: 메시지가 최대 한 번 전달 (소비자 확인 없이 메시지 삭제)
  • at-least-once: 메시지가 최소 한 번 전달 (소비자 확인 필요, 중복 가능)
  • exactly-once: 메시지 정확히 한 번 전달 (트랜잭션 기능으로 구현)
• Kafka:
  • at-most-once: 메시지 발행 후 확인하지 않음 (acks=0)
  • at-least-once: 메시지 발행 확인 (acks=1 또는 acks=all)
  • exactly-once: 트랜잭션 API 활용 (Kafka 0.11 이상)

✅ 데이터 내구성(Durability)

• 메시지 큐:
  • 내구성은 디스크 저장 여부와 복제 구성에 의존
  • 메모리 중심 설계로 장애 시 일부 데이터 손실 가능성
• Kafka:
  • 모든 메시지는 커밋 로그에 기록되어 높은 내구성 제공
  • 복제 인자(replication factor)로 내구성 수준 조절
  • ISR(In-Sync Replicas) 메커니즘으로 데이터 일관성 유지

▶️ 데이터 보존 활용 사례

메시지 큐: 주문 처리 시스템에서 결제 서비스로 작업 위임, 처리 완료 후 메시지 삭제

Kafka: 사용자 행동 로그를 30일간 보존하며 다양한 분석 서비스가 독립적으로 접근

---

📌 적합한 활용 사례 비교

각 시스템이 가진 특성으로 인해 더 적합한 활용 사례가 다릅니다.

 

✅ 메시지 큐에 적합한 사례

• 작업 큐(Task Queue): 백그라운드 작업 분산 처리
• 마이크로서비스 간 비동기 통신: 요청-응답 패턴, RPC 대체
• 분산 트랜잭션 처리: 2단계 커밋, 사가(Saga) 패턴 구현
• 필요한 기능:
  • 복잡한 라우팅 규칙
  • 메시지 우선순위 지정
  • 낮은 지연 시간 필요
  • 정확히 한 번(exactly-once) 처리 요구

✅ Kafka에 적합한 사례

• 로그 수집 및 분석: 애플리케이션, 시스템 로그 중앙화
• 이벤트 소싱(Event Sourcing): 상태 변경을 이벤트 시퀀스로 저장
• 스트림 처리: 실시간 데이터 처리, CEP(Complex Event Processing)
• 데이터 파이프라인: 다양한 시스템 간 데이터 통합
• 필요한 기능:
  • 높은 처리량 요구
  • 데이터 재생(replay) 기능
  • 다중 소비자 지원
  • 장기간 데이터 보존

✅ 하이브리드 활용 사례

• Kafka를 백본으로, 메시지 큐를 엔드포인트로 사용
  • Kafka로 대용량 데이터 수집 및 중앙화
  • 특정 처리를 위해 메시지 큐로 데이터 라우팅
• 이벤트 기반 아키텍처에서 상호 보완
  • Kafka: 이벤트 저장 및 배포
  • 메시지 큐: 특정 소비자를 위한 작업 큐 역할

▶️ 선택 가이드라인

메시지 큐 선택 시나리오:
- 작업의 지연 없는 처리가 중요할 때
- 복잡한 라우팅이 필요할 때
- 메시지별 처리 보장이 중요할 때

Kafka 선택 시나리오:
- 대용량 데이터 처리가 필요할 때
- 여러 시스템이 동일 데이터에 접근해야 할 때
- 이벤트 이력 보존이 중요할 때
- 확장성이 주요 요구사항일 때

---

📌 RabbitMQ vs Kafka: 구체적 비교

가장 많이 사용되는 메시지 큐 시스템인 RabbitMQ와 Kafka를 직접 비교해 보겠습니다.

 

RabbitMQ vs Kafka 구체적 비교

 

✅ 기본 개념 비교

• RabbitMQ:
  • AMQP 기반의 메시지 브로커
  • Exchange, Queue, Binding 개념 중심
  • 다양한 Exchange 타입(Direct, Topic, Fanout, Headers)
• Kafka:
  • 분산 커밋 로그 시스템
  • Topic, Partition, Segment 개념 중심
  • Producer, Consumer, Consumer Group 구조

✅ 성능 지표 비교

비교 항목	RabbitMQ	Kafka
최대 처리량	중간 (수만 msg/s)	높음 (수백만 msg/s)
지연 시간	낮음 (~ms)	상대적으로 높음 (10ms+)
메시지 크기	제한 없음 (실질적으로 수 MB)	기본 1MB 제한 (조정 가능)
클러스터 크기	소~중규모 (10대 미만)	대규모 (수백대)

 

✅ 기능 비교

기능	RabbitMQ	Kafka
메시지 라우팅	매우 유연한 라우팅	파티션 키 기반 단순 라우팅
프로토콜 지원	다중 프로토콜(AMQP, MQTT, STOMP)	자체 바이너리 프로토콜
메시지 우선순위	지원	미지원
메시지 TTL	지원	토픽 단위 보존 정책
관리 UI	내장 관리 콘솔	외부 도구 필요 (Confluent Control Center, Kafdrop 등)
플러그인 시스템	다양한 플러그인 생태계	Kafka Connect 프레임워크

 

✅ 운영 측면 비교

• RabbitMQ:
  • Erlang/OTP 기반으로 높은 안정성
  • 상대적으로 적은 시스템 리소스 요구
  • 간편한 설치 및 구성
  • 작은 규모에서 시작하기 용이
• Kafka:
  • Java/Scala 기반, JVM 튜닝 중요
  • 높은 디스크 I/O 및 메모리 요구
  • ZooKeeper(또는 KRaft) 별도 구성 필요
  • 설정 복잡성이 상대적으로 높음

▶️ 실제 대규모 사용자 사례

RabbitMQ:
- CloudAMQP: 클라우드 기반 RabbitMQ 서비스
- Mozilla: Firefox Sync 서비스에 활용
- T-Mobile: 메시징 백엔드로 활용

Kafka:
- Netflix: 실시간 스트리밍 분석
- LinkedIn: 활동 추적 및 메트릭 수집
- Uber: 승객-운전자 매칭 시스템
- PayPal: 실시간 사기 탐지 시스템

---

📌 ActiveMQ vs Kafka: 구체적 비교

또 다른 유명한 메시지 큐 시스템인 ActiveMQ와 Kafka를 비교해 보겠습니다.

 

✅ 기본 개념 비교

• ActiveMQ:
  • JMS(Java Message Service) 구현체
  • Queue와 Topic 모델 제공
  • 다양한 전송 프로토콜 지원
• Kafka:
  • 이벤트 스트리밍 플랫폼
  • 파티션된 로그 구조
  • 단일 바이너리 프로토콜 사용

✅ 아키텍처 비교

• ActiveMQ:
  • 전통적인 JMS 브로커 아키텍처
  • 메시지 저장소로 KahaDB 또는 JDBC 사용
  • Master-Slave 복제 모델
• ActiveMQ Artemis(차세대 ActiveMQ):
  • 비공유(shared-nothing) 분산 아키텍처
  • 비동기 I/O 모델로 성능 향상
• Kafka:
  • 분산 커밋 로그 아키텍처
  • 토픽 파티션 기반 병렬 처리
  • 리더-팔로워 복제 모델

✅ 기능 비교

기능	ActiveMQ	Kafka
메시지 모델	JMS 표준(Queue/Topic)	로그 기반 토픽
트랜잭션	JMS 트랜잭션 지원	Producer/Consumer 트랜잭션
메시지 필터링	선택자(Selector) 기반 필터링	클라이언트 측 필터링만 가능
메시지 변환	메시지 변환 지원	별도 처리 필요(Kafka Streams 등)
브라우저 지원	STOMP, WebSocket 통합	자체 지원 없음(별도 프록시 필요)

 

✅ 성능과 확장성 비교

• ActiveMQ:
  • 중간 규모의 처리량(초당 수천~수만 메시지)
  • 수직적 확장 중심
  • 복잡한 기능으로 인한 오버헤드 존재
• ActiveMQ Artemis:
  • 향상된 처리량(초당 수십만 메시지 가능)
  • 네트워크 I/O 최적화
• Kafka:
  • 매우 높은 처리량(초당 수백만 메시지)
  • 수평적 확장 용이
  • 단순한 기능으로 성능 최적화

▶️ 선택 가이드라인

ActiveMQ 선택 시나리오:
- JMS 표준 호환성이 필요할 때
- 다양한 메시징 패턴이 필요할 때
- 기존 Java 엔터프라이즈 환경과 통합할 때

Kafka 선택 시나리오:
- 대규모 데이터 스트림 처리가 필요할 때
- 높은 처리량이 중요한 요구사항일 때
- 이벤트 기반 아키텍처 구축 시

---

📌 Summary

• 메시지 큐와 Kafka는 근본적인 아키텍처와 설계 목적에 차이가 있으며, 각각 적합한 사용 사례가 다릅니다.
• 메시지 큐는 소비 후 메시지가 삭제되는 반면, Kafka는 설정된 기간 동안 메시지를 보존하는 로그 기반 모델입니다.
• 메시지 큐는 복잡한 라우팅과 낮은 지연 시간에 최적화되어 있고, Kafka는 높은 처리량과 확장성에 중점을 둡니다.
• 메시지 큐는 작업 큐, 마이크로서비스 통신에 적합하며, Kafka는 로그 수집, 이벤트 소싱, 데이터 파이프라인에 적합합니다.
• RabbitMQ는 유연한 라우팅과 낮은 지연 시간이 특징이며, Kafka는 대용량 처리와 데이터 재생 기능이 강점입니다.
• ActiveMQ는 JMS 표준 준수와 다양한 메시징 패턴을 제공하지만, 처리량과 확장성은 Kafka에 비해 제한적입니다.
• 두 시스템은 상호 배타적이지 않으며, 복잡한 아키텍처에서 서로 보완적으로 사용될 수 있습니다.