워크호스에 의존하는 기능

워크호스 자체는 기능이 아니지만, 워크호스 없이는 GitLab의 몇 가지 기능이 효율적으로 작동되지 않습니다.

이러한 효율성 이점을 이해하기 위해 2020년 3분기에 GitLab.com에서 확인한 바에 따르면 레일즈 애플리케이션 스레드는 평균 약 200 MB의 RSS를 사용하지만, 워크호스 고루틴은 약 200 KB를 사용합니다.

워크호스에 의존하는 기능의 예시:

1. git clone 및 git push HTTP로

Git clone, pull 및 push는 큰 양의 데이터를 전송하고 각각 GitLab 측에서 CPU 집약적이기 때문에 느립니다. 워크호스가 없으면 Git 리포지토리의 HTTP 액세스가 일반 웹 액세스와 경쟁하여 더 많은 레일즈 애플리케이션 서버를 실행해야 할 수 있습니다.

2. CI 러너의 롱 폴링

GitLab CI 러너는 GitLab 서버를 폴링하여 새 CI 작업을 가져옵니다. 워크호스는 CI 러너가 새 CI 작업을 기다릴 수 있는 “대기실” 역할을 합니다. Go의 효율성으로 인해 비용 부담을 덜고 많은 러너를 대기실에 수용할 수 있습니다. 이 대기실 메커니즘이 없으면 훨씬 더 많은 레일즈 서버 용량을 추가해야 합니다. 자세한 내용은 롱 폴링 문서를 참조하세요.

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

파일 업로드 및 다운로드는 파일이 크거나 사용자의 연결이 느려서 느릴 수 있습니다. 워크호스는 레일즈를 위해 느린 부분을 처리할 수 있습니다. 이로써 CI 아티팩트, 패키지 리포지토리, LFS 객체 등의 효율성이 향상됩니다.

4. 웹소켓 프록시

웹 터미널과 같은 기능은 사용자의 웹 브라우저와 인터넷에서 직접 액세스할 수 없는 GitLab 내부의 컨테이너 간의 장기간 연결이 필요합니다. 레일즈 애플리케이션 스레드를 이 연결을 프록시하는 데 사용한다면, 워크호스가 관리하는 것보다 훨씬 더 많은 메모리 비용이 들 것입니다.

빠른 사실 (워크호스의 작동 방식)

  • 워크호스는 일부 요청을 레일즈에 연관시키지 않고 처리할 수 있습니다: 예를 들면 JavaScript 파일과 CSS 파일은 디스크에서 직접 제공됩니다.
  • 워크호스는 레일즈에서 보낸 응답을 수정할 수 있습니다: 예를 들면 레일즈에서 send_file을 사용하면 GitLab 워크호스가 디스크에서 파일을 열고 그 내용을 클라이언트에게 응답 본문으로 보냅니다.
  • 워크호스는 레일즈의 허가를 받은 후 요청을 인수할 수 있습니다. 예: git clone 처리.
  • 워크호스는 레일즈로 전달하기 전에 요청을 수정할 수 있습니다. 예: Git LFS 업로드 처리 시, 워크호스는 먼저 레일즈의 허가를 받고, 그런 다음 요청 본문을 임시 파일에 저장하고, 파일 경로를 포함한 수정된 요청을 레일즈에 전송합니다.
  • 워크호스는 레일즈를 위해 오래된 WebSocket 연결을 관리할 수 있습니다. 예: 환경을 위한 터미널 웹소켓 처리.
  • 워크호스는 PostgreSQL에 연결하지 않고, 레일즈와 (선택적으로) Redis에만 연결합니다.
  • 워크호스는 모든 요청이 NGINX 또는 Apache와 같은 상위 프록시를 통해 전달된다고 가정합니다.
  • 워크호스는 유휴 상태의 클라이언트 연결을 정리하지 않습니다.
  • 워크호스는 모든 레일즈로의 요청이 워크호스를 통과한다고 가정합니다.

자세한 정보는 ‘GitLab 워크호스 간략 역사’를 참조하세요.