Workhorse에 새 기능 추가하기

GitLab Workhorse의 역할과 새 기능 추가 시 고려해야 할 사항, 장기 요청의 정의 및 관련 리소스를 설명합니다.

GitLab Workhorse는 GitLab을 위한 스마트 리버스 프록시입니다. 다음과 같은 장기 HTTP 요청 을 처리합니다: 파일 다운로드 파일 업로드 Git 푸시 및 풀 Git 아카이브 다운로드 Workhorse 자체는 기능이 아니지만, GitLab의 여러 기능 은 Workhorse 없이는 효율적으로 작동하지 않습니다. 언뜻 보면 Workhorse는 Ruby on Rails 컨트롤러의 로직 양을 줄이기 위해 HTTP 스트림을 처리하는 파이프라인에 불과한 것처럼 보입니다. 하지만 그렇게 취급하지 마세요. 기능을 Workhorse로 오프로드하려는 엔지니어는 처음 예상보다 더 많은 작업이 필요하다는 것을 자주 발견합니다: 새로운 프로그래밍 언어이며, GitLab에서 Go 개발자는 소수에 불과합니다. Workhorse에는 까다로운 요구 사항이 있습니다: 상태가 없어야(stateless) 합니다. 메모리 및 디스크 사용량을 엄격하게 제어해야 합니다. 처리 과정에서 요청이 느려지지 않아야 합니다. 새 기능 추가 지양 # 절대적으로 필요하고 다른 옵션이 없는 경우에만 새 기능을 추가하는 것을 권장합니다. Rails 코드베이스와 Workhorse 간에 기능을 분리하는 것은 기술 부채를 의도적으로 도입하는 선택입니다. 이는 시스템에 복잡성을 추가하고 두 컴포넌트 간의 결합을 야기합니다: Workhorse를 사용하여 기능을 구축하는 것은 상당한 복잡성 비용이 발생하므로, Rails 요청 및 Sidekiq job 기반의 설계를 선호해야 합니다. Rails-and-Sidekiq을 사용하는 것이 Rails-and-Workhorse보다 더 많은 작업이 필요하더라도, Rails-and-Sidekiq이 장기적으로 유지 관리하기 더 쉽습니다. Workhorse는 GitLab에 고유한 것인 반면, Rails-and-Sidekiq은 업계 표준입니다. 웹 요청에 대한 전역 동작을 위해서는 Workhorse 대신 Rack 미들웨어 사용을 고려하세요. 일반적으로 HTTP 클라이언트가 Rails에서 구현하기 적합한 동작(예: 장기 요청)을 기대하는 경우에만 Rails-and-Workhorse를 사용하세요. 장기 요청이란? # Workhorse와 Puma의 RAM 사용량 사이에는 한 자릿수 차이가 있습니다. 연결이 밀리초 이상 열려 있으면 Ruby on Rails 컨트롤러에 도달한 후 독점하는 RAM 양으로 인해 문제가 발생합니다. 두 가지 유형의 장기 요청을 식별했습니다: 데이터 전송과 HTTP 롱 폴링. 몇 가지 예시: git push git pull 아티팩트 업로드 또는 다운로드 새 job을 기다리는 CI 러너 클라우드 네이티브 설치의 부상으로 Workhorse의 기능 세트는 오브젝트 스토리지 직접 업로드를 추가하도록 확장되었습니다. 이 변경으로 공유 네트워크 파일 시스템(NFS) 드라이브의 필요성이 제거되었습니다. 여전히 Workhorse에 새 기능을 추가해야 한다고 생각한다면, Workhorse 메인테이너를 위한 이슈를 열고 다음 사항을 설명하세요: 구현하고자 하는