• 라우팅 규칙
  • 라우팅 규칙 마이그레이션
  • 스케일 아키텍처에서의 라우팅 규칙
  • 자세한 예제
• 대기열 선택기 (사용중단)
  • 대기열 선택기 사용
  • 부정 설정 (사용중단)
• 큐 선택기에서 라우팅 규칙으로 마이그레이션
  • 단일 노드 설정
    • 마이그레이션 예시
  • 다중 노드 설정
  • 사용 가능한 연산자
  • 사용 가능한 작업 클래스 디렉터리

특정 작업 클래스 처리

GitLab에는 특정 작업 클래스만 처리하는 Sidekiq 프로세스를 생성하는 두 가지 옵션이 있습니다:

1. 라우팅 규칙은 GitLab.com에서 사용됩니다. 이 규칙은 응용 프로그램 내에서 작업을 관리자가 구성한 대기열 이름으로 직접 보냅니다. 이를 통해 매우 대규모의 배포에서 중요한 Redis의 부하를 줄일 수 있습니다.
2. 대기열 선택기는 Sidekiq 프로세스 시작 시 응용 프로그램 외부에서 작업 선택을 수행합니다. 이는 2021년 9월까지 GitLab.com에서 사용되었으며 호환성을 유지하기 위해 보존되었습니다.

이 두 가지는 동일한 작업자 매칭 쿼리 구문을 사용합니다. 기술적으로 함께 사용할 수 있지만, 대부분의 배포에서는 한 가지를 선택해야 하며, 둘을 결합하는 것에 특별한 이점은 없습니다.

라우팅 규칙

• 기본 라우팅 규칙 값이 GitLab 15.4에 추가되었습니다.

대부분의 GitLab 인스턴스에서는 라우팅 규칙을 사용하여 Sidekiq 대기열을 관리하는 것이 좋습니다. 이를 통해 관리자는 속성에 기반한 작업 클래스 그룹에 대한 단일 대기열 이름을 선택할 수 있습니다. 구문은 [쿼리, 대기열]의 순서가 있는 배열입니다.

1. 쿼리는 작업자 매칭 쿼리입니다.
2. 대기열 이름은 유효한 Sidekiq 대기열 이름이어야 합니다. 대기열 이름이 nil이거나 빈 문자열인 경우 해당 작업자는 생성된 대기열 이름에 의해 라우팅됩니다. (자세한 내용은 사용 가능한 작업 클래스 디렉터리을 참조하십시오). 대기열 이름은 디렉터리에 있는 작업 클래스의 기존 대기열 이름과 일치할 필요는 없습니다.
3. 작업자에 대한 첫 번째 일치하는 쿼리가 해당 작업자에 대해 선택됩니다. 이후의 규칙은 무시됩니다.

라우팅 규칙 마이그레이션

Sidekiq 라우팅 규칙이 변경된 후, 규칙을 잘 따르지 않으면 특히 작업 대기열이 긴 시스템에서 완전히 작업을 잃지 않으려면 관리자가 마이그레이션에 주의해야 합니다. 마이그레이션은 Sidekiq 작업 마이그레이션에서 언급된 마이그레이션 단계를 따라 수행할 수 있습니다.

스케일 아키텍처에서의 라우팅 규칙

라우팅 규칙은 GitLab 노드 전체에서 동일해야 합니다(특히 GitLab Rails 및 Sidekiq 노드). 대기열 선택기는 시작된 Sidekiq 프로세스의 인수만 변경하므로 GitLab 노드 간에 다를 수 있습니다.

자세한 예제

이것은 다양한 가능성을 보여주기 위한 포괄적인 예제입니다. Helm 차트 예제도 사용할 수 있습니다. 이는 권장 사항이 아닙니다.

1. /etc/gitlab/gitlab.rb를 편집합니다:

   sidekiq['routing_rules'] = [
     # CPU 바운드가 아니고 긴급도가 높은 모든 작업자를 `high-urgency` 대기열로 라우팅
     ['resource_boundary!=cpu&urgency=high', 'high-urgency'],
     # 데이터베이스, gitaly 및 글로벌 검색이 스로틀링된 모든 작업자를 `throttled` 대기열로 라우팅
     ['feature_category=database,gitaly,global_search&urgency=throttled', 'throttled'],
     # 외부와 연락을 가진 모든 작업자를 `network-intenstive` 대기열로 라우팅
     ['has_external_dependencies=true|feature_category=hooks|tags=network', 'network-intensive'],
     # 모든 가져오기 작업자를 작업자 이름에 의해 생성된 대기열로 라우팅, 예를 들어 JiraImportWorker를 `jira_import`, SVNWorker를 `svn_worker`
     ['feature_category=import', 'import'],
     # 와일드카드 매칭, 나머지는 `default` 대기열로 라우팅
     ['*', 'default']
   ]
   

   그런 다음 queue_groups를 이러한 생성된 대기열 이름과 일치하도록 설정할 수 있습니다. 예를 들어:

   sidekiq['queue_selector'] = false
   sidekiq['queue_groups'] = [
     # 높은 긴급도를 가진 프로세스 두 개 실행
     'high-urgency',
     'high-urgency',
     # 스로틀링되고 네트워크 중심적, 가져오기를 위한 프로세스 하나 실행
     'throttled,network-intensive,import',
     # 기본 및 메일러 대기열에 대해 하나의 'catchall' 프로세스 실행
     'default,mailers'
   ]
   

