Workhorse에 의존하는 기능

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

효율적인 이점을 파악하기 위해 2020년 3분기에 대해 GitLab.com에서 확인한 데이터를 참고해 보겠습니다. Rails 어플리케이션 스레드는 평균 200MB의 RSS를 사용하는 반면, Workhorse 고루틴은 약 200KB를 사용하고 있습니다. (자세한 내용)

Workhorse에 의존하는 기능의 예시:

1. git clone 및 git push(HTTP)

Git clone, pull 및 push는 많은 양의 데이터를 전송하고 GitLab 측에서 CPU 집약적이기 때문에 느립니다. Workhorse가 없으면 Git 저장소의 HTTP 액세스가 애플리케이션의 정상적인 웹 액세스와 경쟁하여 더 많은 Rails 애플리케이션 서버를 실행해야 할 것입니다.

2. CI runner 롱 폴링

GitLab CI runner는 GitLab 서버를 주기적으로 폴링하여 새로운 CI 작업을 가져옵니다. Workhorse는 CI runner가 대기하고 새로운 CI 작업을 기다릴 수 있는 “대기실” 역할을 합니다. Go의 효율성 덕분에 적은 비용으로 많은 runner를 대기실에 수용할 수 있습니다. 이러한 대기실 메커니즘이 없으면 많은 Rails 서버 용량을 추가해야 했을 것입니다. 자세한 내용은 롱 폴링 문서를 확인하세요.

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

파일 업로드 및 다운로드가 느릴 수 있습니다. 파일이 크거나 사용자의 연결이 느리기 때문입니다. Workhorse는 Rails의 느린 부분을 처리할 수 있습니다. 이로써 CI artifacts, 패키지 저장소, 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의 장기 WebSocket 연결을 관리할 수 있습니다. 예: 환경의 터미널 웹소켓 처리.
  • Workhorse는 PostgreSQL에 연결하지 않고, Rails 및 (선택적으로) Redis에만 연결합니다.
  • Workhorse는 휴면 중인 클라이언트 연결을 정리하지 않습니다.
  • Workhorse에 도달하는 모든 요청은 먼저 NGINX 또는 Apache와 같은 상위 프록시를 통해 전달된다고 가정합니다.
  • Workhorse는 Rails로 전달되는 모든 요청에 대해 먼저 Rails의 허가를 요청한다고 가정합니다.

더 많은 정보는 ‘GitLab Workhorse의 간략한 역사’를 참고하세요.