특정 작업 클래스 처리

caution
이것들은 고급 설정입니다. GitLab.com에서 사용되지만 대부분의 GitLab 인스턴스에서는 모든 큐를 수신 대기하는 프로세스를 추가해야 합니다. 이것은 우리가 참조 아키텍처에서 취한 접근 방식과 동일합니다.

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

  1. Routing rules은 GitLab.com에서 사용됩니다. 이는 애플리케이션 내에서 관리자가 구성한 대기열 이름으로 작업을 지시합니다. 이는 매우 대규모의 배포에서 중요한 Redis의 부하를 줄입니다.
  2. Queue selectors은 애플리케이션 외부에서 작업 선택을 수행하며 Sidekiq 프로세스 시작 시 사용되었습니다. 이는 2021년 9월까지 GitLab.com에서 사용되었으며 호환성을 유지하기 위해 유지됩니다.

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

Routing rules

note
Mailer 작업은 라우팅 규칙에 따라 라우팅될 수 없으며 항상 mailers 큐로 이동합니다. 라우팅 규칙을 사용할 때 적어도 하나의 프로세스가 mailers 큐를 수신 대기하도록 해야 합니다. 일반적으로 이것은 default 큐와 함께 배치될 수 있습니다.

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

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

라우팅 규칙 마이그레이션

Sidekiq 라우팅 규칙을 변경한 후에는 특히 작업 큐가 긴 시스템에서 작업을 완전히 잃지 않도록 마이그레이션에 주의해야 합니다. 마이그레이션은 Sidekiq 작업 마이그레이션에 언급된 마이그레이션 단계를 따라 수행할 수 있습니다.

확장된 아키텍처에서의 라우팅 규칙

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

자세한 예제

