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