Workhorse에 새로운 기능 추가하기

GitLab Workhorse는 GitLab을 위한 스마트 리버스 프록시입니다. 이는
긴 HTTP 요청을 처리합니다, 예를 들면:

  • 파일 다운로드.
  • 파일 업로드.
  • Git 푸시 및 풀.
  • Git 아카이브 다운로드.

Workhorse 자체는 기능이 아니지만, GitLab의 여러 기능은
Workhorse 없이는 효율적으로 작동하지 않습니다.

첫눈에 Workhorse는 HTTP 스트림을 처리하여 Ruby on Rails 컨트롤러의 논리를 줄이는
파이프라인처럼 보입니다. 그러나 그렇게 취급하지 마세요. Workhorse에 기능을 이전하려는
엔지니어들은 종종 처음 예상했던 것보다 더 많은 작업이 필요하다는 것을 발견합니다:

  • 새로운 프로그래밍 언어이며, GitLab의 엔지니어 중 일부만 Go 개발자입니다.
  • Workhorse는 까다로운 요구 사항을 가지고 있습니다:
    • 상태 비저장입니다.
    • 메모리 및 디스크 사용량을 엄격하게 통제해야 합니다.
    • 요청이 처리되는 동안 지연되어서는 안 됩니다.

새로운 기능 추가를 피하세요

저희는 절대적으로 필요하고 다른 옵션이 없을 경우에만 새로운 기능을 추가할
것을 권장합니다. Rails 코드베이스와 Workhorse 사이에 기능을 분리하는 것은
기술적 부채를 도입하기 위한 신중한 선택입니다. 이는 시스템에 복잡성을 추가하며,
두 컴포넌트 간의 결합도를 증가시킵니다:

  • Workhorse를 사용하여 기능을 구축하는 데는 상당한 복잡성 비용이 따르므로,
    Rails 요청 및 Sidekiq 작업을 기반으로 한 디자인을 선호해야 합니다.
  • 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.
  • 아티팩트 업로드 또는 다운로드.
  • 새로운 작업을 기다리는 CI 러너.

클라우드 네이티브 설치의 증가와 함께, Workhorse의 기능 세트는
객체 저장소 직접 업로드를 추가하도록 확장되었습니다. 이 변경으로
공유 네트워크 파일 시스템(NFS) 드라이브가 필요 없어졌습니다.

여전히 Workhorse에 새로운 기능을 추가해야 한다고 생각하면,
Workhorse 유지 관리자를 위한 이슈를 열고 설명하세요:

  1. 구현하고자 하는 내용.
  2. 왜 우리 Ruby 코드베이스에서 구현할 수 없는지.

Workhorse 유지 관리자가 상황을 평가하는 데 도움을 드릴 수 있습니다.

관련 주제