서비스가 커지고 컴포넌트가 분리되면,
“데이터를 누가 언제 어떻게 전달하느냐”가 큰 과제가 된다
이때 등장하는 것이 메시지 브로커(Message Broker)다
이번 글에서는 대표적인 세 가지 브로커 ![]
— Redis, Kafka, RabbitMQ — 를 중심으로 동작 원리와 사용 목적을 비교해보자
메시지 브로커(Message Broker)란?
메시지 브로커는 시스템 간 데이터를 안전하게 전달하는 중간자이다
Producer → [Message Broker] → Consumer
생산자(Producer)가 메시지를 보내면,
브로커가 이를 저장하고 소비자(Consumer)가 가져간다
이 구조는 비동기 처리, 시스템 간 결합도 감소, 확장성 향상에 핵심적인 역할을 한다
핵심 키워드
-
비동기성: 생산자와 소비자가 동시에 작동하지 않아도 된다.
-
내결함성(Fault Tolerance): 장애가 발생해도 메시지가 손실되지 않는다.
-
확장성(Scalability): 트래픽 급증에도 대응 가능하다.
Redis – 초고속 인메모리 기반 메시징
Redis는 원래 인메모리 데이터베이스로 시작했지만,
Pub/Sub, Streams, Blocking Queue 기능을 통해 메시지 브로커로도 활용된다
동작 원리
-
Pub/Sub 모델
-
PUBLISH명령으로 메시지를 특정 채널에 발행한다 -
해당 채널을
SUBSCRIBE한 클라이언트에게 즉시 전달된다 -
메시지가 브로커에 저장되지 않기 때문에, 구독하지 않았던 시점의 메시지는 받을 수 없다
-
-
List + BLPOP / BRPOP (Blocking Queue)
-
큐를 흉내낸 구조
-
소비자가 없을 때는 대기하고, 생산자가
push하면 바로pop된다 -
단순하지만 지속성(persistence)과 복구가 약하다
-
-
Redis Streams (5.0+)
-
Kafka와 유사한 구조: 메시지를 로그처럼 저장하고, Consumer Group으로 처리 가능
-
각 메시지에는 ID(offset)가 부여되어 재처리, ack 관리 가능
-
실시간 데이터 파이프라인에서 Kafka의 가벼운 대안으로 사용되기도 한다
-
특징
-
빠른 속도: 모든 데이터가 메모리에 저장되어 지연이 거의 없다
-
단순한 구조: 별도의 토픽, 파티션 개념 없이 간단하게 구성 가능
장점
-
초저지연 (μs 단위 응답)
-
설정과 운영이 단순
-
캐시, 랭킹, 실시간 채팅 등 고속 이벤트 처리에 최적
실제 활용 예시
-
실시간 채팅 시스템: Pub/Sub 기반으로 사용자 간 메시지 전달
-
알림 서버: 빠른 푸시 전송
-
작업 큐(Job Queue): 간단한 비동기 작업 처리
주의점
-
메모리 기반이라 영속성이 약함 (RDB/AOF 설정 필요)
-
클러스터 구성 시 복제 지연에 주의
-
메시지 유실 시 복구가 어렵다
RabbitMQ — 신뢰성이 핵심인 전통 메시지 큐
RabbitMQ는 AMQP(Advanced Message Queuing Protocol)을 구현한 대표 브로커로,
“메시지를 잃지 않고 안전하게 전달하는 것”을 목표로 한다
동작 원리
RabbitMQ는 메시지 라우팅 구조가 매우 유연함
Producer → Exchange → Queue → ConsumerExchange: 메시지를 라우팅하는 중간자
-
direct: 정확히 일치하는 라우팅 키로 전달 -
fanout: 모든 큐에 브로드캐스트 -
topic: 패턴 매칭 기반 -
headers: 메시지 헤더 기반
Queue: 메시지가 실제 저장되는 곳
Consumer: 큐에서 메시지를 가져와 처리 후 ack(확인 응답)를 보냄
장점
-
정확히 한 번(Exactly Once) 처리 보장
-
Dead Letter Queue (DLQ)로 실패 메시지 관리
-
Ack/Nack/Retry로 신뢰성 높은 전달 -
다양한 라우팅 전략으로 복잡한 메시지 흐름 설계 가능
실제 활용 예시
-
결제 처리: “정확히 한 번” 전달이 중요
-
이메일, 푸시 발송: 실패 시 재시도 필요
-
마이크로서비스 간 이벤트 전달
주의점
-
Throughput이 Kafka보다 낮음
-
스케일링이 어려움(노드 간 큐 공유 불가)
-
Latency는 Redis보다 높음
Kafka — 대규모 스트리밍 데이터의 표준
Kafka는 “분산 로그 시스템(Distributed Commit Log)” 개념에 기반한 메시징 플랫폼
단순한 메시지 큐를 넘어, 데이터 파이프라인과 이벤트 스트리밍 플랫폼으로 진화
핵심 개념
-
Topic: 메시지 카테고리 -
Partition: 병렬성과 순서 보장을 위한 단위 -
Offset: 각 메시지의 위치 인덱스 -
Broker Cluster: 데이터를 분산 저장 -
Consumer Group: 여러 소비자가 병렬로 읽기
처리 흐름
Producer → Topic (Partitioned Log) → Consumer Group-
메시지는 디스크에 Append-only 형태로 저장
-
Consumer는 자신의 Offset을 저장해 재처리 가능
-
장애 발생 시 Offset 기반 복구 가능
장점
-
초대규모 데이터 처리: 초당 수백만 메시지
-
영속성: 데이터는 로그 파일로 장기 보관 가능
-
수평 확장: Partition 수를 늘려 Throughput 향상
-
스트리밍 분석과 자연스러운 연계(Spark, Flink, ksqlDB)
실제 활용 예시
-
로그 수집 시스템(ELK, Data Lake)
-
실시간 분석(Spark Streaming, Flink, ksqlDB)
-
대규모 이벤트 파이프라인
주의점
-
운영 복잡도 높음(ZooKeeper → KRaft로 점진 전환 중)
-
메시지 순서는 Partition 내에서만 보장
-
짧은 실시간성은 Redis보다 떨어짐
정리 - 어떤 상황에서 무엇을 사용해야할까?
| 구분 | Redis | RabbitMQ | Kafka |
|---|---|---|---|
| 특징 요약 | 인메모리 Pub/Sub | 신뢰성 높은 큐 | 대규모 로그 스트림 |
| 영속성 | 약함 | 강함 | 매우 강함 |
| 순서 보장 | X | Queue 단위 | Partition 단위 |
| 처리량(Throughput) | 매우 높음 | 중간 | 매우 높음 |
| 지연(Latency) | μs 단위 | ms 단위 | ms~s 단위 |
| 운영 난이도 | 낮음 | 중간 | 높음 |
| 적합한 사례 | 채팅, 알림, 캐시 | 결제, 주문 처리 | 로그, 분석 파이프라인 |
-
Redis → 빠른 실시간 반응이 필요한 서비스
-
RabbitMQ → 신뢰성 있는 트랜잭션 전달이 필요한 시스템
-
Kafka → 대규모 로그 및 이벤트 스트리밍 중심 아키텍처
