업데이트 간 Sidekiq 호환성

GitLab 업데이트 중 Sidekiq job 인수 변경, 워커 클래스 추가/제거/이름 변경 시 하위 호환성을 유지하는 방법을 설명합니다.

Sidekiq job의 인수는 실행이 예약된 동안 큐에 저장됩니다. 온라인 업데이트 중에는 다음과 같은 여러 상황이 발생할 수 있습니다: 애플리케이션의 이전 버전이 job을 게시하고, 업그레이드된 Sidekiq 노드가 이를 실행합니다. job이 업그레이드 전에 큐에 추가되었지만, 업그레이드 후에 실행됩니다. job이 최신 버전의 애플리케이션을 실행하는 노드에 의해 큐에 추가되었지만, 이전 버전의 애플리케이션을 실행하는 노드에서 실행됩니다. 새로운 워커 추가 # GitLab.com에서는 현재 카나리 Stage에 Sidekiq 배포가 없습니다 . 이는 HTTP 엔드포인트에서 예약할 수 있는 새로운 워커가 카나리에서 예약될 수 있지만, 전체 프로덕션 배포가 완료될 때까지 Sidekiq에서 실행되지 않을 수 있음을 의미합니다. 이는 job 예약보다 몇 시간 늦을 수 있습니다. 일부 워커의 경우 이것이 문제가 되지 않지만, 특히 지연 민감 job 의 경우에는 사용자 경험이 저하될 수 있습니다. 이것은 새로운 워커 클래스가 처음 도입될 때만 적용됩니다. 일반적인 개발 프로세스로 기능 플래그 사용 을 권장하므로, 새로운 Sidekiq 워커 예약을 포함한 전체 변경 사항을 기능 플래그로 제어하는 것이 좋습니다. 워커의 인수 변경 # job은 연속된 버전의 애플리케이션 간에 하위 호환성과 상위 호환성을 모두 갖춰야 합니다. 인수를 추가하거나 제거하면 문제가 발생할 수 있습니다. 모든 배포 중에는 일부 애플리케이션 노드는 업데이트되었지만 그렇지 않은 노드도 있는 기간이 있습니다. 업데이트된 노드가 새 인수로 job을 큐에 추가하지만, 이전 Sidekiq 노드가 이를 처리하면 인수 불일치로 인해 job이 실패합니다. GitLab.com의 경우, 동일한 마일스톤에 여러 번의 배포가 있을 경우 이런 상황이 발생할 수 있습니다. 대부분의 Self-managed 배포는 각 릴리즈마다 단일 배포 사이클에서 모든 노드를 순차적으로 업데이트하므로, 여러 릴리즈에 걸쳐 변경 사항을 분산시켜야 합니다. 인수 폐기 및 제거 # perform_async 및 perform 메서드에서 인수를 제거하기 전에 , 먼저 폐기 처리하세요. 다음 예제는 perform_async 메서드에서 arg2 를 폐기 처리한 후 제거하는 방법을 보여줍니다: 기본값(보통 nil )을 제공하고, 주석을 사용하여 다음 마이너 릴리즈에서 인수를 폐기 처리한다고 표시합니다. (릴리즈 M) class ExampleWorker # Keep arg2 parameter for backwards compatibility. def perform(object_id, arg1, arg2 = nil) # ... end end 한 마이너 릴리즈 후, perform_async 에서 인수 사용을 중단합니다. (릴리즈 M+1) ExampleWorker.perform_async(object_id, arg1) 다음 메이저 릴리즈에서, 워커 클래스에서 값을 제거합니다. (다음 메이저 릴리즈) class ExampleWorker def p