Redis를 활용한 메시징 시스템의 두 기능은 모두 “데이터를 전달한다"는 목적은 같지만, **철학(Philosophy)**과 데이터 보존 방식에서 결정적인 차이가 있습니다.
한마디로 요약하자면: **Pub/Sub은 ‘방송’**이고, **Streams는 ‘기록이 남는 로그’**입니다.
1. Redis Pub/Sub (Publish/Subscribe)
가장 전통적인 형태의 메시징 모델입니다. 발신자가 메시지를 던지면, 그 순간 연결되어 있는 모든 수신자에게 실시간으로 전달됩니다.
- 휘발성 (Fire and Forget): 메시지를 보낸 후 어디에도 저장하지 않습니다. 수신자가 오프라인 상태라면 그 메시지는 영원히 사라집니다.
- 실시간성: 지연 시간이 거의 없어 실시간 알림이나 채팅에 적합합니다.
- 팬아웃(Fan-out): 하나의 메시지를 수천 명의 구독자에게 동시에 뿌릴 때 매우 효율적입니다.
2. Redis Streams
Kafka와 유사한 기능을 Redis에 구현한 모델입니다. 단순 전달을 넘어 데이터의 ‘이력’을 관리합니다.
- 영속성 (Persistence): 메시지가 Redis 메모리에 저장됩니다. 소비자가 읽어간 후에도 설정한 기간이나 개수만큼 보관됩니다.
- 소비자 그룹 (Consumer Groups): 여러 대의 서버가 하나의 스트림을 나눠서 처리할 수 있습니다. (메시지 분산 처리)
- 오프라인 대응: 수신자가 잠시 다운되었다가 다시 접속해도, 읽지 않은 시점부터 메시지를 다시 가져올 수 있습니다.
- 확인 응답 (ACK): 소비자가 메시지를 성공적으로 처리했는지 서버에 알리는 메커니즘이 있습니다.
3. 주요 차이점 비교 테이블
| 구분 | Redis Pub/Sub | Redis Streams |
|---|---|---|
| 데이터 저장 | 없음 (즉시 삭제) | 있음 (메모리에 보관) |
| 메시지 재전송 | 불가능 | 가능 (Offset 기준) |
| 수신 대상 | 연결된 모든 구독자 | 소비자 그룹 내 1명 또는 전체 |
| 주요 용도 | 실시간 채팅, 단순 알림 | 이벤트 소싱, 작업 큐, 데이터 분석 |
| 안정성 | 낮음 (네트워크 끊기면 유실) | 높음 (ACK 및 재처리 지원) |
무엇을 선택해야 할까요?
-
Pub/Sub을 선택하세요:
-
메시지 유실이 크게 중요하지 않은 실시간 대시보드 업데이트.
-
짧고 빠른 실시간 채팅 서비스.
-
구현이 매우 간단해야 할 때.
-
Streams를 선택하세요:
-
데이터 유실이 절대 없어야 하는 결제/주문 이벤트 처리.
-
대량의 데이터를 여러 워커(Worker)가 분산해서 처리해야 할 때.
-
서비스가 잠시 멈춰도 재가동 시 과거 데이터를 이어서 처리해야 할 때.
추후 Kafka로 전환을 미리 고려한다면?
추후에 Apache Kafka로 마이그레이션할 계획이 있으시다면, 고민할 필요 없이 Redis Streams를 선택하셔야 합니다.
Redis Streams 자체가 Kafka의 디자인 철학(Append-only Log, Consumer Group, Offset 관리)을 상당 부분 벤치마킹하여 만들어졌기 때문입니다.
Redis Streams가 Kafka로 가는 징검다리인 이유
1. 동일한 아키텍처 구조
Kafka와 Redis Streams는 메시지를 처리하는 방식이 매우 유사합니다. 나중에 코드를 수정할 때 로직의 큰 틀을 유지할 수 있습니다.
- Log-based Storage: 두 시스템 모두 메시지를 순차적으로 쌓아두는 로그 형태입니다.
- Consumer Groups: Kafka의 핵심 기능인 ‘소비자 그룹’ 개념이 Redis Streams에도 그대로 구현되어 있어, 수평 확장(Scaling-out) 로직을 미리 연습할 수 있습니다.
- Offset 관리: 어디까지 읽었는지 기록하는
ID(Redis)와Offset(Kafka) 개념이 대응됩니다.
2. 마이그레이션 시나리오 비교
| 비교 항목 | Pub/Sub → Kafka | Streams → Kafka |
|---|---|---|
| 코드 변경량 | 로직 전체를 새로 짜야 함 | 인터페이스와 라이브러리 교체 수준 |
| 데이터 성격 | 실시간 방송형 (비저장) | 로그/이벤트형 (저장) |
| 장애 대응 | 재처리를 위한 DB 설계 별도 필요 | 이미 구현된 ACK/Retry 로직 활용 가능 |
Kafka로 넘어가기 전, 주의할 점
비록 Streams가 Kafka와 닮았지만, Redis는 결국 ‘인메모리’ 기반이라는 점을 기억해야 합니다.
- 저장 용량의 한계: Kafka는 디스크 기반이라 테라바이트 단위의 데이터를 쌓아두지만, Redis는 메모리가 꽉 차면 위험합니다.
XADD시MAXLEN옵션을 사용해 데이터 개수를 제한하며 운영하는 것이 좋습니다. - 영속성 전략: Redis의 AOF(Append Only File) 설정을 강화해야 Kafka 수준의 안정성을 흉내 낼 수 있습니다. (물론 성능은 조금 트레이드오프 됩니다.)
- 파티셔닝: Kafka의 파티션만큼 강력한 분산 처리를 Redis에서 구현하려면 Redis Cluster 환경을 잘 구성해야 합니다.