1️⃣ 메시징 시스템의 공통 목표
- 서비스 간 결합도 낮추기
- 트래픽 폭주를 흡수
- 비동기 처리와 장애 복원력 확보
- 신뢰성 있는 전달
하지만 이 공통 목표를 어떤 방식으로 구현하느냐가 Kafka, RabbitMQ, Redis Pub/Sub의 근본적 차이.
2️⃣ Kafka — “로그 스트림 기반 이벤트 플랫폼”
🧠 개념
Kafka는 단순한 메시지 큐가 아니라 분산 로그 저장소.
모든 메시지는 디스크에 Append-Only로 기록되고,
Consumer Group이 각자 오프셋을 관리하며 읽음.
✅ 강점
- 초고속 처리량
- 리플레이 가능: retention 기간 동안 재소비 가능
- 확장성: Broker + Partition 기반 선형 확장
- Exactly-once 처리 지원 (Kafka Streams / Transactional API)
⚠️ 한계
- 브로커 운영이 복잡함
- 메시지 실시간성보단 대량 처리에 최적화
- 순서 보장은 파티션 내에서만 가능
🧩 사용 예시
- 데이터 파이프라인 (로그 수집, CDC, 검색 인덱스 갱신)
- 도메인 이벤트 전달
- 스트림 프로세싱
3️⃣ RabbitMQ — “신뢰성 있는 큐 중심 메시지 브로커”
🧠 개념
RabbitMQ는 AMQP 프로토콜 기반의 메시지 브로커로,
Exchange -> Queue -> Consumer 라우팅 모델을 사용.
즉, 메시지가 들어오면 Exchange에서 라우팅 규칙에 따라
하나 이상의 Queue로 전달.
✅ 강점
- 메시징 패턴이 다양함
- ACK 기반 전달 보장
- 메시지 우선순위, DLQ, TTL 등 비즈니스 큐에 유리한 기능
- 간단한 1:1 / 1:N 워크큐 모델
⚠️ 한계
- 처리량은 Kafka보다 낮음
- 메시지 순서 보장이 약함(멀티큐 병렬 처리 시)
- 큰 메시지나 초대량 트래픽에는 부적합
🧩 사용 예시
- 주문 처리/배송 요청 등 업무 단위 큐
- 이메일/푸쉬 알림/백오피스 작업
4️⃣ Redis Pub/Sub — “가볍고 빠른 실시간 알림”
🧠 개념
Redis의 Pub/Sub은 메모리 기반 실시간 브로드캐스트 기능.
Publisher가 채널에 메시지를 발행하면
그 채널을 구독한 모든 Subscriber에게 즉시 전송됨.
✅ 강점
- 매우 낮은 지연
- 운영이 간단함
- 채팅방, 알림, 게임 서버 등 초실시간 이벤트에 적합
⚠️ 한계
- 메시지 유실 가능
- 지속성 없음 (메시지 저장 안함)
- 재시도, ACK, DLQ 기능 없음
- Subscriber가 순간적으로 끊기면 메시지 놓침
🧩 사용 예시
- 실시간 알림/피드/채팅
- 간단한 내부 이벤트 브로커
5️⃣ 판단 포인트
| 판단 기준 | Kafka | RabbitMQ | Redis Pub/Sub |
| 데이터 유실 절대 금지 | ✅ | ✅ | ❌ |
| 실시간 알림 성능 최우선 | ⚠️ | ✅ | ✅ ✅ |
| 대규모 확장 필요 | ✅ ✅ | ⚠️ | ❌ |
| 메시지 순서 중요 | 파티션 단위 | 큐 단위 | ❌ |
| 비즈니스 로직 큐잉 | ⚠️ | ✅ ✅ | ❌ |
| 운영 단순성 | ❌ | ⚠️ | ✅ ✅ |
'DevOps' 카테고리의 다른 글
| 🧩 프로세스 수준에서의 동시 접근 제어 — 락, 세마포어 (0) | 2025.11.14 |
|---|---|
| 🌐 외부 연동 설계 — 타임아웃부터 서킷 브레이커까지 (0) | 2025.11.11 |
| ⚖️ CAP 정리 — 분산 시스템의 세 가지 불가능한 균형 (0) | 2025.10.29 |
| 🔍 DB 인덱스 - 빠른 검색의 비밀 (0) | 2025.10.28 |
| 🧩 DB 커넥션 풀, 실무에서 반드시 알아야 하는 이유 (0) | 2025.10.27 |