2. 파일을 저장하고 GitLab을 다시 구성합니다:

   sudo gitlab-ctl reconfigure
   

대기열 선택기 (사용중단)

queue_selector 옵션을 사용하면 더 일반적인 방법으로 대기열 그룹을 선택할 수 있습니다. queue_selector를 설정한 후에는 모든 queue_groups가 앞서 언급된 구문을 따라야 합니다.

대기열 선택기 사용

1. /etc/gitlab/gitlab.rb를 편집합니다:

   sidekiq['enable'] = true
   sidekiq['routing_rules'] = [['*', nil]]
   sidekiq['queue_selector'] = true
   sidekiq['queue_groups'] = [
     # CPU 바운드가 아니고 긴급도가 높은 모든 대기열 실행
     'resource_boundary!=cpu&urgency=high',
     # 연속적인 통합 및 페이지 대기열에서 높은 긴급도가 아닌 모든 대기열 실행
     'feature_category=continuous_integration,pages&urgency!=high',
     # 모든 대기열 실행
     '*'
   ]
   

2. 파일을 저장하고 GitLab을 다시 구성합니다:

   sudo gitlab-ctl reconfigure
   

부정 설정 (사용중단)

이를 사용하면 Sidekiq 프로세스를 나열한 것을 제외한 모든 대기열에서 작동하도록 설정할 수 있습니다. 이는 일반적으로 여러 Sidekiq 노드가 있는 경우에만 사용됩니다. 이 예에서는 한 Sidekiq 노드에서 모든 가져오기 관련 작업을 제외합니다.

1. /etc/gitlab/gitlab.rb를 편집합니다:

   sidekiq['routing_rules'] = [['*', nil]]
   sidekiq['negate'] = true
   sidekiq['queue_selector'] = true
   sidekiq['queue_groups'] = [
      "feature_category=importers"
   ]
   

2. 파일을 저장하고 GitLab을 다시 구성합니다:

   sudo gitlab-ctl reconfigure
   

큐 선택기에서 라우팅 규칙으로 마이그레이션

GitLab 배포에는 참조 아키텍처에서와 같이 모든 큐를 수신 대기하는 더 많은 Sidekiq 프로세스를 추가하는 것을 권장합니다. 매우 대규모 배포의 경우 큐 선택기 대신 라우팅 규칙을 권장합니다. 우리는 GitLab.com에서 라우팅 규칙을 사용하고 있으며 Redis에 가해지는 부하를 낮추는 데 도움이 됩니다.

단일 노드 설정

단일 노드 설정에서 큐 선택기에서 라우팅 규칙으로 마이그레이션하는 방법:

1. /etc/gitlab/gitlab.rb에서 열기.
2. sidekiq['queue_selector']를 false로 설정.
3. sidekiq['queue_groups']의 모든 큐 selector를 가져옵니다.
4. 각 selector에 queue_name을 지정하고 [selector, queue_name] 형식으로 배치합니다.
5. sidekiq['routing_rules']을 [selector, queue_name] 항목 배열로 대체합니다.
6. sidekiq['routing_rules']의 마지막 항목으로 ['*', 'default']와 같이 와일드카드 매치를 추가합니다. 이 “catchall” 큐는 default로 명명되어야 합니다.
7. sidekiq['queue_groups']을 queue_name으로 대체합니다.
8. 적어도 하나의 default 큐와 하나 이상의 mailers 큐를 sidekiq['queue_groups']에 추가합니다.

9. 파일을 저장하고 GitLab을 다시 구성합니다.:

   sudo gitlab-ctl reconfigure
   

10. 기존 작업을 마이그레이션하는 Rake 작업 실행:

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

마이그레이션 예시

아래 예시는 위의 마이그레이션 과정을 더 명확히 보여줍니다:

1. /etc/gitlab/gitlab.rb에서 sidekiq['queue_groups']의 urgency 쿼리를 확인합니다. 예시:

   sidekiq['routing_rules'] = []
   sidekiq['queue_selector'] = true
   sidekiq['queue_groups'] = [
     'urgency=high',
     'urgency=low',
     'urgency=throttled',
     '*'
   ]
   

