Sidekiq 제한 용량 워커
LimitedCapacity::Worker
컨cern을 사용하여 워커 클래스의 동시 실행 작업 수를 제한할 수 있습니다.
이 워커는 세 가지 메서드를 구현해야 합니다:
-
perform_work
: 이 컨cern은 일반적인perform
메서드를 구현하고 사용 가능한 용량이 있을 경우perform_work
를 호출합니다. -
remaining_work_count
: 수행해야 할 작업 수입니다. -
max_running_jobs
: 동시에 실행할 수 있는 작업의 최대 수입니다.
class MyDummyWorker
include ApplicationWorker
include LimitedCapacity::Worker
def perform_work(*args)
end
def remaining_work_count(*args)
5
end
def max_running_jobs
25
end
end
이 워커를 큐에 추가하려면 MyDummyWorker.perform_with_capacity(*args)
를 사용하세요. 이 워커에 전달되는 *args
는 perform_work
메서드에 전달됩니다. 이 작업이 스스로를 조절하고 다시 큐에 추가하는 방식 때문에, 매번 같은 *args
를 제공하는 것이 좋습니다. 실제로 이 유형의 워커는 인수와 함께 사용되지 않는 경우가 많으며, 대신 다른 곳에 저장된 작업량을 소비해야 합니다(예: PostgreSQL). 이러한 설계는 일반 Sidekiq 작업을 인수와 함께 가져와 LimitedCapacity::Worker
로 만드는 데 적합하지 않다는 것을 의미합니다. 대신 사용하려면 큐를 다른 곳에 저장하도록 재설계해야 할 수 있습니다.
이런 종류의 워커에 대한 일반적인 사용 사례는 별도의 작업 대기열(예: PostgreSQL)에서 주기적으로 실행하는 것입니다. 이 경우, 워커를 주기적으로 시작하기 위해 추가적인 크론 워커가 필요합니다. 예를 들어, 다음 스케줄러에서:
class ScheduleMyDummyCronWorker
include ApplicationWorker
include CronjobQueue
def perform
MyDummyWorker.perform_with_capacity
end
end
얼마나 많은 작업이 실행되고 있나요?
거의 모든 시간에 max_running_jobs
가 실행됩니다.
크론 워커는 각 실행 시 남은 용량을 확인하고 최대 max_running_jobs
작업을 예약합니다. 이러한 작업이 완료되면 즉시 스스로 다시 큐에 추가되지만, 실패 시에는 추가되지 않습니다. 크론 워커는 실패한 작업을 대체할 책임이 있습니다.
오류 처리 및 멱등성
이 컨cern은 Sidekiq 재시도를 비활성화하고, 오류를 기록하며, 작업을 데드 큐로 보냅니다. 이는 작업을 생성하는 단일 소스만 두도록 하고, 재시도가 먼 미래에 수행할 작업으로 슬롯을 차지할 수 있기 때문입니다.
우리는 크론 워커가 새로운 작업을 큐에 추가하도록 허용하는데, 이는 즉시 실행될 경우 작업이 다시 실패할 수 있기 때문에 우리의 재시도 및 백오프 메커니즘으로 볼 수 있습니다. 이는 실패한 작업마다 더 낮은 용량으로 실행하며 크론 워커가 용량을 다시 채울 때까지 이어집니다. 워커가 대기열을 받지 않는 것이 중요하다면, #perform_work
에서 예외를 처리해야 하며 작업이 예외를 발생시키지 않아야 합니다.
작업은 :none
전략을 사용하여 중복이 제거되지만, 워커는 idempotent!
로 표시되지 않습니다.
메트릭
이 컨cern은 워커 클래스 이름을 레이블로 사용하는 게이지 유형의 세 가지 Prometheus 메트릭을 노출합니다:
limited_capacity_worker_running_jobs
limited_capacity_worker_max_running_jobs
limited_capacity_worker_remaining_work_count