InfoGrab DocsInfoGrab Docs

Workhorse를 사용하는 기능

요약

Workhorse 자체는 기능이 아니지만, GitLab에는 Workhorse 없이는 효율적으로 동작하지 않는 여러 기능이 있습니다. 효율성의 이점을 설명하기 위해, 2020Q3 GitLab.com에서 확인한 수치를 살펴보면, Rails 애플리케이션 스레드는 평균 약 200 MB의 RSS를 사용하는 반면, Workhorse 고루틴은 약 200 KB를 사용합니다.

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

효율성의 이점을 설명하기 위해, 2020Q3 GitLab.com에서 확인한 수치를 살펴보면, Rails 애플리케이션 스레드는 평균 약 200 MB의 RSS를 사용하는 반면, Workhorse 고루틴은 약 200 KB를 사용합니다.

Workhorse를 사용하는 기능의 예시:

1. HTTP를 통한 git clone 및 git push#

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

2. CI 러너 롱 폴링#

GitLab CI 러너는 GitLab 서버를 폴링하여 새로운 CI job을 가져옵니다. Workhorse는 CI 러너가 새로운 CI job을 기다리며 대기할 수 있는 일종의 "대기실" 역할을 합니다. Go의 효율성 덕분에 적은 비용으로 대기실에 많은 러너를 수용할 수 있습니다. 이 대기실 메커니즘 없이는 훨씬 더 많은 Rails 서버 용량을 추가해야 합니다. 자세한 내용은 롱 폴링 문서를 참조하세요.

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

파일 업로드 및 다운로드는 파일이 크거나 사용자의 연결 속도가 느리기 때문에 느릴 수 있습니다. Workhorse는 Rails를 대신하여 느린 부분을 처리할 수 있습니다. 이를 통해 CI 아티팩트, 패키지 리포지터리, LFS 객체 등의 기능 효율성이 향상됩니다.

4. 웹소켓 프록시#

웹 터미널과 같은 기능은 사용자의 웹 브라우저와 인터넷에서 직접 접근할 수 없는 GitLab 내부 컨테이너 간의 지속적인 연결을 필요로 합니다. Rails 애플리케이션 스레드를 이러한 연결 프록시에 전용으로 사용하면 Workhorse가 처리하는 것보다 훨씬 더 많은 메모리가 소모됩니다.

5. Web IDE#

보안을 위해 Web IDE의 일부 기능은 별도의 오리진에서 실행되어야 합니다. 이 접근 방식을 지원하기 위해 Web IDE는 Workhorse에 의존하여 Web IDE 에셋으로 들어오고 나가는 특정 요청을 적절히 라우팅하고 데코레이션합니다. Web IDE 에셋은 정적 프론트엔드 에셋이므로, 이 작업을 Rails에 의존하는 것은 불필요한 오버헤드입니다.

6. AI 보조 기능 (GitLab Duo Workflow)#

GitLab Duo Chat 및 GitLab Duo Agent Platform을 포함한 GitLab AI 보조 기능은 Workhorse에 의존하여 GitLab Duo Workflow Service에 대한 요청을 프록시합니다. Workhorse는 GitLab Rails 애플리케이션과 GitLab Duo Workflow Service 사이의 브릿지 역할을 하며, 다음을 지원합니다:

  • 웹소켓 프록시: 실시간 AI 상호작용을 위해 클라이언트와 GitLab Duo Workflow Service 간의 장기 웹소켓 연결을 유지합니다.

  • HTTP 요청 처리: GitLab Duo Workflow Service에서 GitLab API로의 HTTP 요청을 가로채고 처리하여, 모든 요청이 인증되고 Rails 애플리케이션을 통해 적절히 라우팅되도록 합니다.

  • MCP(Model Context Protocol) 툴 실행: MCP 서버와의 통신을 관리하여 AI 에이전트가 사용자 환경에 대한 도구와 정보에 접근할 수 있도록 합니다.

  • GitLab Self-Managed 및 제한된 네트워크 지원: Workhorse를 통해 요청을 프록시함으로써, GitLab Self-Managed 인스턴스 및 네트워크 제한이 있는 인스턴스는 GitLab Duo Workflow Service에서 직접 아웃바운드 연결 없이도 AI 기능을 사용할 수 있습니다.

자세한 아키텍처 정보는 AI 보조 기능 아키텍처를 참조하세요.

