Sidekiq 제한 용량 워커
LimitedCapacity::Worker concern을 사용하여 워커 클래스의 동시 실행 작업 수를 제한할 수 있습니다.
워커는 세 가지 메서드를 구현해야 합니다.
-
perform_work: 해당 concern은 일반적인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에서)을 주기적으로 실행하는 경우입니다. 이 경우 추가적인 cron 워커가 주기적으로 워커를 시작해야 합니다. 예를 들어, 다음 스케줄러에서:
class ScheduleMyDummyCronWorker
include ApplicationWorker
include CronjobQueue
def perform
MyDummyWorker.perform_with_capacity
end
end
실행 중인 작업 수는 얼마나 되나요?
거의 항상 max_running_jobs를 실행합니다.
cron 워커는 각 실행 시 남은 용량을 확인하고 대부분 max_running_jobs 작업을 예약합니다. 완료된 이러한 작업은 즉시 자체를 다시 대기열에 넣지만 장애 발생 시에는 그렇지 않습니다. cron 워커는 이러한 실패한 작업을 대체하는 역할을 합니다.
오류 처리와 동형성
이 concern은 Sidekiq 재시도를 비활성화하고 오류를 로그에 기록한 다음 작업을 dead 대기열로 전송합니다. 이는 작업을 생성하는 소스가 하나뿐이어야 하고 재시도가 먼 미래에 수행될 작업이 슬롯을 차지하는 것을 막기 위해 수행됩니다.
cron 워커에게 새로운 작업을 큐잉하도록 하므로 이것을 우리의 재시도 및 배제 메커니즘으로 볼 수 있습니다. 왜냐하면 작업이 즉시 실행되면 다시 실패할 수 있기 때문입니다. 이는 각 실패한 작업에 대해 용량이 줄어들게 되어 계속해서 더 낮은 용량으로 실행됨을 의미합니다. 워커에게 백로그가 없어야 하는 경우 #perform_work에서 예외를 처리하고 작업이 발생하지 않도록해야 합니다.
작업은 :none 전략을 사용하여 중복 처리되지만 워커는 idempotent!로 표시되지 않습니다.
메트릭
이 concern은 워커 클래스 이름을 라벨로 사용하는 gauge 유형의 프로메테우스 메트릭을 세 개 노출합니다.
limited_capacity_worker_running_jobslimited_capacity_worker_max_running_jobslimited_capacity_worker_remaining_work_count
대안
제한된 용량 워커가 아키텍처에 맞지 않는 경우 concurrency limit 속성을 사용하여 Sidekiq 워커의 동시성을 제한할 수도 있습니다.
도움말