InfoGrab DocsInfoGrab Docs

Sidekiq 제한 용량 워커

요약

제한 용량 워커에 관한 다음 문서는 일반적으로 인수를 받지 않고 커스텀 큐(예: 작업의 PostgreSQL 백로그)에서 작업을 가져오는 특정 유형의 워커와 관련이 있습니다. LimitedCapacity::Worker concern을 사용하면 워커 클래스에서 동시에 실행되는 job 수를 제한할 수 있습니다.

제한 용량 워커에 관한 다음 문서는 일반적으로 인수를 받지 않고 커스텀 큐(예: 작업의 PostgreSQL 백로그)에서 작업을 가져오는 특정 유형의 워커와 관련이 있습니다. 일반 Sidekiq 워커의 동시성을 제한하는 데 사용할 수 없습니다. 일반 Sidekiq 워커의 동시성을 제한하려면 동시성 제한을 사용하면 됩니다.

LimitedCapacity::Worker concern을 사용하면 워커 클래스에서 동시에 실행되는 job 수를 제한할 수 있습니다.

워커는 세 가지 메서드를 구현해야 합니다:

  • perform_work: concern이 일반적인 perform 메서드를 구현하며, 사용 가능한 용량이 있을 경우 perform_work를 호출합니다.

  • remaining_work_count: 수행할 작업이 있는 job의 수입니다.

  • max_running_jobs: 동시에 실행이 허용되는 최대 job 수입니다.

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)를 사용합니다. 이 워커에 전달된 *argsperform_work 메서드로 전달됩니다. 이 job이 스스로를 스로틀하고 다시 큐에 넣는 방식으로 인해, 모든 사용 시에 항상 동일한 *args를 제공해야 합니다. 실제로 이 유형의 워커는 인수 없이 사용되는 경우가 많으며, 대신 다른 곳(예: PostgreSQL)에 저장된 워크로드를 소비해야 합니다. 이 설계로 인해 인수가 있는 일반 Sidekiq 워크로드를 LimitedCapacity::Worker로 만들기에는 적합하지 않습니다. 이를 사용하려면 큐를 다른 곳에 저장되도록 재설계해야 할 수 있습니다.

이 유형의 워커의 일반적인 사용 사례는 별도의 작업 큐(예: PostgreSQL)를 주기적으로 소비하여 실행되는 경우입니다. 이 경우 워커를 주기적으로 시작하는 추가 cron 워커가 필요합니다. 예를 들어, 다음 스케줄러에서:

class ScheduleMyDummyCronWorker
  include ApplicationWorker
  include CronjobQueue

  def perform
    MyDummyWorker.perform_with_capacity
  end
end

실행 중인 job 수는 얼마나 됩니까?#

거의 항상 max_running_jobs만큼 실행됩니다.

cron 워커는 각 실행 시 남은 용량을 확인하고 최대 max_running_jobs개의 job을 스케줄합니다. 이 job들은 완료 시 즉시 자신을 다시 큐에 넣지만, 실패 시에는 그렇지 않습니다. cron 워커가 실패한 job들을 교체하는 역할을 담당합니다.

오류 처리 및 멱등성#

이 concern은 Sidekiq 재시도를 비활성화하고, 오류를 로깅하며, job을 데드 큐(dead queue)로 보냅니다. 이는 job을 생성하는 소스를 하나만 유지하기 위한 것이며, 재시도가 먼 미래에 수행할 job으로 슬롯을 차지하기 때문입니다.

cron 워커가 새 job을 큐에 넣도록 합니다. 이는 job이 즉시 실행될 경우 다시 실패할 수 있으므로 재시도 및 백오프 메커니즘으로 볼 수 있습니다. 이는 실패한 job마다 cron 워커가 용량을 다시 채울 때까지 더 낮은 용량으로 실행된다는 것을 의미합니다. 워커가 백로그를 쌓지 않는 것이 중요한 경우, #perform_work에서 예외를 처리해야 하며 job이 raise를 발생시키지 않아야 합니다.

job은 :none 전략을 사용하여 중복 제거되지만, 워커는 idempotent!로 표시되지 않습니다.

메트릭#

이 concern은 워커 클래스 이름을 라벨로 하는 게이지 타입의 세 가지 Prometheus 메트릭을 노출합니다:

  • limited_capacity_worker_running_jobs

  • limited_capacity_worker_max_running_jobs

  • limited_capacity_worker_remaining_work_count

