본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 Spring Boot 환경에서의 세션 저장(Session Store) 기능과 redis의 pub sub 기능에 대해 간단하게 알아보았다.
해당 내용을 수강하면서 pub sub 모델을 구현한 메시지 브로커에는 다양한 서비스들이 있는데 선택에 대한 관점에 대해 추가적으로 알아보았다. kakfa와 비교해 보았다.
Redis와 Kafka의 기본 포지션
Pub/Sub 모델을 구현할 때 Redis와 Kafka 중 무엇을 선택할지를 시스템 설계 관점에서 정리해 본다. 두 기술 모두 Pub/Sub 패턴을 지원하지만, 설계 철학과 강점이 다르다는 점을 먼저 전제하는 것이 중요하다.
Redis
- 인메모리 기반 키–값 저장소로, 캐시·세션 저장소·간단한 메시지 브로커 용도로 많이 사용된다.
- Pub/Sub과 Streams 같은 데이터 구조를 통해 메시징 기능을 제공한다.
Kafka
- 디스크 기반 분산 이벤트 스트리밍 플랫폼으로, 대용량 이벤트 데이터 처리와 장기 보존, 재처리에 특화되어 있다.
메시지 처리 모델 비교
메시지 처리 모델에 대해 비교해보자. 요약하면, Redis Pub/Sub은 “지금 이 순간 알림 전달”에, Kafka는 “시간 순서가 있는 이벤트 로그를 축적·재사용”하는 데 초점이 맞춰져 있다.
Redis Pub/Sub
- 발행자가 채널에 메시지를 보내면 Redis가 구독자들에게 즉시 푸시하는 구조다.
- 메시지가 전송된 후에는 별도 보존이 없고, 구독자가 없으면 메시지는 그냥 사라진다.
- 일종의 “실시간 알림 버스”에 가깝고, at-most-once 성격에 가깝다(중복 처리·재전송·리플레이는 직접 구현해야 한다).
Redis Streams
- Streams는 Redis의 “로그형 데이터 구조”로, 단순 Pub/Sub보다 훨씬 Kafka에 가까운 기능을 제공한다.
- 메시지에 ID가 부여되고, Stream에 순차적으로 적재된다.
- Consumer Group을 사용하면 특정 그룹 내에서 메시지를 나눠 소비하고, ACK 기반으로 처리 상태를 관리할 수 있다.
- 이 구조 덕분에, Redis도 어느 정도 메시지 재처리·지연 소비를 지원하지만, 기본적으로 인메모리 기반이라 장기 보관·초대용량 로그 처리에는 부담이 생긴다.
Kafka
- Kafka는 토픽/파티션/오프셋 개념을 중심으로 설계된 분산 로그 저장소다.
- 프로듀서는 토픽에 이벤트를 append-only로 기록하고, 컨슈머는 각자 오프셋을 관리하며 필요한 위치부터 읽어간다.
- 메시지는 디스크에 로그로 저장되고, 보존 기간(retention) 또는 용량 기준으로 자동 정리된다.
- 컨슈머 그룹을 통해 수평 확장(파티션 단위 병렬 처리)이 가능하고, 동일 이벤트를 여러 컨슈머 그룹이 독립적으로 읽을 수 있어 리플레이, 분기 처리에 매우 유리하다.
스토리지·성능·확장성 관점에서의 차이
아래 표는 Pub/Sub 관점에서 Redis와 Kafka를 비교한 정리다. Streams는 Redis 컬럼에 포함했다.
| 관점 | Redis PubSub / Streams | Kafka |
| 저장 방식 | 인메모리(옵션으로 디스크 영속화), Streams는 로그 구조지만 기본은 RAM 의존 | 디스크 기반 로그 저장, 필요 시 원격 스토리지로 오프로드 |
| 메시지 보존 | Pub/Sub은 보존 없음, Streams는 비교적 단기 보존과 재처리 지원 | 보존 기간·용량 정책 설정 가능, 장기 이벤트 로그 보관에 적합 |
| 전송 모델 | 주로 푸시 기반, 구독자가 없으면 메시지 유실 | 풀 기반(컨슈머가 오프셋을 기준으로 가져감) |
| 처리량·확장성 | 단일 인스턴스 성능은 매우 빠르고 지연 시간이 낮음. 클러스터링으로 수평 확장 가능하지만 메모리 비용 증가 | 파티션 기반 수평 확장에 최적화, 대용량 스트림 처리·다수 컨슈머 그룹에 유리 |
| 내구성·장애 대응 | 적절한 복제와 영속화 설정이 필요, 기본 Pub/Sub은 재처리 기능이 약함 | 브로커·파티션 단위 복제, 컨슈머 리플레이·DLQ 등 내장 기능 풍부 |
| 대표 사용처 | 캐시 무효화, 실시간 알림, 세션/상태 공유, 경량 실시간 스트림 | 로그·이벤트 수집, 데이터 파이프라인, 이벤트 소싱, 분석용 스트림 |
어떤 Pub/Sub 기술을 선택할까?
요구사항에 따라 골라 쓰는 것이 중요하다. 몇 가지 전형적인 기준을 정리해보면 다음과 같다.
Redis Pub/Sub / Streams를 선택하기 좋은 경우
- 짧은 수명의 이벤트이고, 재처리나 장기 보관이 필요 없는 경우
- 예: 로컬 캐시 무효화 브로드캐스트, 실시간 UI 알림, 간단한 상태 변경 알림.
- 지연 시간(latency)이 매우 중요하고, 데이터량이 상대적으로 크지 않은 경우
- Redis는 인메모리 특성상 매우 낮은 지연을 제공하므로, 빠른 반응이 필요한 시스템에 유리하다.
- 이미 Redis를 캐시/세션 스토어로 사용 중이고, 추가 인프라 없이 경량 메시징 레이어가 필요한 경우
- 운영 복잡도를 최소화하면서, Pub/Sub 기능을 “덤”으로 활용하는 전략에 가깝다.
Kafka를 선택하기 좋은 경우
- 이벤트를 장기 보존하거나, 여러 시스템이 같은 이벤트를 서로 다른 속도로 소비/재처리해야 하는 경우
- 예: 로그 수집, 추후 분석을 위한 이벤트 저장, CDC(Change Data Capture) 파이프라인, 이벤트 소싱.
- 초당 수만~수십만 건 이상의 대용량 이벤트 스트림을 다수의 컨슈머 그룹이 소비해야 하는 경우
- 파티션을 늘려 컨슈머 수평 확장을 할 수 있어 고처리량에 최적화되어 있다.
- “지금만 중요”한 알림이 아니라, 시간 순서가 중요한 데이터 흐름 자체를 비즈니스의 핵심 자산으로 취급해야 하는 경우
- 예: 유저 행동 이벤트 로그, 결제 이벤트, IoT 센서 데이터 등.
둘을 함께 쓰는 하이브리드 패턴
실무에서는 Redis와 Kafka를 동시에 사용하는 패턴도 자주 등장한다.
- Kafka: 시스템 전체의 정식 이벤트 로그 및 데이터 파이프라인.
- Redis Pub/Sub 또는 Streams:
- Kafka에서 처리된 결과를 읽어 실시간 대시보드에 반영하거나,
- Kafka 이벤트를 기반으로 특정 서비스에 저지연 알림을 제공하는 용도로 사용.
이처럼, Redis는 “빠른 캐시 + 경량 메시징”, Kafka는 “중심 이벤트 로그 + 데이터 파이프라인”이라는 역할을 나누어 설계하면, 각 기술의 강점을 활용하면서 단점을 상호 보완할 수 있다.
선택을 위한 간단 체크리스트
정리 차원에서, Pub/Sub 기술을 고를 때 체크해보면 좋은 질문들을 적어보면 다음과 같다.
- 메시지를 재처리하거나 나중에 다시 읽을 필요가 있는가?
- 예: 예전 이벤트를 다시 돌려보며 재집계, 장애 이후 재처리 등
- Kafka 또는 Redis Streams(단, 용량·보존 기간 요구사항이 크다면 Kafka 우선).
- 메시지의 수명은 어느 정도인가?
- “그 시점에만 의미 있고 지나면 버려도 된다” → Redis Pub/Sub 유리.
- “시간 순서가 중요하고, 과거 데이터도 비즈니스 자산이다” → Kafka 유리.
- 트래픽 규모와 컨슈머 수는 어느 정도인가?
- 단일/적은 수의 서비스 간 신호 전달 수준 → Redis만으로도 충분.
- 다수의 마이크로서비스와 데이터 파이프라인이 같은 스트림을 공유 → Kafka 고려.
- 운영 복잡도를 얼마나 감당할 수 있는가?
- Redis는 상대적으로 단순하지만, 내구성·클러스터링·모니터링을 직접 챙겨야 한다.
- Kafka는 인프라 구성·운영 난이도가 높지만, 그만큼 스트리밍 플랫폼으로서의 기능이 풍부하다.
참고 출처
- https://aws.amazon.com/ko/compare/the-difference-between-kafka-and-redis/?utm_source=chatgpt.com
- https://betterstack.com/community/comparisons/redis-vs-kafka/?utm_source=chatgpt.com
- https://www.geeksforgeeks.org/system-design/redis-vs-kafka/?utm_source=chatgpt.com
