Fullscript의 Ruby on Rails 백그라운드 큐잉 시스템: Rescue에서 Solid Queue로의 성공적인 전환

도입

Fullscript는 비즈니스 성장에 따라 기존 백그라운드 큐잉 시스템인 Rescue의 확장성과 안정성 문제(의존성, 워커 중단)에 직면했습니다. 이에 Rails 7.1의 기본 큐 어댑터인 Solid Queue로의 마이그레이션을 결정했습니다. Solid Queue는 데이터베이스 기반의 장점과 Rails 생태계 통합을 통해 기존 문제 해결 및 향후 시스템 성장을 위한 기반을 제공했습니다.

Solid Queue 전환은 Active Job 사용 확인과 Mission Control Jobs 설정으로 시작되었습니다. 프로덕션 환경의 쓰기 부하를 고려, 별도의 MySQL 큐 DB를 구축했습니다. 큐 명명 전략은 지연 허용치(latency tolerance) 기반(예: ‘within one minute’)으로 변경하여 명확한 SLO를 부여하고, 자동 경고 및 리소스 확장을 용이하게 했습니다. 워커는 각 큐에 전용으로 할당하고 부하에 따라 자동 확장되도록 구성했으며, 주요 지표는 Prometheus로 모니터링했습니다.

마이그레이션 중 긴 인자 리스트(DB 컬럼 확장), 메모리 과다(워커 메모리 증설), DB 연결 고갈(DB 크기 증설 및 워커 제한), 느린 작업 유입(실행 시간 모니터링 및 재배치), 대량 작업 동시 인큐잉(배치 처리 및 무작위 지연) 등 여러 문제가 발생했으며, 각 문제에 대한 적절한 해결책을 적용하여 시스템 안정성을 확보했습니다.

결론

Fullscript는 약 두 달간의 마이그레이션 프로젝트를 성공적으로 완료하여 기존 Rescue에서 빈번했던 고볼륨 작업의 실패율을 현저히 감소시키고 시스템 신뢰성을 획기적으로 향상시켰습니다. 현재 하루 약 300만 개의 작업을 처리하며, Solid Queue는 Rescue 대비 뛰어난 성능과 수평적 확장성, SQL 쿼리를 통한 직관적인 가시성을 제공합니다. 특히, 지연 허용치 기반의 큐 명명 전략은 시스템 이해도와 운영 효율성을 크게 증진시켰습니다. Solid Queue로의 성공적인 전환은 Fullscript의 Ruby on Rails 기반 백그라운드 처리 시스템을 더욱 견고하고 효율적으로 만들었습니다.

Fullscript의 Ruby on Rails 백그라운드 큐잉 시스템: Rescue에서 Solid Queue로의 성공적인 전환

RailsConf 2025 From Resque to SolidQueue - Rethinking our background jobs for... by Andrew Markle

핵심 요약

도입

결론

관련 글들

Ruby on Rails 앱의 백그라운드 작업 관리: SolidQ로 Rescue 대체하기

Solid Queue: 37signals의 배경 작업 관리 시스템 전환

루비 백그라운드 작업의 과거, 현재, 그리고 미래

댓글 0

댓글 작성

아직 댓글이 없습니다