Workhorse에 새로운 기능 추가하기

GitLab Workhorse는 GitLab을 위한 스마트한 리버스 프록시입니다. 이는 long HTTP requests를 다룹니다. 이러한 요청에는 다음이 포함됩니다:

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

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

첫눈에 보면, Workhorse는 루비 온 레일즈 컨트롤러 내의 로직 양을 줄이기 위한 HTTP 스트림 처리를 위한 파이프라인으로 보입니다. 그러나 그렇게 다루어서는 안 됩니다. Workhorse에 기능을 할당하려는 엔지니어들은 종종 처음 예상보다 더 많은 작업이 필요하다는 것을 발견합니다.

  • 새로운 프로그래밍 언어이며, GitLab의 엔지니어 중 소수만이 Go 개발자입니다.
  • Workhorse에는 엄격한 요구 사항이 있습니다:
    • 상태가 없어야 합니다.
    • 메모리 사용과 디스크 사용을 엄격히 제어해야 합니다.
    • 요청이 과도하게 느려지지 않아야 합니다.

새로운 기능 추가 피하기

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

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

long requests란?

Workhorse와 Puma RAM 사용량 사이에는 큰 차이가 있습니다. 밀리초보다 더 오래 연결을 유지하는 것은 루비 온 레일즈 컨트롤러가 도달한 후 RAM을 독점하는 양으로 인해 문제가 됩니다. 우리는 두 가지 종류의 long requests를 식별했습니다: 데이터 전송과 HTTP 롱 폴링. 몇 가지 예시:

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

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

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

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

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

관련 주제