Solid Queue 붙이기 일기
원래 Sidekiq 붙여서 background job 처리할려 했는데, Redis는 자연스럽게 따라오게 되고 redis 사용하는건 보통 까다로운일이 아닌거같다.
큰거 바라는건 아니지만 sidekiq은 쓰고 싶고…
하지만 최근에 Solid queue가 출시 되었고 이 참에 초기 서비스 만드는데 인프라 비용이나 시간 아낄겸 solid queue를 붙여보았다.
Solid Queue?
Sidekiq은 Redis를 백엔드로 사용하여 작업 큐를 관리하는데 반해 SolidQueue는 sidekiq처럼 별도의 서비스로 동작하면서 PostgresSQL나 MySQL과 같은 데이터베이스를 벡엔드로 해서 작업 큐를 관리한다.
항상 서비스 만들 때 마다 sidekiq붙여서 redis달고 다니던거 db로 퉁칠 수 있는데, 이게 가능한 본질적인 이유는 `FOR UPDATE SKIP LOCKED` 구문 덕분이다.
FOR UPDATE SKIP LOCKED은 SELECT하려는 레코드가 다른 트랜잭션에 의해 이미 잠겨진 상태라면 무시하고 잠금이 걸리지 않은 레코드만 가져오면서 에러를 방출하지 않을 뿐더러 동시성 문제를 해결해주는데, 이는 다중 소비자 큐을 구현하기 적절한 구문이다.
이런 원리를 바탕으로 만들어진 Solid Queue….
이런저런 경험썰
실제 개발시 사용경험은 Sidekiq이랑 차이는 없다. AcitveJob쓰는거니까…
그리고 config 구성에 대해서는 개인적으로 SolidQueue가 더 직관적이고 정돈된 느낌든다. (역시 새술은) 다만 나온지 얼마되지 않아서 문서는 풍부하지 않지만 가볍게 붙여 쓰는 입장에선 부족함 없었다.
https://github.com/rails/solid_queue/blob/main/README.md README.md 문서 따라서 config하면 모든게 끝.
그리고 같이 추가해주면 좋은게 https://github.com/rails/mission_control-jobs 인데 sidekiq이랑 UI/UX 측면에서 큰차이는 없고 클라이언트 개발 오래해온 입장에선 solid queue의 mission control jobs에 손을 들어주고싶..
다만 최소 solid queue 0.2.1 version 이상을 사용하는걸 권장한다. job이 제거되지 않거나 retry되지 않는 버그가 있어서 괜히 딥다이브해서 삽질좀 했는데 solid queue version 이슈였다는거…
그리고 admin 권한있는 사용자에 한해서 동작할 수 있도록 mission control에서 base_controller_class 설정할 수 있도록 제공도 해주는데, ApplicationController 하나 적절히 subclassing하거나 기존에 있는 admin 관련 base controller 있으면 지정해주면 된다. (해야한다 일반 사용자들이 접근못하게 ㅋㅋ)
config.mission_control.jobs.base_controller_class = "BlahBlahController"이 과정에서 좀 고달팠던건… 날먹 개발할려고 Active Admin 신나게 쓰고 있었는데 공식문서가 아주 빻아서… (물론 없지는 않고 대충있음)이 mission control이랑 active admin 둘이 붙인다고 머리를 좀 많이 굴렸다. (이 때 iOS개발 살짝 그리웠음?)
또 다른 rails 엔지니어가 삽질하지 않도록 그냥 소소한 팁 남기자면 before_action으로 authenticate_admin_user! 호출 해주면 모든게 해결된다 🥹🥹🥹🥹🥹
class AdminBaseController < ApplicationController
before_action :authenticate_admin_user!
end마무리
Rails 8.0 마일스톤에 solid queue가 queue되었는데 앞으로도 많은 발전 거듭하길 기원한다.
아직 수면내시경 후유증있어서 오늘 레일즈 일기는 여기까지 끝
