Kafka vs RabbitMQ

Kafka vs. RabbitMQ

Apache Kafka와 RabbitMQ는 모두 분산 메시징 시스템이지만 설계 목적, 아키텍처, 활용 사례에서 뚜렷한 차이를 보인다.

기본 개념

Kafka는 LinkedIn에서 개발되어 나중에 Apache 재단으로 이관된 분산 이벤트 스트리밍 플랫폼이다. 주로 대용량 데이터 스트림을 실시간으로 처리하기 위해 설계되었다.

핵심 구성 요소:

• 브로커(Broker): Kafka 서버로, 메시지를 저장하고 관리한다.
• 토픽(Topic): 메시지가 게시되는 카테고리이다.
• 파티션(Partition): 토픽을 여러 파티션으로 나누어 병렬 처리한다.
• 프로듀서(Producer): 토픽에 메시지를 게시하는 애플리케이션이다.
• 컨슈머(Consumer): 토픽의 메시지를 구독하는 애플리케이션이다.
• 주키퍼(ZooKeeper): 브로커 클러스터 관리를 위한 코디네이션 서비스이다.
• 컨슈머 그룹(Consumer Group): 토픽을 구독하는 컨슈머들의 집합이다.

Kafka는 토픽을 파티션으로 분할하여 여러 브로커에 분산 저장함으로써 높은 처리량과 확장성을 제공한다. 각 파티션은 순서가 보장된 불변의 메시지 시퀀스로, 디스크에 저장된다.

RabbitMQ는 Erlang으로 구현된 오픈 소스 메시지 브로커로, AMQP(Advanced Message Queuing Protocol)를 기반으로 한다. 메시지의 안정적인 전달과 라우팅에 중점을 둔다.

핵심 구성 요소:

• Exchange: 프로듀서로부터 받은 메시지를 큐로 라우팅한다.
• Queue: 메시지가 저장되는 버퍼이다.
• Binding: Exchange와 Queue 사이의 관계를 정의한다.
• Virtual Host: 여러 애플리케이션이 같은 RabbitMQ 인스턴스를 공유할 수 있도록 격리된 환경을 제공한다.
• Connection: 클라이언트와 브로커 간의 TCP 연결이다.
• Channel: 하나의 TCP 연결 내에서 여러 통신 채널을 제공한다.

RabbitMQ는 다양한 Exchange 타입(Direct, Topic, Fanout, Headers)을 제공하여 유연한 라우팅 패턴을 지원한다. 메시지는 컨슈머가 처리할 때까지 큐에 저장된다.

아키텍처 및 핵심 기능

Kafka는 발행-구독(Pub-Sub) 모델을 기반으로 하지만, 일반적인 메시징 시스템과는 다른 접근 방식을 취한다:

• 로그 중심(Log-Centric): 메시지는 추가만 가능한(append-only) 로그로 저장된다.
• 컨슈머 풀 모델(Consumer Pull Model): 컨슈머가 브로커로부터 메시지를 가져온다.
• 오프셋 기반(Offset-Based): 각 컨슈머는 자신이 읽은 메시지의 오프셋(위치)를 추적한다.
• 다중 구독자(Multi-Subscriber): 여러 컨슈머 그룹이 독립적으로 동일한 토픽을 소비할 수 있다.

이 모델은 대용량 스트림 처리와 이벤트 소싱에 적합하다. 컨슈머는 자신의 속도로 메시지를 처리하고, 필요에 따라 과거 메시지를 다시 소비할 수 있다.

RabbitMQ는 보다 전통적인 메시징 패러다임을 따른다:

• 메시지 큐잉(Message Queuing): 메시지는 컨슈머에게 전달될 때까지 큐에 저장된다.
• 푸시 모델(Push Model): 브로커가 컨슈머에게 메시지를 전달한다.
• 확인 기반(Acknowledgement-Based): 컨슈머는 메시지 처리 후 확인을 보낸다.
• 메시지 라우팅(Message Routing): 다양한 Exchange 타입을 통해 메시지 라우팅 패턴을 지원한다.

이 모델은 작업 분배와 RPC(Remote Procedure Call) 패턴에 적합하다. 메시지는 일반적으로 한 번만 처리되며, 확인 후 큐에서 제거된다.

성능 및 처리량

성능 및 확장성

Kafka는 매우 높은 처리량을 제공하도록 설계되었다:

• 순차적 디스크 I/O: 디스크 기반의 데이터 저장소에서도 높은 성능을 제공한다.
• 제로 카피(Zero-Copy): 메시지를 네트워크로 전송할 때 불필요한 복사를 방지한다.
• 배치 처리(Batching): 다수의 작은 I/O 작업을 하나의 큰 작업으로 묶어 효율성을 높인다.
• 수평적 확장(Horizontal Scaling): 파티션을 여러 브로커에 분산하여 처리량을 선형적으로 확장한다.

Kafka는 수백만 메시지/초의 처리량을 지원할 수 있으며, 대형 데이터 파이프라인에 적합하다.

RabbitMQ는 낮은 지연 시간과 안정적인 메시지 전달에 초점을 맞추고 있다:

• 메모리 기반(Memory-Based): 메시지는 주로 메모리에 저장된다(필요한 경우 디스크로 이동).
• 발행자 확인(Publisher Confirms): 메시지가 안전하게 저장되었는지 확인한다.
• 클러스터링(Clustering): 여러 노드에 큐를 미러링하여 고가용성을 제공한다.
• 플러그인 시스템(Plugin System): 기능을 확장하기 위한 다양한 플러그인을 지원한다.

