특정 잡 클래스 처리

특정 잡 클래스 처리에 대해 설명합니다.

Warning 이 설정들은 고급 설정입니다. GitLab.com에서 사용하고 있기는 하지만, 대부분의 GitLab 인스턴스는 모든 큐를 수신하는 프로세스를 추가하는 방식만 사용해야 합니다. 이는 참조 아키텍처 에서 설명하는 방식과 같습니다. 대부분의 GitLab 인스턴스는 모든 프로세스가 모든 큐를 수신 하도록 구성해야 합니다. 또 다른 방법은 라우팅 규칙 을 사용해 애플리케이션 내부의 특정 job 클래스를 직접 구성한 큐 이름으로 보내는 것입니다. 이렇게 하면 Sidekiq 프로세스가 구성된 큐 몇 개만 수신하면 됩니다. 그 결과 Redis 부하가 줄어들며, 이는 대규모 배포에서 중요합니다. 라우팅 규칙 # 히스토리 기본 라우팅 규칙 값 이 GitLab 15.4에서 도입되었습니다. 큐 선택기가 GitLab 17.0에서 라우팅 규칙으로 대체 되었습니다. Note 메일러 job은 라우팅 규칙으로 보낼 수 없으며 항상 mailers 큐로 들어갑니다. 라우팅 규칙을 사용할 때는 최소 한 개의 프로세스가 mailers 큐를 수신하도록 합니다. 보통 이 큐는 default 큐와 함께 배치할 수 있습니다. 대부분의 GitLab 인스턴스는 라우팅 규칙으로 Sidekiq 큐를 관리하는 것을 권장합니다. 라우팅 규칙을 사용하면 관리자가 job 클래스의 속성을 기준으로 클래스 그룹마다 하나의 큐 이름을 지정할 수 있습니다. 구문은 [query, queue] 쌍의 순서 있는 배열입니다: 쿼리는 워커 매칭 쿼리 입니다. 큐 이름은 유효한 Sidekiq 큐 이름이어야 합니다. 큐 이름이 nil 이거나 빈 문자열이면 해당 워커는 워커 이름으로 생성된 큐로 보내집니다. (자세한 내용은 사용 가능한 job 클래스 목록 을 참고합니다.) 큐 이름이 사용 가능한 job 클래스 목록에 있는 기존 큐 이름과 일치할 필요는 없습니다. 워커와 일치하는 첫 번째 쿼리가 그 워커에 적용되며, 이후 규칙은 무시됩니다. 라우팅 규칙 마이그레이션 # Sidekiq 라우팅 규칙을 변경한 뒤에는 job을 통째로 잃지 않도록 마이그레이션에 주의해야 하며, 특히 job 대기열이 긴 시스템에서 그렇습니다. 마이그레이션은 Sidekiq job 마이그레이션 에 설명된 단계에 따라 수행할 수 있습니다. 확장된 아키텍처에서의 라우팅 규칙 # 라우팅 규칙은 애플리케이션 구성의 일부이므로 모든 GitLab 노드(특히 GitLab Rails 노드와 Sidekiq 노드)에서 동일해야 합니다. 상세 예시 # 다음은 다양한 가능성을 보여 주기 위한 포괄적인 예시입니다. Helm 차트 예시 도 있습니다. 이 예시는 권장 구성이 아닙니다. /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' ], # Rout