특정 작업 클래스 처리
경고: 이러한 설정은 고급 설정입니다. GitLab.com에서 사용되지만 대부분의 GitLab 인스턴스는 모든 큐를 수신하는 더 많은 프로세스를 추가해야 합니다. 이는 참조 아키텍처에서 설명한 것과 동일한 방식입니다.
대부분의 GitLab 인스턴스는 모든 프로세스가 모든 큐를 수신하도록 설정해야 합니다.
다른 대안으로는 라우팅 규칙을 사용하는 것이 있습니다. 이를 통해 어플리케이션 내부에서 특정 작업 클래스를 구성한 큐 이름으로 보내도록 지시할 수 있습니다. 그런 다음, Sidekiq 프로세스는 구성된 큐 중 소수의 큐만 수신하면 됩니다. 이렇게 하면 매우 대규모의 배포에서 중요한 Redis의 부하가 줄어듭니다.
라우팅 규칙
참고:
메일러 작업은 라우팅 규칙으로 라우팅할 수 없으며 항상 mailers
큐로 이동합니다. 라우팅 규칙을 사용할 때는 적어도 하나의 프로세스가 mailers
큐를 수신하도록 해야 합니다. 일반적으로 이는 default
큐와 함께 놓일 수 있습니다.
대부분의 GitLab 인스턴스는 Sidekiq 큐를 관리하기 위해 라우팅 규칙을 사용하는 것을 권장합니다. 이를 통해 관리자는 작업 클래스의 속성에 기반하여 그룹화된 단일 큐 이름을 선택할 수 있습니다. 구문은 [쿼리, 큐]
의 순서있는 배열입니다.
- 쿼리는 작업자 일치 쿼리입니다.
- 큐 이름은 유효한 Sidekiq 큐 이름이어야 합니다. 큐 이름이
nil
이거나 빈 문자열인 경우에는 작업자가 자체 이름에서 생성된 큐로 라우팅됩니다. (자세한 정보는 사용 가능한 작업 클래스 목록을 참조하십시오.) 큐 이름은 사용 가능한 작업 클래스 목록에 나열된 기존 큐 이름과 일치할 필요가 없습니다. - 작업자에 대해 첫 번째 일치하는 쿼리가 해당 작업자를위한 작업을 선택하며, 나중 규칙은 무시됩니다.
라우팅 규칙 이전
라우팅 규칙을 변경한 후에는 특히 긴 대기열이 있는 시스템에서 작업을 완전히 잃어버리지 않도록 마이그레이션에 주의해야 합니다. 마이그레이션은 Sidekiq 작업 마이그레이션에서 언급된 마이그레이션 단계를 따라 수행할 수 있습니다.
확장된 아키텍처의 라우팅 규칙
라우팅 규칙은 GitLab 노드(특히 GitLab Rails 및 Sidekiq 노드) 전체에서 동일해야하므로 이들은 어플리케이션 구성의 일부입니다.
자세한 예제
이것은 다양한 가능성을 보여주기 위해 의도된 종합적인 예제입니다. Helm 차트 예제도 사용 가능합니다. 이러한 예제는 권장하는 것은 아닙니다.
-
/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'], # 와일드카드 일치, 나머지를 `default` 큐로 이동합니다 ['*', 'default'] ]
그런 다음,
queue_groups
을 생성된 큐 이름과 일치하도록 설정할 수 있습니다. 예를 들어:sidekiq['queue_groups'] = [ # 두 개의 `high-urgency` 프로세스 실행 'high-urgency', 'high-urgency', # `throttled`, `network-intensive`, `import`를 위한 프로세스 하나 실행 'throttled,network-intensive,import', # `default` 및 `mailers` 큐에 대한 하나의 '일반적인' 프로세스 실행 'default,mailers' ]
-
파일 저장 및 GitLab 재구성:
sudo gitlab-ctl reconfigure
작업자 일치 쿼리
GitLab은 라우팅 규칙에서 사용되는 작업자의 속성에 따라 작업자를 일치시키기 위한 쿼리 구문을 제공합니다.
- 선택된 속성.
- 질의를 작성하는 데 사용되는 연산자.
사용 가능한 속성
큐 일치 쿼리는 Sidekiq 스타일 가이드에서 설명된 작업자 속성에 기반하여 작동합니다. 작업자 속성의 하위 집합을 기반으로 질의를 지원합니다:
-
feature_category
- 큐가 속한 GitLab 기능 범주. 예를 들어,merge
큐는source_code_management
범주에 속합니다. -
has_external_dependencies
- 큐가 외부 서비스에 연결되는지 여부. 예를 들어, 모든 가져오기자는 이를true
로 설정합니다. -
urgency
- 이 큐의 작업이 얼마나 중요한지.high
,low
, 또는throttled
일 수 있습니다. 예를 들어,authorized_projects
큐는 사용자 권한을 새로 고침하는 데 사용되며high
로 분류됩니다. -
worker_name
- 작업자 이름. 특정 작업자를 선택하는 데 이 속성을 사용합니다. 사용 가능한 작업 클래스 목록에서 모든 사용 가능한 이름을 찾을 수 있습니다. -
name
- 작업자 이름에서 생성된 큐 이름. 이 속성을 사용하여 특정 큐를 선택합니다. 이는 작업자 이름에서 생성되므로 다른 라우팅 규칙의 결과에 따라 변경되지 않습니다. -
resource_boundary
- 큐가cpu
,memory
, 또는unknown
로 바인딩되었는지 여부. 예를 들어,ProjectExportWorker
는 데이터를 내보내기 전에 메모리에 데이터를로드해야하므로 메모리에 바인딩됩니다. -
tags
- 큐에 대한 짧은 수명의 주석. 이러한 주석은 릴리스마다 자주 변경되며 완전히 제거 될 수 있습니다.
has_external_dependencies
는 부울 속성입니다. 정확한 문자열 true
만 true로 간주되며 그외의 경우는 모두 false로 간주됩니다.
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 작업 클래스 및 큐의 목록은 다음 파일에서 확인할 수 있습니다.