⚙️
Sidekiq는 어떻게 동작하나?
Redis 기반 백그라운드 잡 큐 시스템
Sidekiq는 Ruby의 대표적인 백그라운드 잡 프로세서입니다. 웹 요청 중 시간이 오래 걸리는 작업을 Redis 큐에 직렬화된 잡으로 넣으면(perform_async), 별도의 Sidekiq 워커 프로세스가 멀티스레드로 큐에서 잡을 꺼내 처리합니다. 웹 프로세스는 즉시 응답을 반환할 수 있고, 실제 작업은 백그라운드에서 이뤄집니다. 실패한 잡은 자동 재시도되며, Dead 상태로 빠진 잡은 웹 UI에서 모니터링 가능합니다.
구조 다이어그램
🌐
웹 프로세스
Rails / Puma
MyWorker.perform_async(id)
① LPUSH (enqueue)
→
🗄️
Redis
queue:default
queue:mailers
retry 셋
dead 셋
② BRPOP (dequeue)
→
⚙️
Sidekiq 워커
멀티스레드 프로세스
Thread 1: 이메일
Thread 2: 인코딩
Thread 3: 대기
실패 시 재시도 흐름:
실패
→
retry 큐 (exponential backoff)
→
25회 재시도
→
Dead 큐
핵심 포인트
- 웹 프로세스와 워커 프로세스는 <strong>별도 프로세스</strong> (같은 코드베이스)
- Redis가 큐 역할 — 잡은 JSON으로 직렬화
- BRPOP: 큐가 비어있으면 블로킹 대기 (폴링 아님)
- 워커는 멀티스레드로 동시에 여러 잡 처리
동작 흐름
1
웹 요청에서 MyWorker.perform_async(args) 호출
2
잡 정보가 JSON으로 직렬화되어 Redis 큐에 LPUSH
3
Sidekiq 워커 프로세스가 Redis에서 BRPOP으로 잡 꺼냄
4
워커가 perform(args) 메서드 실행 (별도 스레드)
5
성공 시 잡 제거, 실패 시 retry 큐로 이동 (exponential backoff)
6
최대 재시도 초과 시 Dead 큐로 이동 (수동 확인 필요)
장점
- ✓ 웹 응답 속도 개선 (무거운 작업 분리)
- ✓ 자동 재시도 (exponential backoff)
- ✓ 멀티스레드로 높은 처리량
- ✓ Sidekiq Web UI로 모니터링
단점
- ✗ Redis 의존 (Redis 다운 = 잡 처리 중단)
- ✗ 잡 직렬화 제약 (복잡한 객체 전달 불가)
- ✗ 멀티스레드 안전성 주의
- ✗ 중복 실행 가능성 (멱등성 필요)
사용 사례
이메일/알림 발송
이미지/동영상 인코딩
외부 API 호출 (결제, 배송)
CSV/PDF 대량 생성
데이터 동기화/정리