⚙️

Sidekiq는 어떻게 동작하나?

Redis 기반 백그라운드 잡 큐 시스템

Sidekiq는 Ruby의 대표적인 백그라운드 잡 프로세서입니다. 웹 요청 중 시간이 오래 걸리는 작업을 Redis 큐에 직렬화된 잡으로 넣으면(perform_async), 별도의 Sidekiq 워커 프로세스가 멀티스레드로 큐에서 잡을 꺼내 처리합니다. 웹 프로세스는 즉시 응답을 반환할 수 있고, 실제 작업은 백그라운드에서 이뤄집니다. 실패한 잡은 자동 재시도되며, Dead 상태로 빠진 잡은 웹 UI에서 모니터링 가능합니다.

구조 다이어그램

🌐

Web Process

Rails / Puma

MyWorker.perform_async(id)

① LPUSH (enqueue) →

🗄️

Redis

queue:default queue:mailers retry set dead set

② BRPOP (dequeue) →

⚙️

Sidekiq Worker

멀티스레드 프로세스

Thread 1: 이메일 Thread 2: 인코딩 Thread 3: 대기

실패 시 재시도 흐름:

실패 → retry 큐 (exponential backoff) → 25회 재시도 → Dead 큐

핵심 포인트

웹 프로세스와 워커 프로세스는 별도 프로세스 (같은 코드베이스)
Redis가 큐 역할 — 잡은 JSON으로 직렬화
BRPOP: 큐가 비어있으면 블로킹 대기 (폴링 아님)
워커는 멀티스레드로 동시에 여러 잡 처리

동작 흐름

웹 요청에서 MyWorker.perform_async(args) 호출

잡 정보가 JSON으로 직렬화되어 Redis 큐에 LPUSH

Sidekiq 워커 프로세스가 Redis에서 BRPOP으로 잡 꺼냄

워커가 perform(args) 메서드 실행 (별도 스레드)

성공 시 잡 제거, 실패 시 retry 큐로 이동 (exponential backoff)

최대 재시도 초과 시 Dead 큐로 이동 (수동 확인 필요)

장점

✓ 웹 응답 속도 개선 (무거운 작업 분리)
✓ 자동 재시도 (exponential backoff)
✓ 멀티스레드로 높은 처리량
✓ Sidekiq Web UI로 모니터링

단점

✗ Redis 의존 (Redis 다운 = 잡 처리 중단)
✗ 잡 직렬화 제약 (복잡한 객체 전달 불가)
✗ 멀티스레드 안전성 주의
✗ 중복 실행 가능성 (멱등성 필요)

사용 사례

이메일/알림 발송 이미지/동영상 인코딩 외부 API 호출 (결제, 배송) CSV/PDF 대량 생성 데이터 동기화/정리

기반 아키텍처

📬

Message Queue

큐를 통한 비동기 작업 처리

→