Redis streaming

Redis streaming (Streaming)

전용 스트리밍 플랫폼을 세울 필요 없이, 컨슈머 그룹·재생·설정 가능한 보존으로 정렬된 이벤트 스트림을 처리·전달하고 싶다면 Redis streaming을 쓸 수 있어요.

출처: Redis 공식 문서 — Redis streaming

언제 Redis streaming을 쓰나 (When to use)

전용 스트리밍 플랫폼을 세우지 않고 컨슈머 그룹·재생·설정 가능한 보존으로 정렬된 이벤트 스트림(사용자 행동, 텔레메트리, 트랜잭션, 서비스 간 메시지)을 처리·전달해야 할 때 Redis streaming을 사용해요.

왜 이 문제가 어려운가 (Why the problem is hard)

작동 가능한 스트리밍 계층은 정렬된 내구성 로그, 독립 컨슈머 추적과 확인(acknowledgment), at-least-once 전달, 보존 제어가 필요해요 — 모두 중간 규모 워크로드에 별도 브로커를 도입하지 않고요.

이 패턴은 이력이 없는 at-most-once 전송인 pub/sub과 달라요. 메시지가 발행될 때 오프라인인 구독자는 그 메시지를 영원히 놓치니까요. 또한 각 작업을 정확히 한 워커가 인수해 완료 후 버리는 job queue와도 달라요. Streaming은 정렬된 이력을 보존하므로, 많은 독립 컨슈머 그룹이 같은 이벤트를 제 각자의 속도로 읽고 어느 지점에서든 재생할 수 있어요.

Redis 솔루션에서 기대할 수 있는 점 (What you can expect)

여러 독립 컨슈머 그룹에 정렬된 이벤트를 전달하되, 각 그룹이 제 속도로 전체 스트림을 처리하게 할 수 있어요.
그룹 안에서 컨슈머를 수평 확장해 at-least-once 전달과 컨슈머별 추적으로 워커 간 작업을 공유할 수 있어요.
디버깅, 새 프로젝션 부트스트랩, 하위 시스템을 처음부터 재구축을 위해 과거 이벤트를 재생할 수 있어요.
길이·최소 ID로 이벤트를 보존해 별도 정리 작업 없이 메모리를 묶을 수 있어요.
크래시한 컨슈머의 미확인 엔트리를 회수해 워커가 메시지 중간에 죽어도 작업을 조용히 잃지 않게 해요. (확인 전 MAXLEN ~로 잘린 엔트리는 XAUTOCLAIM의 deleted-IDs 목록에 표면화되어, 호출자가 누락 페이로드에 대해 재시도하는 대신 dead-letter 저장소로 보낼 수 있어요)
부하 분산과 엔티티별 event sourcing을 위해 테넌트·리전·엔티티별로 스트림을 파티셔닝할 수 있어요.
이미 운영 중인 인프라를 사용해 중간 규모·짧은 보존의 스트리밍 워크로드에서 전용 Kafka 배포를 대체할 수 있어요.

Redis가 이 솔루션을 어떻게 지원하는가 (How Redis supports the solution)

실무에서 프로듀서는 XADD로 스트림에 이벤트를 추가하고 Redis는 각 엔트리에 자동 생성된 시간 정렬 ID를 부여해요. 컨슈머는 XREAD로 스트림을 직접 읽거나, 컨슈머 그룹에 가입해 XREADGROUP으로 읽어요. 각 컨슈머는 처리 중인 메시지의 자체 pending-entries 목록을 갖고, 그룹 전체는 엔트리가 어떤 컨슈머에게든 나눠질 때 전진하는 단일 last-delivered-id 커서를 추적해요. 컨슈머가 엔트리 처리를 끝내면 XACK로 확인하고, 타임아웃을 넘겨 미확인 상태로 남은 엔트리는 XCLAIM이나 XAUTOCLAIM로 건강한 컨슈머에게 재지정할 수 있어요.

Redis가 streaming에 잘 맞는 이유가 되는 기능은 다음과 같아요:

Streams(XADD, XLEN)는 자동 생성 시간 정렬 ID를 가진 append-only 로그라, 정렬이 애플리케이션이 유지해야 할 것이 아닌 데이터 구조 자체에 내재해요.
Consumer groups(XREADGROUP)이 독립 진행 추적과 at-least-once 전달로 그룹 내 컨슈머 간 작업 공유를 제공해요. 각 컨슈머는 자체 pending-entries 목록을 갖고, 그룹 커서는 컨슈머 승인에 의해 전진해요.
미확인 엔트리를 XACK으로 확인하고, 시간초과된 미확인 엔트리를 XCLAIM/XAUTOCLAIM으로 회수해 컨슈머 크래시에서 복구해요.
MAXLEN ~ 근사 트리밍(approximate trimming)과 최소 ID 보존으로 유한 메모리 보존 한도를 주고, 부적절한 ID로 저장되는 것을 막아요.
파티셔닝은 테넌트·리전·엔티티별 키로 이루어져 부하 분산과 엔티티별 event sourcing을 지원해요.
메모리에서 밀리초 미만 읽기·쓰기로 streaming이 이미 캐시·세션·rate limiting을 처리하는 같은 Redis 인스턴스에서 한계 비용 없이 돌아요.

생태계 (Ecosystem)

이벤트 중심 워크로드에 Redis Streams를 쓰는 라이브러리·프레임워크는 다음과 같아요:

Java: Spring Data Redis Streams가 생산자·소비자 추상화와 pending-entries 처리가 있는 컨슈머 그룹 처리를 제공해요.
Node.js: node-redis와 ioredis가 이벤트 중심 API에서 스트림 프로듀서·컨슈머를 제공해요.
Python: redis-py를 FastAPI 또는 Django와 함께 마이크로서비스 이벤트 파이프라인에 써요.
Infrastructure: Redis Enterprise / Redis Cloud의 Active-Active geo-distribution으로 리전 간 스트림 복제; Azure Managed Redis와 함께 써요.

직접 만드는 Redis streaming 파이프라인 코드 예제 (Code examples)

아래 가이드는 프로듀서와 컨슈머 그룹이 있는 간단한 Redis 백엔드 이벤트 스트림을 만드는 방법을 보여줘요. 각 가이드에는 이벤트 생성, 그룹 내 컨슈머 확장, 어느 지점에서든 이력 재생, 독립 그룹 관찰이 가능한 실행 가능한 인터랙티브 데모가 있어요.