Worker 컨텍스트#

로그에서 worker에 관한 더 많은 정보를 얻기 위해, job에 ApplicationContext 형식의 메타데이터를 추가합니다. 대부분의 경우 요청에서 job을 스케줄링할 때 이 컨텍스트는 이미 요청에서 추론되어 스케줄된 job에 추가됩니다.

job이 실행될 때, 스케줄링 당시 활성화된 컨텍스트가 복원됩니다. 이로 인해 실행 중인 job 내에서 스케줄된 모든 job에 컨텍스트가 전파됩니다.

이 모든 것은 대부분의 경우 job에 컨텍스트를 추가하기 위해 별도로 아무것도 할 필요가 없다는 것을 의미합니다.

그러나 job이 스케줄될 때 컨텍스트가 없거나 잘못된 컨텍스트가 있을 수 있는 경우가 있습니다. 이러한 경우를 위해 RuboCop 규칙을 추가하여 주의를 환기시키고 로그에서 잘못된 메타데이터를 방지합니다.

대부분의 다른 cop들처럼, 이를 비활성화할 타당한 이유가 있을 수 있습니다. 예를 들어 요청의 컨텍스트가 올바른 경우이거나, cop이 감지하지 못하는 방식으로 이미 컨텍스트를 지정한 경우가 있습니다. 어떤 경우든 cop을 비활성화할 때 사용할 컨텍스트를 가리키는 코드 주석을 남겨 두세요.

객체를 컨텍스트에 제공할 때는 네임스페이스와 프로젝트의 라우트가 미리 로드되어 있는지 확인하세요. 이는 모든 Routable에 정의된 .with_route 스코프를 사용하여 수행할 수 있습니다.

Cron worker#

컨텍스트는 크론 job 큐의 worker(include CronjobQueue)에 대해 자동으로 초기화되며, 요청에서 스케줄링하는 경우에도 마찬가지입니다. 이는 cron worker에서 다른 job이 스케줄될 때 잘못된 메타데이터를 방지하기 위해 수행합니다.

Cron worker 자체는 인스턴스 전체에서 실행되므로 사용자, 네임스페이스, 프로젝트 또는 컨텍스트에 추가해야 하는 다른 리소스로 범위가 지정되지 않습니다.

그러나 컨텍스트가 필요한 서비스를 실행하거나 다른 job을 스케줄링하는 경우가 많습니다.

그렇기 때문에 worker 어딘가에 컨텍스트에 대한 표시가 있어야 합니다. 이는 worker 내의 어딘가에서 다음 방법 중 하나를 사용하여 수행할 수 있습니다:

• with_context 헬퍼에 job을 스케줄링하는 코드를 감싸는 방법:

  def perform
    deletion_cutoff = Gitlab::CurrentSettings
                        .deletion_adjourned_period.days.ago.to_date
    projects = Project.with_route.with_namespace
                 .marked_for_deletion_before(deletion_cutoff)

    projects.find_each(batch_size: 100).with_index do |project, index|
      delay = index * INTERVAL

      with_context(project: project) do
        AdjournedProjectDeletionWorker.perform_in(delay, project.id)
      end
    end
  end

• 컨텍스트를 제공하는 배치 스케줄링 메서드를 사용하는 방법:

  def schedule_projects_in_batch(projects)
    ProjectImportScheduleWorker.bulk_perform_async_with_contexts(
      projects,
      arguments_proc: -> (project) { project.id },
      context_proc: -> (project) { { project: project } }
    )
  end

또는 지연을 포함하여 스케줄링하는 경우:

  diffs.each_batch(of: BATCH_SIZE) do |diffs, index|
    DeleteDiffFilesWorker
      .bulk_perform_in_with_contexts(index *  5.minutes,
                                     diffs,
                                     arguments_proc: -> (diff) { diff.id },
                                     context_proc: -> (diff) { { project: diff.merge_request.target_project } })
  end

대량 스케줄된 job#

대량으로 job을 스케줄링할 때 이러한 job들은 상위 컨텍스트 대신 각각의 별도 컨텍스트를 가져야 하는 경우가 많습니다.

그런 경우에는 bulk_perform_async를 bulk_perform_async_with_context 헬퍼로 대체하고, bulk_perform_in 대신 bulk_perform_in_with_context를 사용하면 됩니다.

예를 들면:

    ProjectImportScheduleWorker.bulk_perform_async_with_contexts(
      projects,
      arguments_proc: -> (project) { project.id },
      context_proc: -> (project) { { project: project } }
    )

첫 번째 인수의 열거 가능한 객체로부터 각 객체는 2개의 블록에 yield됩니다:

• arguments_proc: job을 스케줄링할 때 필요한 인수 목록을 반환해야 합니다.

• context_proc: job에 대한 컨텍스트 정보가 담긴 해시를 반환해야 합니다.

인수 로깅#

Sidekiq job 인수는 SIDEKIQ_LOG_ARGUMENTS가 비활성화되지 않은 한 기본적으로 로깅됩니다.

기본적으로 로깅되는 인수는 숫자형 인수뿐인데, 다른 타입의 인수에는 민감한 정보가 포함될 수 있기 때문입니다. 이를 재정의하려면 worker 내에서 loggable_arguments에 로깅할 인수의 인덱스를 지정하면 됩니다. (숫자형 인수는 여기에 지정할 필요가 없습니다.)

예를 들면:

class MyWorker
  include ApplicationWorker

  loggable_arguments 1, 3

  # object_id will be logged as it's numeric
  # string_a will be logged due to the loggable_arguments call
  # string_b will be filtered from logs
  # string_c will be logged due to the loggable_arguments call
  def perform(object_id, string_a, string_b, string_c)
  end
end