스트리밍 데이터 처리: Apache Kafka vs RabbitMQ

스트리밍 데이터 처리: Apache Kafka vs RabbitMQ 완벽 비교

현대의 웹 애플리케이션과 대규모 분산 시스템에서는 실시간 데이터 스트리밍이 핵심입니다. IoT 기기에서 발생하는 센서 데이터, SNS의 실시간 게시물, 실시간 로그 및 분석 시스템 등 수많은 시스템이 스트리밍 아키텍처를 요구하고 있습니다. 이러한 환경에서 가장 많이 사용되는 메시지 브로커로는 Apache Kafka와 RabbitMQ가 있습니다.

이 글에서는 Apache Kafka와 RabbitMQ의 구조, 성능, 사용 사례, 장단점 등을 심층적으로 비교하고, 어떤 상황에 어떤 메시징 시스템을 선택해야 하는지에 대해 설명드리겠습니다.

 

1. 메시지 브로커란?

메시지 브로커는 송신자와 수신자 사이에서 메시지를 중개하는 시스템입니다. 메시지 브로커를 사용하면 두 시스템이 직접 통신하지 않아도 되기 때문에 비동기 처리, 확장성, 장애 복원력이 향상됩니다.

 

2. Apache Kafka란?

Kafka는 분산형 스트리밍 플랫폼으로, 고속 로그 수집 및 대용량 데이터 스트리밍을 위해 설계된 시스템입니다. Kafka는 다음과 같은 특징을 가지고 있습니다.

• 분산형 아키텍처: 브로커, 파티션, 리플리케이션으로 구성되어 확장성이 뛰어남
• 높은 처리량: 초당 수십만 건 이상의 메시지를 처리 가능
• 내구성: 디스크에 메시지를 저장하고, 리플리케이션으로 데이터 손실 방지
• Publish/Subscribe 기반: 하나의 메시지를 다수의 소비자가 동시에 구독 가능
• Stream Processing 지원: Kafka Streams, ksqlDB 등 실시간 처리 지원

 

3. RabbitMQ란?

RabbitMQ는 메시지 큐 기반의 브로커로, AMQP(Advanced Message Queuing Protocol)를 따릅니다. 비교적 전통적인 메시징 시스템으로 안정성과 유연성을 제공합니다.

• 큐 기반 아키텍처: 메시지는 큐에 저장되고, 소비자가 큐에서 하나씩 가져감
• 낮은 지연시간: 실시간 처리가 뛰어남
• 라우팅 기능이 강력: 다양한 Exchange 타입으로 복잡한 라우팅 처리 가능
• 플러그인 아키텍처: 인증, 모니터링 등 다양한 기능 확장 가능
• 경량 시스템: 중소규모 애플리케이션에서 사용하기 적합

 

4. 아키텍처 비교

항목	Kafka	RabbitMQ
프로토콜	자체 TCP 기반	AMQP, MQTT, STOMP 등
메시지 보관	디스크 기반 (로그 저장)	메모리 중심, 옵션으로 디스크 저장
처리 방식	Pull 기반 (Consumer가 요청)	Push 기반 (Broker가 전달)
확장성	뛰어남 (샤딩, 파티션 구조)	상대적으로 낮음
메시지 순서 보장	파티션 내 순서 보장	큐 단위 순서 보장
트랜잭션	제한적 지원	강력한 트랜잭션 지원
주요 사용 사례	로그 수집, 실시간 분석, 대용량 스트리밍	작업 큐, 실시간 알림, 마이크로서비스 메시징

 

 

4-1. Kafka 예제: Python + kafka-python

from kafka import KafkaProducer

producer = KafkaProducer(bootstrap_servers='localhost:9092')
producer.send('my-topic', b'실시간 로그 메시지 예제')
producer.flush()

Kafka는 파티션을 통해 데이터의 병렬 처리를 가능하게 하며, 메시지를 로그처럼 저장하기 때문에, 메시지 재처리나 이중 소비가 가능합니다.

 

4-2. RabbitMQ 예제: Python + pika

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

channel.queue_declare(queue='task_queue')
channel.basic_publish(exchange='',
                      routing_key='task_queue',
                      body='작업 메시지 전송')
connection.close()

RabbitMQ는 메시지를 한 번 소비한 후 삭제하며, 단순한 작업 큐 처리에 매우 적합합니다.

 

5. 실전 사용 사례 분석

5-1. Kafka가 적합한 경우

1. 대용량 데이터 수집 및 분석
   • 로그 수집 시스템 (ELK, Fluentd)
   • 클릭 스트림 분석
   • IoT 센서 수천 개 이상으로부터 수집되는 데이터 처리
2. 데이터 스트리밍 처리
   • 실시간 마케팅 이벤트 분석
   • 실시간 추천 시스템 (예: 사용자 행동 기반 상품 추천)
3. 높은 내구성과 복원력 필요
   • 데이터 유실 없이 복구 가능해야 하는 금융/보안 시스템

5-2. RabbitMQ가 적합한 경우

1. 작업 큐 처리
   • 이메일 발송, 이미지 변환, 파일 처리 등 비동기 작업 처리
   • 마이크로서비스 간 작업 분배
2. 낮은 지연시간이 중요할 때
   • 실시간 알림 전송
   • 채팅 시스템, 주식 거래 처리 등
3. 복잡한 라우팅 로직이 필요한 경우
   • 다양한 큐로 메시지를 분기해야 하는 업무

 

6. 성능 비교 (간단 벤치마크 예시)

항목	Kafka	RabbitMQ
처리량 (TPS)	1백만 이상	10만 이하
평균 지연시간	수 ms ~ 수십 ms	수 ms
메시지 보존 기간	무제한 (설정 가능)	기본은 소비 시 삭제
확장성	우수 (수천 노드까지)	제한적 (10~50 노드 권장)

실제 벤치마크 수치는 환경에 따라 다르므로 참고용입니다.

 

7. 결론: 어떤 메시지 브로커를 선택해야 할까?

Kafka와 RabbitMQ는 메시징 목적은 같지만 철학과 구조가 다릅니다.

• Kafka는 로그 기반 스트리밍 플랫폼, 수많은 이벤트를 저장하고 다양한 소비자가 동시에 읽어야 할 경우 이상적입니다.
• RabbitMQ는 전통적인 메시지 큐 시스템, 간단한 작업 분배나 낮은 지연시간이 중요할 때 유리합니다.

현대 시스템에서는 두 브로커를 함께 사용하는 하이브리드 구조도 많습니다. 예를 들어, Kafka로 로그 수집 → 실시간 처리, RabbitMQ로 비동기 작업 처리를 동시에 구성할 수 있습니다.

 

8. 마무리하며

스트리밍 데이터 환경이 확산됨에 따라 메시지 브로커의 선택은 시스템 성능과 아키텍처에 큰 영향을 미칩니다. Kafka와 RabbitMQ는 서로 대체제가 아니라, 목적에 따라 보완적으로 사용할 수 있는 도구입니다. 각자의 장단점을 잘 이해하고, 아키텍처 설계 시 전략적으로 적용한다면 더욱 안정적이고 유연한 시스템을 구축할 수 있습니다.

니까? 이미지, 다이어그램 또는 Kafka 스트리밍 예제 흐름도가 필요하시면 말씀해주세요!