Redis를 떠나 SolidQueue로? Rails 개발자들의 선택은?
Basecamp가 MySQL 환경을 위해 Redis 기반의 Sidekiq 대신 SolidQueue를 채택하면서, Rails 개발 생태계에 변화가 감지됨
SolidQueue는 RDBMS(관계형 데이터베이스 관리 시스템) 기반으로, Redis 의존성을 제거하여 시스템 단순화를 추구함
커뮤니티에서는 확장성(Scalability) 문제와 UI 부재를 단점으로 지적하며, Sidekiq, GoodJob 등 기존 솔루션과의 비교가 이루어짐
데이터베이스 연결 풀(Connection Pool) 관리 필요성, Redis 기반의 데이터 격리 아키텍처(Data Isolation Architecture) 장점 등 기술적 트레이드 오프(Trade-offs)에 대한 논의가 활발함
SolidQueue 도입 배경: MySQL 환경과 Rails의 선택
Basecamp는 MySQL 환경에서 RDBMS(관계형 데이터베이스 관리 시스템) 엔진 특정 쿼리 사용을 지양하는 정책을 가지고 있다. Rails 생태계에서 Redis 기반의 Sidekiq 대신 SolidQueue를 선택한 배경에는 이러한 정책이 크게 작용했다. 데이터베이스 독립성(Database Independence)을 유지하면서, 시스템의 복잡성을 줄이려는 의도로 풀이된다. 하지만, SolidQueue는 배치 작업(Batch Jobs) 지원이 미흡하다는 단점이 존재한다.
Redis vs RDBMS: 기술적 트레이드 오프
Redis를 사용하는 경우, 인메모리 데이터베이스(In-memory Database)의 빠른 성능을 활용할 수 있지만, 별도의 인프라 관리 부담이 있다. 반면, SolidQueue와 같이 RDBMS를 사용하는 경우, 데이터베이스 연결 풀(Connection Pool) 관리가 필요하며, 큐(Queue) 처리량에 따라 데이터베이스 부하가 증가할 수 있다. 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 시스템의 안정성을 확보할 수 있다는 장점도 존재한다.
확장성(Scalability) 및 성능 비교
커뮤니티에서는 SolidQueue의 확장성에 대한 우려가 제기되었으며, 특히 대규모 작업 처리 환경에서의 성능 저하 가능성이 언급되었다. Elixir 기반의 Oban은 단일 노드에서 분당 100만 개의 작업을 처리할 수 있는 벤치마크를 제시하며, RDBMS 기반 큐의 성능 잠재력을 보여주었다. 하지만, 대부분의 애플리케이션은 이보다 훨씬 적은 양의 백그라운드 작업을 처리하므로, SolidQueue의 성능이 충분할 수 있다는 의견도 존재한다.
Sidekiq, GoodJob 등 기존 솔루션과의 비교
SolidQueue는 Sidekiq, GoodJob과 비교하여 UI 부재, 미성숙한 기능, 인덱스 최적화 문제 등의 단점을 지적받았다. GoodJob은 성숙한 커뮤니티와 풍부한 기능을 제공하며, Sidekiq는 널리 사용되는 안정적인 솔루션으로 평가받는다. 새로운 프로젝트의 경우 GoodJob을, 기존 Redis 인프라 제거가 목표라면 SolidQueue를 고려해볼 수 있다. 데이터 미저장 정책(Zero-Retention Policy)을 통해 Redis를 활용하는 경우, 백업 부담을 줄일 수 있다.
