Sidekiq worker 속성

Sidekiq worker 클래스에서 동작을 제어하고 메타데이터를 추가하기 위해 설정할 수 있는 속성들을 설명합니다.

Worker 클래스는 특정 속성을 정의하여 동작을 제어하고 메타데이터를 추가할 수 있습니다. 다른 worker를 상속하는 자식 클래스도 이러한 속성을 상속하므로, 값을 재정의하려는 경우에만 다시 정의하면 됩니다. Job 긴급도 # Job에는 urgency 속성을 설정할 수 있으며, 값은 :high , :low , :throttled 중 하나입니다. 각 값의 목표는 아래와 같습니다: 긴급도 큐 스케줄링 목표 실행 지연 요건 :high 10초 10초 :low (기본값) 1분 5분 :throttled 없음 5분 job의 긴급도를 설정하려면 urgency 클래스 메서드를 사용하세요: class HighUrgencyWorker include ApplicationWorker urgency :high # ... end 지연에 민감한 job # 대량의 백그라운드 job이 한꺼번에 스케줄링되면, worker 노드가 사용 가능해질 때까지 job이 큐에 대기하는 상황이 발생할 수 있습니다. 이는 정상적인 현상으로, 트래픽 급증을 우아하게 처리함으로써 시스템에 복원력을 부여합니다. 그러나 일부 job은 다른 job보다 지연에 더 민감합니다. 일반적으로 지연에 민감한 job은 사용자가 백그라운드 worker에서 비동기적으로 처리되는 것이 아닌, 동기적으로 발생할 것이라고 합리적으로 기대할 수 있는 작업을 수행합니다. 일반적인 예로는 어떤 작업 이후의 쓰기 작업이 있습니다. 이러한 job의 예는 다음과 같습니다: 브랜치에 푸시한 후 머지 리퀘스트를 업데이트하는 job. 브랜치에 푸시한 후 프로젝트의 알려진 브랜치 캐시를 무효화하는 job. 권한 변경 후 사용자가 볼 수 있는 그룹 및 프로젝트를 재계산하는 job. 파이프라인의 job 상태가 변경된 후 CI 파이프라인의 상태를 업데이트하는 job. 이러한 job이 지연되면 사용자는 그 지연을 버그로 인식할 수 있습니다. 예를 들어, 브랜치를 푸시한 후 해당 브랜치에 대한 머지 리퀘스트를 생성하려 할 때 UI에서 해당 브랜치가 존재하지 않는다고 표시될 수 있습니다. 이러한 job을 urgency :high 로 분류합니다. 이러한 job이 스케줄링된 후 매우 짧은 시간 내에 시작될 수 있도록 추가적인 노력이 기울여집니다. 그러나 처리량을 보장하기 위해 이러한 job에는 매우 엄격한 실행 시간 요건이 있습니다: 중간값 job 실행 시간은 1초 미만이어야 합니다. 99%의 job은 10초 내에 완료되어야 합니다. worker가 이러한 기대치를 충족할 수 없다면, urgency :high worker로 처리할 수 없습니다. worker를 재설계하거나, 빠르게 실행되는 urgency :high 코드와 실행 지연 요건이 없지만 스케줄링 목표가 낮은 urgency :low 코드를 가진 두 개의 서로 다른 worker로 작업을 분리하는 것을 고려하세요. 큐의 긴급도 변경 # GitLab.com에서는 Sidekiq을 여러 개의 샤드 로 운영하며, 각 샤드는 특정 유형의 워크로드를 나타냅니다. 큐의 긴급도를 변경하거나 새 큐를 추가할