2. 동일한 urgency 쿼리를 사용하여 /etc/gitlab/gitlab.rb를 업데이트하여 라우팅 규칙을 사용합니다.:

   sidekiq['min_concurrency'] = 20
   sidekiq['max_concurrency'] = 20
      
   sidekiq['routing_rules'] = [
     ['urgency=high', 'high_urgency'],
     ['urgency=low', 'low_urgency'],
     ['urgency=throttled', 'throttled_urgency'],
     # 와일드카드 매칭, 나머지는 `default` 큐로 라우트
     ['*', 'default']
   ]
      
   sidekiq['queue_selector'] = false
   sidekiq['queue_groups'] = [
     'high_urgency',
     'low_urgency',
     'throttled_urgency',
     'default,mailers'
   ]
   

3. 파일을 저장하고 GitLab을 다시 구성합니다.:

   sudo gitlab-ctl reconfigure
   

4. 기존 작업을 마이그레이션합니다 Rake 작업 실행:

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

다중 노드 설정

다중 노드 설정의 경우:

• 모든 GitLab Rails 및 Sidekiq 노드를 동일한 sidekiq['routing_rules'] 설정으로 다시 구성합니다.
• 노드를 업데이트하고 다시 구성할 때 GitLab Rails 및 Sidekiq 노드를 번갈아가며 사용합니다. 이렇게 함으로써 새로 구성된 Sidekiq이 마이그레이션 중에 새 큐 세트에서 작업을 소비할 수 있도록합니다. 그렇지 않으면 새 작업은 마이그레이션이 끝날 때까지 대기합니다.

세 개의 GitLab Rails 노드와 두 개의 Sidekiq 노드 예시를 고려해보겠습니다. 큐 선택기에서 라우팅 규칙으로 마이그레이션하려면:

1. Sidekiq 1에서 단일 노드 설정의 모든 단계를 따르되 한 가지 단계만 제외합니다. 네이티브 Rake 작업을 마이그레이션하지 않습니다.
2. 외부 로드 밸런서를 구성하여 Rails 1이 트래픽을 수락하지 않도록합니다. 이 단계는 Rails 프로세스가 다시 시작될 때까지 Rails 1이 요청을 처리하지 않도록합니다. 자세한 내용은 issue 428794을 참조하십시오.
3. Rails 1에서 Sidekiq 1과 동일한 sidekiq['routing_rules'] 설정을 사용하도록 /etc/gitlab/gitlab.rb를 업데이트합니다. Rails 노드에서는 sidekiq['routing_rules']만 필요합니다.
4. 외부 로드 밸런서를 등록하여 Rails 1을 다시 등록합니다.
5. Sidekiq 2와 Rails 2에 대해 단계 1에서 4를 반복합니다.
6. Rails 3에 대해 단계 2에서 4를 반복합니다.
7. 더 많은 Sidekiq 노드가 있는 경우 나머지 Sidekiq 노드에서 단계 1을 따릅니다.

8. 기존 작업을 마이그레이션하는 Rake 작업 실행:

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

사용 가능한 연산자

라우팅 규칙 및 큐 셀렉터는 우선 순위가 높은 순서로 나열된 다음 연산자를 지원합니다.

• | - 논리 OR 연산자입니다. 예를 들어, query_a|query_b (여기서 query_a와 query_b는 다른 연산자로 이루어진 쿼리입니다)는 어느 하나의 쿼리와 일치하는 큐들을 포함합니다.
• & - 논리 AND 연산자입니다. 예를 들어, query_a&query_b (여기서 query_a와 query_b는 다른 연산자로 이루어진 쿼리입니다)는 두 쿼리에 모두 일치하는 큐만을 포함합니다.
• != - NOT IN 연산자입니다. 예를 들어, feature_category!=issue_tracking는 issue_tracking 기능 카테고리에서 모든 큐를 제외합니다.
• = - IN 연산자입니다. 예를 들어, resource_boundary=cpu는 CPU에 바운드된 모든 큐를 포함합니다.
• , - 세트 연결 연산자입니다. 예를 들어, feature_category=continuous_integration,pages는 continuous_integration 카테고리 또는 pages 카테고리에서 모든 큐를 포함합니다. 이 예제는 OR 연산자를 사용하여도 가능하지만, 더 간결하게 표현할 수 있으며 우선 순위가 낮습니다.

이 구문의 연산자 우선 순위는 고정되어 있어 AND의 우선 순위를 OR보다 높게 설정하는 것은 불가능합니다.

위에서 설명한 표준 큐 그룹 구문과 마찬가지로, 단일 *을 전체 큐 그룹으로 선택할 수 있습니다.

사용 가능한 작업 클래스 디렉터리

기존 Sidekiq 작업 클래스 및 큐의 디렉터리은 다음 파일을 확인하세요:

• 모든 GitLab 에디션을 위한 큐
• GitLab 엔터프라이즈 에디션 전용 큐