Sidekiq 작업 이전 Rake 작업

Tier: Free, Premium, Ultimate Offering: Self-managed
caution
이 작업은 매우 드문 경우여아만 해야 합니다. GitLab의 대다수 인스턴스에는 권장하지 않습니다.

Sidekiq 라우팅 규칙을 사용하면 관리자가 특정 백그라운드 작업을 일반 대기열에서 대체 대기열로 다시 라우팅할 수 있습니다. 기본적으로 GitLab은 백그라운드 작업 유형당 하나의 대기열을 사용합니다. GitLab에는 400개가 넘는 백그라운드 작업 유형이 있으므로 이에 상응하여 400개가 넘는 대기열이 있습니다.

대부분의 관리자는 이 설정을 변경할 필요가 없습니다. 특히 매우 큰 백그라운드 작업 처리 작업 부하가 있는 경우 GitLab이 수신하는 대기열의 수로 인해 Redis 성능에 영향을 줄 수 있습니다.

Sidekiq 라우팅 규칙을 변경하는 경우, 관리자는 작업을 완전히 잃지 않도록 이주에 주의해야 합니다. 기본적인 마이그레이션 단계는 다음과 같습니다:

  1. 이전 및 새 대기열 양쪽에서 수신합니다.
  2. 라우팅 규칙을 업데이트합니다.
  3. 변경 사항이 적용되도록 GitLab을 다시 구성합니다.
  4. 대기 중 및 예정된 작업을 이주하기 위해 Rake 작업을 실행합니다.
  5. 이전 대기열 수신을 중지합니다.

대기 중 및 예정된 작업을 이주하기

4단계는 Redis에 이미 저장된 향후 실행 예정이지만 어떤 이유로 인해 Sidekiq 작업 데이터를 다시 작성해야 하는 작업과 관련이 있습니다. 처리될 예정인 세트 작업과 재시도할 작업 세트가 있습니다. 각 세트에 대해 별도의 Rake 작업을 제공합니다.

  • 재시도할 작업인 경우 gitlab:sidekiq:migrate_jobs:retry입니다.
  • 예정된 작업인 경우 gitlab:sidekiq:migrate_jobs:schedule입니다.

아직 실행되지 않은 대기 중인 작업도 Rake 작업을 사용하여 이주할 수 있습니다 (GitLab 15.6에서 사용 가능):

  • 비동기적으로 수행할 예정인 대기 중인 작업에 대해 gitlab:sidekiq:migrate_jobs:queued입니다.

대부분의 경우, 세 가지 작업을 동시에 실행하는 것이 올바른 선택입니다. 필요한 경우 보다 미세한 제어를 위해 세 가지 작업을 따로 실행할 수 있도록 세 가지 별도 작업이 있습니다. 세 가지를 동시에 실행하려면 (GitLab 15.6에서 사용 가능):

# omnibus-gitlab
sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued

# 소스 설치
bundle exec rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued RAILS_ENV=production