• GitLab 스택에서의 역할
• 기능 및 운영
  • 요청 처리
  • 특수 작업 처리
  • Rails API와의 통합
• 아키텍처적 고려사항
  • 기능 확장
  • 데이터 관리 및 운영 무결성
• 학습 리소스
• 워크호스 설치
  • 실행 시간 종속성
• 코드 테스트

GitLab 워크호스

GitLab 워크호스는 리소스 집약적이고 오랜 시간이 걸리는 요청을 처리하기 위해 고안된 GitLab의 스마트한 리버스 프록시입니다. 이는 Puma 앞에 위치하고 있으며 GitLab Rails에서 발신 및 목적지인 모든 HTTP 요청을 가로챕니다. Rails는 요청을 워크호스로 위임하며, 워크호스는 파일 다운로드 및 업로드, HTTP 푸시/풀을 통한 git, HTTP 아카이브 다운로드와 같은 리소스 집약적인 HTTP 요청에 대한 책임을 집니다. 이로써 리소스 활용을 최적화하고 요청 처리 효율을 향상시킵니다.

GitLab 스택에서의 역할

워크호스 앞에 다른 리버스 프록시 서버가 있을 수 있지만, 지원되는 것은 NGINX뿐입니다. 소스에서 GitLab을 설치할 때는 Apache와 같은 다른 리버스 프록시를 사용하는 것도 가능하지만(지원되는 것은 아님), NGINX 앞에는 gitlab.com과 같은 많은 GitLab 인스턴스에서 CloudFlare와 같은 CDN이 위치합니다.

모든 Rails 컨트롤러 및 HTTP 요청을 처리하고 HTTP 응답을 반환하는 기타 코드는 GitLab 워크호스를 통해 프록시됩니다. 워크호스는 대부분의 리버스 프록시와는 다르게 매우 밀접하게 GitLab Rails에 결합되어 있으며, 대부분의 리버스 프록시가 매우 일반적인 것과는 달리 특이한 요청에 대한 작업을 효율적으로 완료하기 위해 GitLab Rails에서 필요로 하는 HTTP 헤더에 대한 수정을 수행합니다.

기능 및 운영

요청 처리

• 워크호스는 주로 들어오는 요청의 통과 역할을 하여 그것들을 처리하기 위해 Rails로 전달합니다. 본질적으로 대부분의 요청에는 최소한의 개입을 수행하여 요청 처리 파이프라인을 간소화합니다.
• 특정 유형의 요청에 대해서는 특히 리소스 집약적이거나 특수한 처리가 필요한 경우(예: 대용량 파일 업로드), 워크호스는 더 적극적인 역할을 수행합니다. Rails로부터 지시를 받은 후 워크호스는 Gitaly와 직접 상호 작용하거나 파일 업로드 처리를 Rails로부터 분산시킵니다.

특수 작업 처리

• 워크호스는 Rails의 응답에 따라 특정 요청을 가로채고 미리 정의된 작업을 실행할 수 있습니다. 이는 Gitaly와 상호 작용하거나 대용량 데이터 덩어리를 관리하고 필요에 따라 요청 처리 논리를 변경하는 것을 포함합니다.
• 주목할 만한 기능은 파일 업로드를 효율적으로 관리할 수 있는 능력입니다. 워크호스는 파일 업로드 프로세스를 가로채서 Rails에 의해 지시된 필요한 작업(예: 파일을 임시로 저장하거나 객체 저장소에 업로드)을 수행하며, 프로세스가 완료되면 Rails를 업데이트합니다.

Rails API와의 통합

워크호스는 특히 컨테이너 레지스트리 서비스와 상호 작용을 필요로 하는 컨텍스트에서 Rails API의 프록시 역할을 수행합니다. 이러한 구성은 워크호스가 리버스 프록시로 작용하여 Rails에 직접적인 부하를 최소화함으로써 고부하 서비스를 처리할 수 있는 능력을 보여주며, 이는 Rails에 직접적인 부하를 최소화함으로써 고부하 서비스를 처리할 수 있는 능력을 보여줍니다.

아키텍처적 고려사항

기능 확장

• 간단함 유지: Workhorse의 기능을 확장하여 특정 서비스(예: 컨테이너 레지스트리)를 직접 처리하는 경우에도 간단함과 효율성을 유지하는 것이 중요합니다. Workhorse는 복잡한 제어 로직을 포괄해서는 안 되며, 대신 Rails에서 지시된대로 작업을 수행하는 데 중점을 두어야 합니다.
• 서비스 구현 및 데이터 이관: Workhorse에 새로운 기능을 구현하기 위해서는 데이터 이관 전략과 서비스 연속성에 대한 신중한 고려가 필요합니다.

데이터 관리 및 운영 무결성

• Workhorse의 아키텍처는 가비지 수집 및 데이터 이관을 포함한 효율적인 데이터 관리 전략을 용이하게 합니다. Workhorse의 역할은 복잡한 데이터 조작이나 제어 로직을 직접적으로 관여하지 않으면서 고성능 작업을 지원하는 것으로, 이는 Rails의 영향권에 있는 것으로 유지됩니다.
• 백그라운드 처리나 오랜 시간이 걸리는 작업이 필요한 운영에 대해서는 별도의 서비스나 Sidekiq 작업 대기열을 사용하는 것이 제안되며, Workhorse와 Rails가 작업 실행 및 데이터 무결성을 관리하기 위해 협력합니다.

워크호스는 Rails 모노레포의 하위 폴더에 포함되어 있으며, 경로는 아래와 같습니다. gitlab-org/gitlab/workhorse.

학습 리소스

• 워크호스 문서 (이 페이지)
• 비디오: GitLab 워크호스 심층 탐구: 의존성 프록시
• 워크호스를 사용한 의존성 프록시 작동 방식
• 의존성 프록시를 위한 워크호스 개요
• 워크호스 아키텍처 논의

워크호스 설치

GitLab 워크호스를 설치하려면 Go 1.18 이상과 GNU Make가 필요합니다.

/usr/local/bin에 설치하려면 make install을 실행하세요.

make install

/foo/bin에 설치하려면 PREFIX 변수를 설정하세요.

make install PREFIX=/foo

FreeBSD와 같은 일부 운영 체제에서는 make 대신에 gmake을 사용해야 할 수 있습니다.

참고: 일부 기능은 빌드 태그에 따라 다릅니다. 활성화하려면 워크호스 구성을 확인하세요.

실행 시간 종속성

Workhorse는 업로드된 이미지에서 민감한 정보를 포함할 수 있는 EXIF 데이터를 제거하기 위해 ExifTool를 사용합니다. 만약 GitLab을 설치했다면:

• Linux 패키지를 사용하면 모든 준비가 끝났습니다. 만약 CentOS Minimal을 사용하고 있다면 perl 패키지를 설치해야 할 수 있습니다: yum install perl.

• 소스로부터 설치했다면, exiftool이 설치되어 있는지 확인하세요:

  # Debian/Ubuntu
  sudo apt-get install libimage-exiftool-perl
  
  # RHEL/CentOS
  sudo yum install perl-Image-ExifTool
  

코드 테스트

다음과 같이 테스트를 실행하세요:

make clean test

GitLab Workhorse의 각 기능은 해당 기능이 올바른 요청에서 ‘작동’하고 다른 요청에 영향을 주지 않는지 확인하는 통합 테스트가 있어야 합니다. 특정 동작에 대한 패키지 수준의 테스트를 갖는 것도 좋지만, 개발 중에는 고수준의 통합 테스트가 우선입니다.

기능이 통합 테스트로만 커버된 경우에도 괜찮습니다.