Workhorse에 의존하는 기능

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

효율적인 이점을 이해하기 위해 2020년 Q3에 GitLab.com에서 확인한 내용을 고려해보세요. 여기에서, 웹 애플리케이션 스레드는 평균 200MB의 RSS를 사용하는 반면, Workhorse 고루틴은 약 200KB를 사용합니다.

Workhorse에 의존하는 예시 기능:

1. git clone 및 git push HTTP로

Git clone, pull 및 push는 많은 양의 데이터를 전송하고 GitLab 측에서 CPU 집중적이기 때문에 느립니다. Workhorse 없이는 Git 리포지터리에 대한 HTTP 액세스가 앱의 정규 웹 액세스와 경쟁하여 더 많은 Rails 애플리케이션 서버를 실행해야 합니다.

2. CI 러너의 롱 폴링

GitLab CI 러너는 GitLab 서버를 폴링하여 새 CI 작업을 가져옵니다. Workhorse는 CI 러너가 새 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의 장기적인 WebSocket 연결을 관리할 수 있습니다. 예시: 환경의 터미널 웹 소켓을 처리하는 경우.
  • Workhorse는 PostgreSQL에 연결하지 않고, Rails 및 (옵션으로) Redis에만 연결합니다.
  • Workhorse는 유휴 클라이언트 연결을 정리하지 않습니다.
  • 모든 Workhorse에 도달하는 요청은 먼저 NGINX 또는 Apache와 같은 상위 프록시를 통해 전달된다고 가정합니다.
  • Workhorse는 Rails로의 모든 요청이 먼저 지난다고 가정합니다.

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