Sidekiq 개발 가이드라인

GitLab에서 Sidekiq 백그라운드 job 처리기를 사용하여 워커 클래스를 작성하는 방법과 각종 설정, 재시도, 동시성 제한, 큐 관리 등을 설명합니다.

우리는 Sidekiq 을 백그라운드 job 처리기로 사용합니다. 이 가이드는 GitLab.com에서 잘 동작하고 기존 워커 클래스와 일관성을 유지하는 job을 작성하기 위한 것입니다. GitLab 관리에 대한 정보는 Sidekiq 설정 을 참고하세요. 다음 주제에 대한 상세 내용이 담긴 페이지가 있습니다: 업데이트 간 호환성 Job 멱등성 및 job 중복 제거 제한된 용량 워커: 지정된 동시성으로 작업 지속 수행 로깅 워커 속성 **Job 긴급도(urgency)**는 큐잉 및 실행 SLO를 지정합니다. 리소스 경계 및 외부 의존성 은 워크로드를 설명합니다. 기능 분류 데이터베이스 로드 밸런싱 ApplicationWorker # 모든 워커는 Sidekiq::Worker 대신 ApplicationWorker 를 포함해야 합니다. ApplicationWorker 는 편의 메서드를 추가하고 라우팅 규칙 에 따라 큐를 자동으로 설정합니다. Cells 호환성 # GitLab.com은 서로 다른 조직이 GitLab의 별개 물리 인스턴스에 의해 서비스되는 Cells 아키텍처 로 이동 중입니다. 모든 Sidekiq job은 단일 조직 범위로 지정되어야 합니다. 단일 조직으로 컴퓨트 범위를 지정하는 방법에 대한 가이드는 Current.organization 사용 을 참고하세요. 모든 경우에서 마이그레이션 중 데이터 손실을 방지하기 위해, 조직 간 job은 다음 두 가지 조건이 모두 충족될 때만 허용됩니다: job이 반복 실행되는 cron job인 경우. job이 멱등(idempotent)인 경우. 샤딩(Sharding) # Sidekiq API에 대한 모든 호출은 샤딩을 고려해야 합니다. 이를 위해 Sidekiq::Client.via 블록 내에서 Sidekiq API를 활용하여 올바른 Sidekiq.redis 풀이 사용되도록 보장하세요. Gitlab::SidekiqSharding::Router.get_shard_instance 메서드를 호출하여 적절한 Redis 풀을 얻으세요. pool_name, pool = Gitlab::SidekiqSharding::Router.get_shard_instance(worker_class.sidekiq_options['store']) Sidekiq::Client.via(pool) do ... end 라우팅되지 않은 Sidekiq 호출은 모든 API 요청, 서버 측 Sidekiq job, 그리고 테스트에서 유효성 검사기에 의해 감지됩니다. Gitlab::SidekiqSharding::Router 를 사용하여 애플리케이션 로직을 작성하는 것을 권장합니다. 그러나 샤딩은 아직 릴리즈되지 않은 기능이므로, 해당 컴포넌트가 GitLab.com에 영향을 주지 않는다면 아래와 같이 .allow_unrouted_sidekiq_calls 범위 내에서 실행하는 것도 허용됩니다: # Add a comment explaining why it is safe to allow unrouted Sidekiq calls in this case Gitl