Workhorse에 새 기능 추가하기

GitLab Workhorse는 GitLab을 위한 스마트한 리버스 프록시입니다. 이는 긴 HTTP 요청을 처리합니다. 다음과 같은 요청을 처리합니다:

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

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

첫눈에 보기에 Workhorse는 Ruby on Rails 컨트롤러의 로직을 줄이기 위한 HTTP 스트림 처리용 파이프라인으로 보입니다. 그러나 단순히 그렇게만 생각하지 마십시오. Workhorse로 기능을 오프로드하려는 엔지니어들은 종종 원래 예상보다 더 많은 작업이 필요하다는 것을 발견합니다:

  • 이는 새로운 프로그래밍 언어이며, GitLab에서 Go 개발자는 소수에 불과합니다.
  • Workhorse에는 엄격한 요구 사항이 있습니다:
    • 무상태여야 합니다.
    • 메모리 및 디스크 사용량을 엄격하게 제어해야 합니다.
    • 요청이 처리되는 동안 느려지지 않아야 합니다.

새 기능 추가 피하기

절대적으로 필요하고 다른 옵션이 없는 경우에만 새 기능을 추가하는 것을 권장합니다. 기능을 Rails 코드베이스와 Workhorse 사이에 나누는 것은 기술적 부채를 도입하는 의도적인 선택입니다. 시스템에 복잡성을 추가하고 두 구성 요소 간의 결합을 추가합니다:

  • Workhorse를 사용하여 기능을 구축하는 것은 상당한 복잡성 비용이 발생하므로 Rails 요청 및 Sidekiq 작업을 기반으로 하는 설계를 선호해야 합니다.
  • 레일즈 및 Sidekiq을 사용하는 것이 레일즈 및 Workhorse를 사용하는 것보다 더 많은 작업이 필요하더라도 장기적으로 유지 관리하기 쉽습니다. Workhorse는 GitLab에만 있는 것이고, 레일즈 및 Sidekiq은 산업 표준입니다.
  • 웹 요청에 대한 전역 동작인 경우, Workhorse 대신 Rack 미들웨어를 사용하는 것을 고려하세요.
  • 일반적으로, HTTP 클라이언트가 레일즈에서 합리적으로 구현 가능한 동작을 기대할 때에만 레일즈 및 Workhorse를 사용하세요.

긴 요청이란 무엇인가요?

Workhorse와 Puma RAM 사용량 사이에 큰 차이가 있습니다. 몇 밀리초 이상 연결을 유지하는 것은 문제가 있습니다. 왜냐하면 Ruby on Rails 컨트롤러에서 RAM이 많이 사용되기 때문입니다. 우리는 두 가지 종류의 긴 요청을 확인했습니다: 데이터 전송과 HTTP 롱 폴링. 몇 가지 예시는 다음과 같습니다:

  • git push.
  • git pull.
  • 아티팩트 업로드 또는 다운로드
  • CI 러너가 새 작업을 기다리는 경우

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

여전히 Workhorse에 새 기능을 추가해야 한다고 생각한다면, Workhorse 유지 보수자를 위한 이슈를 오픈하고 다음을 설명하세요:

  1. 구현하려는 것
  2. 왜 우리의 루비 코드베이스에 구현할 수 없는지

Workhorse 유지 보수자들은 상황을 평가하는 데 도움을 줄 수 있습니다.

관련 주제