특정 잡 클래스 처리

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

Warning 이것들은 고급 설정입니다. GitLab.com에서 사용되지만 대부분의 GitLab 인스턴스는 모든 큐를 수신하는 프로세스만 추가해야 합니다. 이것이 참조 아키텍처 에 설명된 것과 동일한 접근 방식입니다. 대부분의 GitLab 인스턴스는 모든 큐를 수신하는 모든 프로세스 를 사용해야 합니다. 다른 대안으로 라우팅 규칙 을 사용할 수 있으며, 이는 애플리케이션 내의 특정 잡 클래스를 구성한 큐 이름으로 직접 라우팅합니다. 그러면 Sidekiq 프로세스는 구성된 큐의 일부만 수신하면 됩니다. 이렇게 하면 Redis의 부하가 줄어들어 대규모 배포에서 중요합니다. 라우팅 규칙 # 히스토리 GitLab 15.4에서 기본 라우팅 규칙 값 도입됨. GitLab 17.0에서 큐 선택기가 라우팅 규칙으로 대체 됨. Note Mailer 잡은 라우팅 규칙으로 라우팅할 수 없으며 항상 mailers 큐로 이동합니다. 라우팅 규칙을 사용할 때 적어도 하나의 프로세스가 mailers 큐를 수신하고 있는지 확인합니다. 일반적으로 이는 default 큐와 함께 배치할 수 있습니다. Sidekiq 큐를 관리하기 위해 라우팅 규칙을 사용하는 대부분의 GitLab 인스턴스를 권장합니다. 이를 통해 관리자는 속성을 기반으로 잡 클래스 그룹에 대한 단일 큐 이름을 선택할 수 있습니다. 구문은 [query, queue] 쌍의 정렬된 배열입니다: 쿼리는 워커 일치 쿼리 입니다. 큐 이름은 유효한 Sidekiq 큐 이름이어야 합니다. 큐 이름이 nil 이거나 빈 문자열이면 워커는 워커 이름으로 생성된 큐로 라우팅됩니다. (자세한 내용은 사용 가능한 잡 클래스 목록 참조). 큐 이름은 사용 가능한 잡 클래스 목록의 기존 큐 이름과 일치하지 않아도 됩니다. 워커와 일치하는 첫 번째 쿼리가 해당 워커에 선택되며, 이후 규칙은 무시됩니다. 라우팅 규칙 마이그레이션 # Sidekiq 라우팅 규칙이 변경된 후, 특히 잡 큐가 긴 시스템에서 잡을 완전히 잃지 않도록 마이그레이션에 주의를 기울여야 합니다. 마이그레이션은 Sidekiq 잡 마이그레이션 에서 언급한 마이그레이션 단계를 따라 수행할 수 있습니다. 스케일링된 아키텍처에서의 라우팅 규칙 # 라우팅 규칙은 애플리케이션 구성의 일부이므로 모든 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' ], # Route all database, gitaly and global search