대부분의 GitLab 인스턴스는 모든 프로세스가 모든 큐를 수신하도록 구성해야 합니다.

또 다른 방법은 라우팅 규칙을 사용해 애플리케이션 내부의 특정 job 클래스를 직접 구성한 큐 이름으로 보내는 것입니다. 이렇게 하면 Sidekiq 프로세스가 구성된 큐 몇 개만 수신하면 됩니다. 그 결과 Redis 부하가 줄어들며, 이는 대규모 배포에서 중요합니다.

라우팅 규칙#

히스토리

• 기본 라우팅 규칙 값이 GitLab 15.4에서 도입되었습니다.
• 큐 선택기가 GitLab 17.0에서 라우팅 규칙으로 대체되었습니다.

대부분의 GitLab 인스턴스는 라우팅 규칙으로 Sidekiq 큐를 관리하는 것을 권장합니다. 라우팅 규칙을 사용하면 관리자가 job 클래스의 속성을 기준으로 클래스 그룹마다 하나의 큐 이름을 지정할 수 있습니다. 구문은 [query, queue] 쌍의 순서 있는 배열입니다:

1. 쿼리는 워커 매칭 쿼리입니다.
2. 큐 이름은 유효한 Sidekiq 큐 이름이어야 합니다. 큐 이름이 nil 이거나 빈 문자열이면 해당 워커는 워커 이름으로 생성된 큐로 보내집니다. (자세한 내용은 사용 가능한 job 클래스 목록을 참고합니다.) 큐 이름이 사용 가능한 job 클래스 목록에 있는 기존 큐 이름과 일치할 필요는 없습니다.
3. 워커와 일치하는 첫 번째 쿼리가 그 워커에 적용되며, 이후 규칙은 무시됩니다.

라우팅 규칙 마이그레이션#

Sidekiq 라우팅 규칙을 변경한 뒤에는 job을 통째로 잃지 않도록 마이그레이션에 주의해야 하며, 특히 job 대기열이 긴 시스템에서 그렇습니다. 마이그레이션은 Sidekiq job 마이그레이션에 설명된 단계에 따라 수행할 수 있습니다.

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

라우팅 규칙은 애플리케이션 구성의 일부이므로 모든 GitLab 노드(특히 GitLab Rails 노드와 Sidekiq 노드)에서 동일해야 합니다.

상세 예시#

다음은 다양한 가능성을 보여 주기 위한 포괄적인 예시입니다. Helm 차트 예시도 있습니다. 이 예시는 권장 구성이 아닙니다.

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

   sidekiq['routing_rules'] = [
     # Route all non-CPU-bound workers that are high urgency to `high-urgency` queue
     ['resource_boundary!=cpu&urgency=high', 'high-urgency'],
     # Route all database, gitaly and global search workers that are throttled to `throttled` queue
     ['feature_category=database,gitaly,global_search&urgency=throttled', 'throttled'],
     # Route all workers having contact with outside world to a `network-intensive` queue
     ['has_external_dependencies=true|feature_category=hooks|tags=network', 'network-intensive'],
     # Wildcard matching, route the rest to `default` queue
     ['*', 'default']
   ]
   

   그런 다음 queue_groups를 이렇게 생성된 큐 이름에 맞게 설정할 수 있습니다. 예를 들면 다음과 같습니다:

   sidekiq['queue_groups'] = [
     # Run two high-urgency processes
     'high-urgency',
     'high-urgency',
     # Run one process for throttled, network-intensive
     'throttled,network-intensive',
     # Run one 'catchall' process on the default and mailers queues
     'default,mailers'
   ]
   

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

   sudo gitlab-ctl reconfigure
   

워커 매칭 쿼리#

GitLab은 라우팅 규칙에서 워커를 속성 기준으로 매칭하는 쿼리 구문을 제공합니다. 쿼리는 두 가지 요소로 이루어집니다:

• 선택할 수 있는 속성입니다.
• 쿼리를 구성하는 연산자입니다.

사용 가능한 속성#

큐 매칭 쿼리는 GitLab 개발 문서의 Sidekiq 스타일 가이드에 설명된 워커 속성을 대상으로 동작합니다. 워커 속성 중 다음 일부를 기준으로 쿼리할 수 있습니다:

• feature_category - 해당 큐가 속한 GitLab 기능 카테고리입니다. 예를 들어 merge 큐는 source_code_management 카테고리에 속합니다.
• has_external_dependencies - 큐가 외부 서비스에 연결되는지 여부입니다. 예를 들어 모든 임포터는 이 값이 true 입니다.
• urgency - 이 큐의 job이 얼마나 빠르게 실행되어야 하는지를 나타냅니다. high, low, throttled 중 하나입니다. 예를 들어 authorized_projects 큐는 사용자 권한을 갱신하는 데 사용되며 high 긴급도입니다.
• worker_name - 워커 이름입니다. 특정 워커를 선택할 때 이 속성을 사용합니다. 사용 가능한 모든 이름은 아래 job 클래스 목록에서 확인할 수 있습니다.
• name - 워커 이름에서 생성된 큐 이름입니다. 특정 큐를 선택할 때 이 속성을 사용합니다. 이 값은 워커 이름에서 생성되므로 다른 라우팅 규칙의 결과에 따라 바뀌지 않습니다.
• resource_boundary - 큐가 cpu, memory, unknown 중 무엇에 의해 제한되는지를 나타냅니다. 예를 들어 ProjectExportWorker는 내보내기를 위해 저장하기 전에 데이터를 메모리에 올려야 하므로 메모리 제약을 받습니다.
• tags - 큐에 붙는 수명이 짧은 주석입니다. 릴리스마다 자주 바뀔 수 있고 아예 제거될 수도 있습니다.
• queue_namespace - 일부 워커는 네임스페이스로 묶이며 name 앞에 <queue_namespace>:가 붙습니다. 예를 들어 큐 name 이 cronjob:admin_email 이면 queue_namespace는 cronjob 입니다. 워커 그룹을 선택할 때 이 속성을 사용합니다.

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보다 높은 우선순위로 만들 수는 없습니다.

앞서 설명한 표준 큐 그룹 구문과 마찬가지로, 큐 그룹 전체가 * 하나면 모든 큐를 선택합니다.

Rails 콘솔에서 라우팅 규칙 테스트#

Rails 콘솔에서 다음을 실행하면 주어진 쿼리와 일치하는 워커를 확인할 수 있습니다:

matcher = Gitlab::SidekiqConfig::WorkerMatcher.new("feature_category=global_search")
Gitlab::SidekiqConfig.workers
  .select { |w| matcher.match?(w.to_yaml) }
  .map(&:klass)

쿼리 문자열을 유효한 워커 매칭 쿼리로 바꾸면 다른 라우팅 규칙을 테스트할 수 있습니다.

필요한 쿼리 매개변수는 사용 가능한 job 클래스 목록에서 확인합니다.

사용 가능한 job 클래스 목록#

기존 Sidekiq job 클래스와 큐 목록은 다음 파일에서 확인합니다:

• 모든 GitLab 에디션의 큐
• GitLab Enterprise Edition 전용 큐