Redis 잡 큐

Redis 잡 큐 (Job queue)

이메일 발송, 결제 처리, 이미지 처리, ML 추론, 웹훅 같은 백그라운드 작업을 사용자 요청 경로에서 떼어내 워커 풀에 안정적으로 분산시키는 작업 큐 패턴입니다. Redis 리스트·정렬 집합·스트림을 조합해 at-least-once 전달과 원자적 핸드오프를 보장합니다.

출처: 공식문서 — Redis job queue

언제 잡 큐를 쓰는가

백그라운드 작업(이메일, 결제, 이미지 처리, ML 추론, 웹훅)을 사용자 대면 요청 경로에서 떼어내 워커 풀에 안정적으로 분산시켜야 할 때 사용합니다.

왜 이 문제가 어려운가

백그라운드 작업을 동기 처리하면 부하 시 사용자 요청을 막고 대기 시간이 악화됩니다. 단일 사용자 행동이 여러 다운스트림 작업(이메일 발송, 분석 갱신, 청구 알림)을 유발하고, 공유 큐가 없으면 각 서비스가 스케일에서 취약해지는 point-to-point 통합이 필요합니다. 대표적인 대안의 단점:

  • 단순 인-프로세스 큐: 크래시 시 잡을 유실하고 여러 워커·서비스에 작업을 분산할 수 없음
  • 보류 행을 위해 DB 폴링: 주 DB에 지속 부하를 주고 같은 행을 경쟁하는 워커 사이 핸드오프 레이스 유발
  • 전용 메시지 브로커 도입(RabbitMQ, Kafka, SQS): 배포·모니터링·비용을 추가로 요구 — 종종 잡을 몇 홉 이동시키려는 것뿐인데

작동하는 잡 큐는 at-least-once 전달, 큐→워커의 원자적 핸드오프, 처리 도중 크래시한 워커의 잡 회수(reclaim)가 필요합니다. 잡별 상태·재시도 횟수·완료 결과를 추적하되 그 기록이 영원히 새지 않게 해야 합니다.

Redis 솔루션에서 기대할 수 있는 것

  • 버스트 부하에서 사용자 대면 대기 시간을 낮게 유지하도록 API·서비스와 워커 분리
  • at-least-once 전달과 실패·타임아웃 잡 자동 재시도로 여러 워커에 잡 분산
  • 핵심 Redis 데이터 구조 위에서 FIFO, LIFO, 우선순위, 지연 실행 큐 실행
  • 가시성 타임아웃(visibility timeout)으로 크래시 워커에서 잡 회수 — 처리 중 워커가 죽어도 잡 유실 없음
  • 스트림·컨슈머 그룹으로 단일 사용자 행동을 여러 다운스트림 서비스로 팬아웃
  • Sidekiq, Celery, Bull/BullMQ, RQ 같은 검증된 라이브러리를 Redis 위에서 바로 사용

Redis가 이 솔루션을 어떻게 지원하는가

실제로 Redis 잡 큐는 보류 잡 ID를 리스트에 저장하고, 각 잡을 원자적으로 processing 리스트로 이동시켜 나중에 크래시 워커의 잡을 회수할 수 있게 합니다. 잡 메타데이터(페이로드, 상태, 시도 횟수, 결과)는 해시에 저장되고, 완료된 잡은 TTL로 자동 정리됩니다.

  • LPUSH와 BRPOPLPUSH(또는 BLMOVE)로 원자적 인큐·블로킹 클레임 — 워커가 잡을 디큐하고 processing 리스트에 등록하는 것을 단일 왕복으로
  • Lists로 processing 리스트 가시성 타임아웃 패턴 — 잡이 pending→processing으로 원자 이동, 회수자가 타임아웃 잡을 스캔해 되돌림
  • Sorted sets(ZADD, ZRANGEBYSCORE)로 실행 시각·우선순위 점수 기반 지연 실행·우선순위 큐
  • Streams + consumer groups로 독립적 진행 추적과 함께 여러 워커 풀에 팬아웃
  • Hashes로 잡 메타데이터 저장 + EXPIRE로 완료 잡 자동 정리
  • Pub/Sub(PUBLISH, SUBSCRIBE)로 잡 완료 시그널링 — 폴링 없이 제출자에게 알림
  • 인큐·디큐의 서브 밀리초 대기 시간으로 프로듀서 측 비용 절감

에코시스템

더 알아보기 (Learn more)

  • Redis 잡 큐를 직접 만드는 코드 예제: redis-py, node-redis, go-redis, Jedis, Lettuce, StackExchange.Redis, Predis, redis-rb, redis-rs — 각 라이브러리용 실행 가능한 인터랙티브 데모.
  • Redis Lists — 큐·스택의 기본 구조.
  • Redis Streams — 컨슈머 그룹과 지속적 스트림 처리.