Sidekiq 라우팅 규칙을 사용하면 관리자가 특정 백그라운드 job을 기본 큐에서 다른 큐로 재라우팅할 수 있습니다. 기본적으로 GitLab은 백그라운드 job 유형마다 하나의 큐를 사용합니다. GitLab에는 400개가 넘는 백그라운드 job 유형이 있으므로 큐도 400개가 넘습니다.

대부분의 관리자는 이 설정을 변경할 필요가 없습니다. 백그라운드 job 처리량이 특히 많은 환경에서는 GitLab 이 수신 대기하는 큐의 개수 때문에 Redis 성능이 저하될 수 있습니다.

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

1. 이전 큐와 새 큐를 모두 수신 대기합니다.
2. 라우팅 규칙을 업데이트합니다.
3. 변경 사항을 적용하려면 GitLab을 재구성합니다.
4. 큐에 대기 중인 job과 향후 실행될 job을 마이그레이션하는 Rake 태스크를 실행합니다.
5. 이전 큐 수신 대기를 중지합니다.

큐에 대기 중인 job과 향후 실행될 job 마이그레이션#

4단계에서는 Redis에 이미 저장되어 있지만 향후 실행될 예정인 job의 Sidekiq job 데이터 일부를 다시 작성합니다. 향후 실행될 job은 예약된 job과 재시도될 job 두 가지입니다. 각 집합을 마이그레이션하는 별도의 Rake 태스크를 제공합니다.

• 재시도될 job에는 gitlab:sidekiq:migrate_jobs:retry를 사용합니다.
• 예약된 job에는 gitlab:sidekiq:migrate_jobs:schedule을 사용합니다.

아직 실행되지 않은 큐 대기 job도 Rake 태스크로 마이그레이션할 수 있습니다.

• 비동기로 수행될 큐 대기 job에는 gitlab:sidekiq:migrate_jobs:queued를 사용합니다.

대부분의 경우 세 가지를 동시에 실행하는 것이 적절합니다. 태스크가 세 개로 나뉘어 있으므로 필요할 때 더 세밀하게 제어할 수 있습니다. 세 가지를 한 번에 실행하려면 다음 명령을 사용합니다.

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

# source installations
bundle exec rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued RAILS_ENV=production