Sidekiq 작업 이전 Rake 작업
Sidekiq 라우팅 규칙을 사용하면 관리자가 특정 백그라운드 작업을 일반 대기열에서 대체 대기열로 다시 라우팅할 수 있습니다. 기본적으로 GitLab은 백그라운드 작업 유형당 하나의 대기열을 사용합니다. GitLab에는 400개가 넘는 백그라운드 작업 유형이 있으므로 이에 상응하여 400개가 넘는 대기열이 있습니다.
대부분의 관리자는 이 설정을 변경할 필요가 없습니다. 특히 매우 큰 백그라운드 작업 처리 작업 부하가 있는 경우 GitLab이 수신하는 대기열의 수로 인해 Redis 성능에 영향을 줄 수 있습니다.
Sidekiq 라우팅 규칙을 변경하는 경우, 관리자는 작업을 완전히 잃지 않도록 이주에 주의해야 합니다. 기본적인 마이그레이션 단계는 다음과 같습니다:
- 이전 및 새 대기열 양쪽에서 수신합니다.
- 라우팅 규칙을 업데이트합니다.
- 변경 사항이 적용되도록 GitLab을 다시 구성합니다.
- 대기 중 및 예정된 작업을 이주하기 위해 Rake 작업을 실행합니다.
- 이전 대기열 수신을 중지합니다.
대기 중 및 예정된 작업을 이주하기
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