Sidekiq 제한 용량 워커

GitLab v19.1
원문 보기
요약

제한 용량 워커에 관한 다음 문서는 일반적으로 인수를 받지 않고 커스텀 큐(예: 작업의 PostgreSQL 백로그)에서 작업을 가져오는 특정 유형의 워커와 관련이 있습니다. LimitedCapacity::Worker concern을 사용하면 워커 클래스에서 동시에 실행되는 job 수를 제한할 수 있습니다.

제한 용량 워커에 관한 다음 문서는 일반적으로 인수를 받지 않고 커스텀 큐(예: 작업의 PostgreSQL 백로그)에서 작업을 가져오는 특정 유형의 워커와 관련이 있습니다. 일반 Sidekiq 워커의 동시성을 제한하는 데 사용할 수 없습니다. 일반 Sidekiq 워커의 동시성을 제한하려면 동시성 제한을 사용하면 됩니다.

LimitedCapacity::Worker concern을 사용하면 워커 클래스에서 동시에 실행되는 job 수를 제한할 수 있습니다.

워커는 세 가지 메서드를 구현해야 합니다:

  • perform_work: concern이 일반적인 perform 메서드를 구현하며, 사용 가능한 용량이 있을 경우 perform_work를 호출합니다.

  • remaining_work_count: 수행할 작업이 있는 job의 수입니다.

  • max_running_jobs: 동시에 실행이 허용되는 최대 job 수입니다.

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)를 사용합니다. 이 워커에 전달된 *argsperform_work 메서드로 전달됩니다. 이 job이 스스로를 스로틀하고 다시 큐에 넣는 방식으로 인해, 모든 사용 시에 항상 동일한 *args를 제공해야 합니다. 실제로 이 유형의 워커는 인수 없이 사용되는 경우가 많으며, 대신 다른 곳(예: PostgreSQL)에 저장된 워크로드를 소비해야 합니다. 이 설계로 인해 인수가 있는 일반 Sidekiq 워크로드를 LimitedCapacity::Worker로 만들기에는 적합하지 않습니다. 이를 사용하려면 큐를 다른 곳에 저장되도록 재설계해야 할 수 있습니다.

이 유형의 워커의 일반적인 사용 사례는 별도의 작업 큐(예: PostgreSQL)를 주기적으로 소비하여 실행되는 경우입니다. 이 경우 워커를 주기적으로 시작하는 추가 cron 워커가 필요합니다. 예를 들어, 다음 스케줄러에서:

class ScheduleMyDummyCronWorker
  include ApplicationWorker
  include CronjobQueue

  def perform
    MyDummyWorker.perform_with_capacity
  end
end

실행 중인 job 수는 얼마나 됩니까?#

거의 항상 max_running_jobs만큼 실행됩니다.

cron 워커는 각 실행 시 남은 용량을 확인하고 최대 max_running_jobs개의 job을 스케줄합니다. 이 job들은 완료 시 즉시 자신을 다시 큐에 넣지만, 실패 시에는 그렇지 않습니다. cron 워커가 실패한 job들을 교체하는 역할을 담당합니다.

오류 처리 및 멱등성#

이 concern은 Sidekiq 재시도를 비활성화하고, 오류를 로깅하며, job을 데드 큐(dead queue)로 보냅니다. 이는 job을 생성하는 소스를 하나만 유지하기 위한 것이며, 재시도가 먼 미래에 수행할 job으로 슬롯을 차지하기 때문입니다.

cron 워커가 새 job을 큐에 넣도록 합니다. 이는 job이 즉시 실행될 경우 다시 실패할 수 있으므로 재시도 및 백오프 메커니즘으로 볼 수 있습니다. 이는 실패한 job마다 cron 워커가 용량을 다시 채울 때까지 더 낮은 용량으로 실행된다는 것을 의미합니다. 워커가 백로그를 쌓지 않는 것이 중요한 경우, #perform_work에서 예외를 처리해야 하며 job이 raise를 발생시키지 않아야 합니다.

job은 :none 전략을 사용하여 중복 제거되지만, 워커는 idempotent!로 표시되지 않습니다.

메트릭#

이 concern은 워커 클래스 이름을 라벨로 하는 게이지 타입의 세 가지 Prometheus 메트릭을 노출합니다:

  • limited_capacity_worker_running_jobs

  • limited_capacity_worker_max_running_jobs

  • limited_capacity_worker_remaining_work_count