빠른 참조 (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의 간략한 역사'를 참조하세요.

Workhorse를 사용하는 기능

GitLab v19.1
원문 보기
요약

Workhorse 자체는 기능이 아니지만, GitLab에는 Workhorse 없이는 효율적으로 동작하지 않는 여러 기능이 있습니다. 효율성의 이점을 설명하기 위해, 2020Q3 GitLab.com에서 확인한 수치를 살펴보면, Rails 애플리케이션 스레드는 평균 약 200 MB의 RSS를 사용하는 반면, Workhorse 고루틴은 약 200 KB를 사용합니다.

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

효율성의 이점을 설명하기 위해, 2020Q3 GitLab.com에서 확인한 수치를 살펴보면, Rails 애플리케이션 스레드는 평균 약 200 MB의 RSS를 사용하는 반면, Workhorse 고루틴은 약 200 KB를 사용합니다.

Workhorse를 사용하는 기능의 예시:

1. HTTP를 통한 git clone 및 git push#

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

2. CI 러너 롱 폴링#

GitLab CI 러너는 GitLab 서버를 폴링하여 새로운 CI job을 가져옵니다. Workhorse는 CI 러너가 새로운 CI job을 기다리며 대기할 수 있는 일종의 "대기실" 역할을 합니다. Go의 효율성 덕분에 적은 비용으로 대기실에 많은 러너를 수용할 수 있습니다. 이 대기실 메커니즘 없이는 훨씬 더 많은 Rails 서버 용량을 추가해야 합니다. 자세한 내용은 롱 폴링 문서를 참조하세요.

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

파일 업로드 및 다운로드는 파일이 크거나 사용자의 연결 속도가 느리기 때문에 느릴 수 있습니다. Workhorse는 Rails를 대신하여 느린 부분을 처리할 수 있습니다. 이를 통해 CI 아티팩트, 패키지 리포지터리, LFS 객체 등의 기능 효율성이 향상됩니다.

4. 웹소켓 프록시#

웹 터미널과 같은 기능은 사용자의 웹 브라우저와 인터넷에서 직접 접근할 수 없는 GitLab 내부 컨테이너 간의 지속적인 연결을 필요로 합니다. Rails 애플리케이션 스레드를 이러한 연결 프록시에 전용으로 사용하면 Workhorse가 처리하는 것보다 훨씬 더 많은 메모리가 소모됩니다.

5. Web IDE#

보안을 위해 Web IDE의 일부 기능은 별도의 오리진에서 실행되어야 합니다. 이 접근 방식을 지원하기 위해 Web IDE는 Workhorse에 의존하여 Web IDE 에셋으로 들어오고 나가는 특정 요청을 적절히 라우팅하고 데코레이션합니다. Web IDE 에셋은 정적 프론트엔드 에셋이므로, 이 작업을 Rails에 의존하는 것은 불필요한 오버헤드입니다.

6. AI 보조 기능 (GitLab Duo Workflow)#

GitLab Duo Chat 및 GitLab Duo Agent Platform을 포함한 GitLab AI 보조 기능은 Workhorse에 의존하여 GitLab Duo Workflow Service에 대한 요청을 프록시합니다. Workhorse는 GitLab Rails 애플리케이션과 GitLab Duo Workflow Service 사이의 브릿지 역할을 하며, 다음을 지원합니다:

  • 웹소켓 프록시: 실시간 AI 상호작용을 위해 클라이언트와 GitLab Duo Workflow Service 간의 장기 웹소켓 연결을 유지합니다.

  • HTTP 요청 처리: GitLab Duo Workflow Service에서 GitLab API로의 HTTP 요청을 가로채고 처리하여, 모든 요청이 인증되고 Rails 애플리케이션을 통해 적절히 라우팅되도록 합니다.

  • MCP(Model Context Protocol) 툴 실행: MCP 서버와의 통신을 관리하여 AI 에이전트가 사용자 환경에 대한 도구와 정보에 접근할 수 있도록 합니다.

  • GitLab Self-Managed 및 제한된 네트워크 지원: Workhorse를 통해 요청을 프록시함으로써, GitLab Self-Managed 인스턴스 및 네트워크 제한이 있는 인스턴스는 GitLab Duo Workflow Service에서 직접 아웃바운드 연결 없이도 AI 기능을 사용할 수 있습니다.

자세한 아키텍처 정보는 AI 보조 기능 아키텍처를 참조하세요.

빠른 참조 (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의 간략한 역사'를 참조하세요.