Sidekiq 작업 이관 Rake 작업

Tier: Free, Premium, Ultimate Offering: Self-managed

경고:
이 작업은 매우 일반적이지 않아야 합니다. 대부분의 GitLab 인스턴스에 대해 권장하지 않습니다.

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

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

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