[Message Broker] Kafka vs RabbitMQ 📮 | 메시지 브로커의 구조와 선택 기준
메시지 브로커는 시스템 간의 느슨한 결합(Loose Coupling)과 안정적인 데이터 전달을 위해 꼭 필요한 핵심 구성요소입니다.
오늘은 두 대표 브로커, RabbitMQ와 Kafka를 비교하며 구조와 작동 원리에 대해 포스팅하려 합니다.
요약 실패로 많은 부분 요약되었습니다.
1️⃣ 왜 메시지 브로커가 필요한가?
애플리케이션 간 통신은 기본적으로 요청(Request) - 응답(Response) 구조를 가지고 있습니다.
REST API, GraphQL, gRPC, WebSocket 등 다양한 방식이 있지만, 이들은 대부분 양쪽이 동시에 작동 중이어야 데이터가 정상적으로 전송됩니다.
하지만 이런 구조에는 근본적인 한계가 있습니다.
“만약 수신 서비스가 일시적으로 다운되면, 요청이 실패하고 데이터가 유실된다.”
이 문제는 시스템이 커질수록 심각해집니다.
특히 마이크로서비스 아키텍처(MSA) 환경에서는 하나의 이벤트가 여러 서비스로 흘러가야 하는 일이 많습니다.
💬 예시) SNS 시스템
사용자의 게시글 등록 이벤트
게시글 서비스 → 알림 서비스 / 피드 서비스 / 통계 서비스 / 로그 서비스 …
- 모든 서비스가 동시에 살아 있어야 정상 동작
- 하나라도 실패하면 데이터 유실
- 새로운 서비스 추가 시, 게시글 서비스 코드 수정 필요 → 강한 결합도 발생
이런 문제를 해결하기 위해 등장한 것이 바로 메시지 브로커(Message Broker) 입니다.
2️⃣ 메시지 브로커의 개념과 역할
메시지 브로커는 “보내는 쪽(Producer)”과 “받는 쪽(Consumer)” 사이의 중간자입니다.
이 두 컴포넌트가 서로의 존재나 상태를 몰라도, 안전하게 데이터를 주고받을 수 있게 합니다.
| 구성 요소 | 역할 |
| Producer | 메시지를 생성하여 브로커에 전달 |
| Broker | 메시지를 임시 저장하고 분배 |
| Consumer | 브로커에서 메시지를 가져와 처리 |
📦 비유하자면, 메시지 브로커는 ‘택배함’ 과 같음
- 프로듀서는 택배함에 메시지를 넣기만 하면 됨
- 컨슈머는 자신이 필요할 때 꺼내면 됨
- 택배함(브로커)은 일정 시간 동안 안전하게 보관함
📌 즉, 보내는 쪽과 받는 쪽의 결합을 끊어주는 비동기 통신 구조가 완성됩니다.
3️⃣ RabbitMQ - Queue 기반 메시지 브로커
RabbitMQ는 AMQP(Advanced Message Queuing Protocol) 기반의 메시지 브로커입니다.
메시지를 Queue(큐) 형태로 저장하고, 선입선출(FIFO) 방식으로 처리합니다.
📌 작동 구조
- Producer가 메시지를 브로커에 전송
- Exchange가 어떤 Queue로 라우팅할지 결정
- Consumer가 Queue에서 메시지를 꺼냄
- 처리 완료 후, Ack(확인 응답) 을 브로커에 전달
- 브로커는 Ack을 받은 메시지를 삭제
📌 핵심 개념
| 개념 | 설명 |
| Exchange | 메시지를 큐로 전달하는 라우팅 허브 |
| Queue | 메시지를 저장하는 버퍼 |
| Binding | Exchange와 Queue의 연결 관계 |
| Ack | 메시지가 정상적으로 처리되었음을 알림 |
📌 RabbitMQ 특징 요약
| 항목 | 내용 |
| 처리 모델 | Smart Broker, Dumb Consumer |
| 저장 방식 | Queue (FIFO) |
| 저장 위치 | 메모리 기반 (속도 빠름, 유실 위험 있음) |
| 강점 | 복잡한 라우팅, Ack 기반 신뢰성, 작업 큐 |
| 적합한 경우 | 이메일, 결제, 이미지 처리 등 안정성 필요한 작업 |
4️⃣ Kafka - Log 기반 이벤트 스트리밍 플랫폼
Kafka는 단순 메시지 브로커가 아닙니다.
이벤트 스트리밍 플랫폼(Event Streaming Platform) 으로 불립니다.
RabbitMQ가 메시지를 “한 번 보내고 끝내는 큐”라면,
Kafka는 “지속적으로 데이터를 기록하는 로그(log)”에 가깝다.
📌 작동 방식
- Producer가 Topic 에 메시지 전송
- Broker가 디스크(log) 에 순차적으로 저장 (Append Only)
- 메시지는 삭제되지 않고, 설정된 보존 기간(Retention) 까지 유지
- Consumer는 자신의 Offset 을 기준으로 메시지를 가져감
- 필요한 경우 특정 Offset으로 되돌아가 재처리 가능
📌 핵심 개념
| 개념 | 설명 |
| Topic | 이벤트 종류(게시글, 결제 등)에 따른 구분 단위 |
| Partition | 토픽을 분할 저장하는 단위 (병렬 처리용) |
| Offset | 각 메시지의 고유 인덱스 |
| Consumer Group | 병렬 처리를 위한 소비자 묶음 |
| Cluster | 여러 Broker 서버의 집합 |
📌 Kafka 특징 요약
| 항목 | 내용 |
| 처리 모델 | Dumb Broker, Smart Consumer |
| 저장 방식 | Log (디스크 기반, 순차쓰기) |
| 데이터 유지 | 일정 기간 보존 후 삭제 |
| 컨슈머 모델 | Offset 기반, 재처리 가능 |
| 강점 | 고성능, 확장성, 내결함성 |
| 적합한 경우 | 로그 수집, 스트리밍 분석, 대용량 데이터 파이프라인 |
5️⃣ RabbitMQ vs Kafka 비교 요약
| 구분 | RabbitMQ | Kafka |
| 메시지 구조 | Queue (FIFO) | Log (Append Only) |
| 삭제 시점 | 소비 후 삭제 | 보존 기간 후 삭제 |
| 컨슈머 모델 | Broker 중심 | Consumer 중심 |
| 저장 위치 | 메모리 기반 | 디스크 기반 |
| 처리 성향 | 트랜잭션 중심 | 스트리밍 중심 |
| 강점 | 안정성, 복잡한 라우팅 | 처리량, 확장성 |
| 대표 활용 | 작업 큐, 결제 시스템 | 로그 수집, 실시간 분석 |
6️⃣ 선택 기준 정리
| 상황 | 권장 브로커 |
| 안정적인 메시지 전송, 복잡한 라우팅 | 🐇 RabbitMQ |
| 대규모 데이터 스트림, 실시간 처리 | 🚀 Kafka |
| 분산 작업 큐 필요 | 🐇 RabbitMQ |
| 로그 수집 / 스트리밍 분석 | 🚀 Kafka |
7️⃣ 마무리 요약
RabbitMQ는 “작업 중심 메시징 시스템”으로, 안정성과 신뢰성이 중요할 때 적합합니다.
Kafka는 “데이터 스트리밍 플랫폼”으로, 처리량과 확장성이 필요한 실시간 데이터 파이프라인에 적합합니다.
Reference
https://www.youtube.com/watch?v=0lyrd5FlETQ
https://www.youtube.com/watch?v=Nh3AZx8D9KY
https://www.redhat.com/ko/topics/integration/what-is-apache-kafka
https://aws.amazon.com/ko/what-is/apache-kafka/