⏳
Background Jobs
Active Job + Sidekiq — 무거운 작업을 비동기로 처리
Background Job은 HTTP 요청 사이클에서 시간이 걸리는 작업을 분리하여 별도 프로세스에서 처리하는 패턴입니다.
# app/jobs/send_welcome_email_job.rb
class SendWelcomeEmailJob < ApplicationJob
queue_as :default
def perform(user)
UserMailer.welcome(user).deliver_now
end
end
# 사용
SendWelcomeEmailJob.perform_later(user) # 큐에 등록 (비동기)
SendWelcomeEmailJob.perform_now(user) # 즉시 실행 (동기)
Active Job: Rails의 Job 추상화 레이어. 백엔드(어댑터)를 교체해도 코드 변경 불필요.
Sidekiq: 가장 인기있는 Job 어댑터. Redis 기반, 멀티스레드로 높은 처리량.
Solid Queue: Rails 8의 새 기본 어댑터. DB 기반으로 Redis 불필요. 단, 프로세스 기반이라 워커가 기본 3개 뜨면서 약 534MB(178MB×3) 메모리를 점유 — Sidekiq(스레드 기반, 1프로세스)보다 메모리를 훨씬 많이 먹음. Redis가 불필요한 대신 메모리 비용이 큰 트레이드오프.
재시도:
retry_on StandardError, wait: :exponentially_back_off, attempts: 5
discard_on ActiveRecord::RecordNotFound
핵심 포인트
1
rails generate job SendEmail → app/jobs/ 에 Job 클래스 생성
2
perform 메서드에 실행할 로직 작성
3
MyJob.perform_later(args) — 큐에 등록 (비동기 실행)
4
queue_as :high_priority — 큐 우선순위 지정
5
retry_on / discard_on — 재시도/폐기 정책 설정
6
config.active_job.queue_adapter = :sidekiq — 어댑터 설정
장점
- ✓ HTTP 응답 시간 단축 (사용자 경험 향상)
- ✓ 실패 시 자동 재시도
- ✓ 어댑터 교체 용이 (Sidekiq → Solid Queue)
- ✓ 큐별 우선순위 관리
단점
- ✗ 별도 프로세스 관리 필요 (Sidekiq 워커)
- ✗ 디버깅 복잡 (비동기 환경)
- ✗ Redis 의존 (Sidekiq) 또는 DB 부하 (Solid Queue)
- ✗ 순서 보장 어려움
- ✗ Solid Queue + SQLite는 머신 분리 불가 — SQLite는 파일 기반이라 네트워크 공유가 안 되므로 Rails와 Solid Queue가 같은 디스크(같은 머신)에서 실행되어야 함. Fly.io 등에서 볼륨은 하나의 머신에만 마운트 가능하므로 별도 머신으로 분리 불가. PostgreSQL/Redis라면 네트워크 접속이 가능해 머신 분리가 가능
사용 사례
이메일 발송
파일 처리 (이미지 리사이징, PDF 생성)
외부 API 호출
데이터 집계/리포트 생성
CSV 임포트/엑스포트