RabbitMQ는 일반적으로 Kafka보다 낮은 처리량을 제공하지만, 더 낮은 지연 시간과 더 높은 안정성을 제공한다.

내구성 및 가용성

Kafka는 높은 내구성과 분산 복제를 제공한다:

• 복제 팩터(Replication Factor): 파티션은 여러 브로커에 복제된다.
• 리더-팔로워 모델(Leader-Follower Model): 각 파티션은 하나의 리더와 여러 팔로워를 가진다.
• 장기 보존(Long-Term Retention): 메시지는 설정된 기간 또는 크기 제한까지 유지된다.
• 장애 복구(Fault Tolerance): 브로커 장애 시 파티션 리더십이 자동으로 재할당된다.

Kafka는 데이터 손실 위험이 매우 낮으며, 높은 가용성을 제공한다.

RabbitMQ도 높은 가용성을 위한 메커니즘을 제공한다:

• 지속성(Persistence): 메시지와 큐를 디스크에 저장할 수 있다.
• 미러링 큐(Mirrored Queues): 큐를 여러 노드에 복제하여 노드 장애에 대비한다.
• 퀴럼 큐(Quorum Queues): Raft 합의 알고리즘을 사용하여 더 강력한 복제를 제공한다.
• 클러스터 파티션 처리(Cluster Partition Handling): 네트워크 파티션 상황을 감지하고 처리한다.

RabbitMQ는 적절히 구성된 경우 매우 안정적인 메시지 전달을 제공한다.

주요 사용 사례

Kafka에 적합한 사용 사례

• 로그 집계(Log Aggregation): 다양한 소스의 로그를 중앙 집중화
• 스트림 처리(Stream Processing): 실시간 데이터 스트림 분석
• 이벤트 소싱(Event Sourcing): 상태 변경을 이벤트로 저장
• 활동 추적(Activity Tracking): 사용자 활동이나 시스템 메트릭 추적
• ETL 파이프라인(ETL Pipelines): 데이터 변환 및 적재 프로세스

Kafka는 고성능, 내구성, 확장성이 중요한 대용량 데이터 처리 시나리오에 이상적이다.

RabbitMQ에 적합한 사용 사례

• 작업 큐(Task Queues): 백그라운드 작업 처리 및 부하 분산
• 마이크로서비스 통신(Microservice Communication): 서비스 간 비동기 통신
• 요청-응답 패턴(Request-Response Pattern): RPC와 같은 양방향 통신
• 복잡한 라우팅(Complex Routing): 다양한 조건에 따른 메시지 라우팅
• 우선순위 큐(Priority Queues): 중요한 메시지를 먼저 처리

RabbitMQ는 메시지 라우팅 유연성과 신뢰성이 중요한 시나리오에 적합하다.

기타 특징 비교

운영 및 관리

Kafka는

• 의존성: 주키퍼(ZooKeeper) 필요 (최신 버전에서는 KRaft 모드 지원으로 의존성 제거 중)
• 리소스 요구사항: 상대적으로 높은 메모리 및 디스크 공간 필요
• 모니터링: JMX 기반 메트릭스
• 클라이언트 언어: 다양한 언어 지원(Java, Python, Go,.NET 등)
• 관리 도구: 커맨드 라인 도구와 오픈 소스 UI(Kafka Manager, Confluent Control Center 등)

Kafka는 설정이 복잡할 수 있으나, 큰 규모의 데이터 파이프라인에서 안정적으로 운영된다.

RabbitMQ는

• 의존성: 독립적인 운영 가능
• 리소스 요구사항: 상대적으로 낮은 리소스 요구
• 모니터링: 내장 관리 UI와 HTTP API
• 클라이언트 언어: 다양한 언어 지원(Java, Python, Ruby, PHP,.NET 등)
• 관리 도구: 포괄적인 웹 기반 관리 인터페이스 내장

RabbitMQ는 설정이 직관적이고 관리 도구가 잘 갖추어져 있어 운영이 상대적으로 용이하다.

선택 기준

1. 언제 Kafka를 선택해야 하는가?

   • 대용량 데이터 처리: 초당 수백만 메시지를 처리해야 하는 경우
   • 데이터 스트림 분석: 실시간 데이터 파이프라인이 필요한 경우
   • 이벤트 소싱: 이벤트 기록을 장기간 저장해야 하는 경우
   • 로그 집계: 분산 시스템의 로그를 중앙화해야 하는 경우
   • 내구성: 메시지 손실을 최소화해야 하는 경우
   • 다중 소비: 같은 데이터를 여러 시스템에서 소비해야 하는 경우

2. 언제 RabbitMQ를 선택해야 하는가?

   • 복잡한 라우팅: 다양한 라우팅 패턴이 필요한 경우
   • 낮은 지연 시간: 메시지의 빠른 전달이 중요한 경우
   • 우선순위 큐: 메시지 우선순위를 지정해야 하는 경우
   • 플러그인 필요: 다양한 프로토콜 지원이 필요한 경우
   • 작업 분배: 백그라운드 작업을 분산 처리해야 하는 경우
   • 간편한 관리: 직관적인 관리 도구가 필요한 경우

3. 하이브리드 접근 방식
   많은 기업들은 두 시스템의 장점을 모두 활용하기 위해 하이브리드 아키텍처를 채택한다:

   • Kafka는 대용량 데이터 수집과 장기 저장에 사용
   • RabbitMQ는 세분화된 작업 처리와 복잡한 라우팅에 사용
   • 두 시스템 간의 브리지를 통해 데이터 흐름 유지
     이러한 접근 방식은 각 시스템의 강점을 최대한 활용할 수 있게 해준다.

Kafka vs. RabbitMQ 비교

참고 및 출처