이것은 서로 다른 가능성을 보여주기 위해 의도된 포괄적인 예제입니다. 권장하는 것은 아닙니다.

  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-intensive` 큐로 라우팅
  ['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

큐 셀렉터(사용 중지됨)

caution
이 기능은 GitLab 15.9에서 사용이 중지되었으며 17.0에서 제거할 예정입니다. 대부분의 인스턴스에서는 모든 프로세스가 모든 큐를 수신 대기하도록 해야 합니다. 또 다른 대안은 라우팅 규칙을 사용하는 것입니다(이는 고급 설정이므로 주의하십시오). 이 변경은 파급 효과가 있는 변경입니다.

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

부정 설정 (사용 중지)

caution
이 기능은 GitLab 15.9에서 사용 중지되었습니다. 17.0에서 제거될 예정입니다. 대부분의 인스턴스에서는 모든 프로세스가 모든 큐를 수신하도록 설정해야 합니다. 다른 대안은 라우팅 규칙을 사용하는 것입니다(이는 고급 설정이므로 경고합니다). 이 변경 사항은 파괴적인 변경입니다.

이 설정을 통해 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']에 [selector, queue_name]의 배열을 추가합니다. 이 “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
note
GitLab을 다시 구성한 후에 즉시 Rake 작업을 실행해야 합니다. GitLab을 다시 구성한 후에는 기존 작업이 처리되지 않으므로 Rake 작업이 작업을 마이그레이션하기 시작해야 합니다.

마이그레이션 예시

아래 예시는 위에 설명한 마이그레이션 과정을 더 잘 설명합니다:

  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. /etc/gitlab/gitlab.rb를 업데이트하여 라우팅 규칙을 사용하도록 urgency 쿼리를 사용합니다: 

    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
caution
동시성 섹션에 설명된대로, min_concurrency와 max_concurrency를 동일한 값으로 설정하는 것을 권장합니다. 예를 들어, 큐 그룹 항목에 대기열 수가 1개이고 min_concurrency를 0으로, max_concurrency를 20으로 설정하면 결과 동시성이 2로 설정됩니다. 동시성이 2는 대부분의 경우에는 너무 낮을 수 있으므로 권장하지 않습니다.

다중 노드 설정

다중 노드 설정의 경우:

  • 모든 GitLab Rails 및 Sidekiq 노드를 동일한 sidekiq['routing_rules'] 설정으로 다시 구성합니다.
  • 노드를 업데이트 및 다시 구성하는 동안 GitLab Rails 및 Sidekiq 노드를 번갈아 가며 사용합니다. 이렇게 하면 새로 구성된 Sidekiq이 마이그레이션 중에 새로운 일꾼을 처리할 준비가 되어 있습니다. 그렇지 않으면 새 일꾼이 마이그레이션 종료시까지 대기 상태에 있습니다.

다음은 세 개의 GitLab Rails 노드와 두 개의 Sidekiq 노드의 예시입니다. 큐 셀렉터(queue selectors)에서 라우팅 규칙(routing rules)로 마이그레이션하는 것을 고려해보겠습니다:

  1. Sidekiq 1에서 단일 노드 설정의 모든 단계를 따릅니다. 반드시 랙(Rake) 작업을 실행하지 마세요. 기존 작업을 마이그레이션하는 런 태스크를 실행하지 마세요.
  2. 외부 로드 밸런서를 구성하여 Rails 1이 트래픽을 받지 않도록 합니다. 이 단계는 Rails 프로세스가 다시 시작되는동안 Rails 1이 어떠한 요청도 처리하지 않도록 합니다. 자세한 내용은 이슈 428794를 참조하세요.
  3. Rails 1에서 /etc/gitlab/gitlab.rb를 업데이트하여 Sidekiq 1과 동일한 sidekiq['routing_rules'] 설정을 사용합니다. Rails 노드에서는 sidekiq['routing_rules']만이 필요합니다.
  4. 외부 로드 밸런서를 다시 등록하여 Rails 1을 다시 사용하도록 구성합니다.
  5. Sidekiq 2 및 Rails 2에 대해 단계 1에서 4를 반복합니다.
  6. Rails 3에 대해 단계 2에서 4를 반복합니다.
  7. 만약 Rails 노드보다 더 많은 Sidekiq 노드가 있는 경우, 나머지 Sidekiq 노드에서 단계 1을 따릅니다.

  8. 랙(Rake) 작업을 실행하여 기존 작업을 마이그레이션합니다: 

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

작업 매칭 쿼리

GitLab은 작업 속성을 기반으로 작업자를 매칭시키는 질의 구문을 제공합니다. 이 질의 구문은 라우팅 규칙 및 큐 셀렉터에서 사용됩니다. 질의에는 두 가지 컴포넌트가 포함됩니다:

  • 선택할 수 있는 속성.
  • 질의를 만들기 위해 사용되는 연산자.

사용 가능한 속성

  • GitLab 13.1에 도입되었습니다 (tags).

큐 매칭 쿼리는 Sidekiq 스타일 가이드에 설명된 작업자 속성을 기반으로 동작합니다. 우리는 작업자 속성의 하위 집합에 기반하여 쿼리를 지원합니다:

  • feature_category - 큐가 속한 GitLab 기능 카테고리 입니다. 예를 들어, merge 큐는 source_code_management 범주에 속합니다.
  • has_external_dependencies - 큐가 외부 서비스에 연결되어 있는지 여부입니다. 예를 들어, 모든 importers는 이를 true로 설정합니다.
  • urgency - 이 큐의 작업이 빠르게 실행되어야 하는 중요성입니다. high, low, 또는 throttled 일 수 있습니다. 예를 들어, authorized_projects 큐는 사용자 권한을 새로 고침하는 데 사용되며 high 긴급성을 가집니다.
  • worker_name - 작업자 이름입니다. 특정 작업자를 선택하는 데 이 속성을 사용합니다. 사용 가능한 작업 클래스 디렉터리에서 모든 사용 가능한 이름을 찾으세요.
  • name - 작업자 이름에서 생성된 큐 이름입니다. 특정 큐를 선택하는 데이 속성을 사용합니다. 다른 라우팅 규칙의 결과에 따라 변경되지 않기 때문에 이 이름이 생성됩니다.
  • resource_boundary - 큐가 cpu, memory, 또는 unknown에 의해 제한되는지 여부입니다. 예를 들어, ProjectExportWorker는 데이터를 내보내기 전에 메모리에 데이터를로드해야 하므로 메모리에 제한됩니다.
  • tags - 큐에 대한 단기 주석입니다. 이러한 주석은 빈번히 릴리스마다 변경되며, 완전히 제거 될 수도 있습니다.

has_external_dependencies는 부울 속성입니다. 정확한 문자열 ‘true’만이 참으로 간주되며, 다른 모든 것은 거짓으로 간주됩니다.

tags은 집합이므로 =는 교차 세트를 확인하고 !=는 분리된 세트를 확인합니다. 예를 들어, tags=a,b는 태그 a, b, 또는 둘 다를 가진 큐를 선택합니다. tags!=a,b는 해당 태그를 가지지 않은 큐를 선택합니다.

사용 가능한 연산자

라우팅 규칙 및 큐 셀렉터는 다음과 같은 연산자를 지원하며, 우선 순위가 높은 것부터 낮은 것까지 나열됩니다:

  • | - 논리 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 작업 클래스 및 큐 디렉터리을 확인하려면 다음 파일을 참조하세요: