Sidekiq限定作業員

LimitedCapacity::Worker を使用することで、ワーカークラスの同時実行ジョブ数を制限することができます。

ワーカーは3つのメソッドを実装する必要があります:

  • perform_work: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

通常のワーカーに加えて、キューをジョブで埋め戻すために cron ワーカーも定義する必要があります。perform_with_capacity に渡された引数はperform_work メソッドに渡されます。

class ScheduleMyDummyCronWorker
  include ApplicationWorker
  include CronjobQueue

  def perform(*args)
    MyDummyWorker.perform_with_capacity(*args)
  end
end

実行中のジョブの数は?

ほぼ常時、max_running_jobs

cronワーカーは実行のたびに残りの容量をチェックし、最大でもmax_running_jobs 。完了したジョブはすぐに再キューイングされますが、失敗したジョブは再キューイングされません。cronワーカーは失敗したジョブを置き換える役割を担います。

エラーと冪等性の処理

この懸念は、Sidekiqのリトライを無効にし、エラーをログに記録し、ジョブをデッドキューに送ります。これは、ジョブを生成するソースを1つだけにするためと、再試行が遠い将来に実行されるジョブでスロットを占有するためです。

cronワーカーに新しいジョブをエンキューさせますが、これはリトライとバックオフのメカニズムとも言えます。つまり、失敗したジョブごとに、cronワーカーが再び容量を満たすまで、低い容量で実行することになります。もしワーカーがバックログを取得しないことが重要であれば、#perform_work で例外を処理し、ジョブを発生させないようにしなければなりません。

ジョブは:none 戦略を使って重複排除されますが、ワーカーはidempotent! としてマークされません。

メトリクス

この懸念は、ワーカークラス名をラベルとするゲージタイプの Prometheus メトリクスを3つ公開します:

  • limited_capacity_worker_running_jobs
  • limited_capacity_worker_max_running_jobs
  • limited_capacity_worker_remaining_work_count