Sidekiq 작업 마이그레이션 Rake 작업

Tier: Free, Premium, Ultimate

Offering: Self-managed

caution

이 작업은 매우 드물어야 합니다. 우리는 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