Workhorse에 의존하는 기능

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

효율성 이점을 맥락적으로 이해하기 위해, 2020년 3분기 GitLab.com에서 우리가 확인한 바에 따르면 Rails 애플리케이션 스레드는 평균적으로 약 200 MB의 RSS를 사용하고 Workhorse 고루틴은 약 200 KB를 사용합니다.

Workhorse에 의존하는 기능의 예:

1. git clone 및 git push over HTTP

Git clone, pull 및 push는 대량의 데이터를 전송하고 각 작업이 GitLab 측에서 CPU 집약적이기 때문에 느립니다. Workhorse가 없으면 HTTP를 통해 Git 리포지토리에 접근하는 것은 애플리케이션의 일반 웹 접근과 경쟁하게 되어 훨씬 더 많은 Rails 애플리케이션 서버를 실행해야 했습니다.

2. CI 러너 긴 폴링

GitLab CI 러너는 GitLab 서버를 폴링하여 새로운 CI 작업을 가져옵니다. Workhorse는 CI 러너가 앉아 기다릴 수 있는 일종의 “대기실” 역할을 합니다. Go의 효율성 덕분에 우리는 많은 러너를 대기실에 저렴한 비용으로 배치할 수 있습니다. 이 대기실 механизмы 없이는 많은 Rails 서버 용량을 추가해야 했습니다.

자세한 내용은 긴 폴링 문서를 참조하세요.

3. 파일 업로드 및 다운로드

파일 업로드 및 다운로드는 파일이 크거나 사용자의 연결이 느린 경우 느릴 수 있습니다. Workhorse는 Rails에 대한 느린 부분을 처리할 수 있습니다. 이는 CI 아티팩트, 패키지 리포지토리, LFS 객체 등의 기능 효율성을 향상시킵니다.

4. 웹소켓 프록시

웹 터미널과 같은 기능은 사용자의 웹 브라우저와 GitLab 내부의 컨테이너 간에 장기 연결을 요구하며, 이 컨테이너는 인터넷에서 직접 접근할 수 없습니다. 그러한 연결을 프록시하기 위해 Rails 애플리케이션 스레드를 전담하는 것은 Workhorse가 이를 관리하는 것보다 훨씬 더 많은 메모리를 소모합니다.

빠른 사실 (Workhorse는 어떻게 작동하나요)

  • Workhorse는 Rails를 전혀 수반하지 않고도 일부 요청을 처리할 수 있습니다: 예를 들어, JavaScript 파일 및 CSS 파일은 디스크에서 직접 제공됩니다.

  • Workhorse는 Rails에서 전송되는 응답을 수정할 수 있습니다: 예를 들어, Rails에서 send_file을 사용하면 GitLab Workhorse가 디스크에서 파일을 열고 그 내용이 클라이언트에 대한 응답 본문으로 전송됩니다.

  • Workhorse는 Rails에 허가를 요청한 후 요청을 인수할 수 있습니다. 예: git clone 처리.

  • Workhorse는 Rails에 전달하기 전에 요청을 수정할 수 있습니다. 예: Git LFS 업로드를 처리할 때 Workhorse는 먼저 Rails의 허가를 요청한 다음, 요청 본문을 임시 파일에 저장하고 파일 경로를 포함한 수정된 요청을 Rails에 보냅니다.

  • Workhorse는 Rails용으로 장기 라이브 웹소켓 연결을 관리할 수 있습니다. 예: 환경에 대한 터미널 웹소켓 처리.

  • Workhorse는 PostgreSQL에 연결하지 않고, Rails와 (선택적으로) Redis에만 연결합니다.

  • 모든 Workhorse에 도달하는 요청은 먼저 NGINX 또는 Apache와 같은 업스트림 프록시를 통과한다고 가정합니다.

  • Workhorse는 유휴 클라이언트 연결을 정리하지 않습니다.

  • 모든 Rails에 대한 요청은 Workhorse를 통과한다고 가정합니다.

자세한 내용은 ‘GitLab Workhorse의 간략한 역사’를 참조하세요.