Gitaly는 Git 리포지터리에 대한 고수준 원격 프로시저 호출(RPC) 액세스를 제공합니다. GitLab이 Git 데이터를 읽고 쓰는 데 사용됩니다.

Gitaly는 모든 GitLab 설치에 포함되어 있으며 Git 리포지터리 스토리지 및 검색을 조정합니다. Gitaly는 다음과 같이 설정할 수 있습니다:

• 단일 인스턴스 Linux 패키지 설치(한 머신에 모든 GitLab)에서 백그라운드 서비스로 실행.
• 확장 및 가용성 요건에 따라 별도 인스턴스로 분리하여 전체 클러스터 구성으로 구성.

GitLab은 구성된 리포지터리 스토리지를 통해 리포지터리에 액세스합니다. 각 새 리포지터리는 구성된 가중치를 기반으로 리포지터리 스토리지 중 하나에 저장됩니다. 각 리포지터리 스토리지는 다음 중 하나입니다:

• 스토리지 경로를 사용하여 리포지터리에 직접 액세스하는 Gitaly 스토리지로, 각 리포지터리가 단일 Gitaly 노드에 저장됩니다. 모든 요청이 이 노드로 라우팅됩니다.
• Gitaly Cluster(Praefect)에서 제공하는 가상 스토리지로, 각 리포지터리를 내결함성을 위해 여러 Gitaly 노드에 저장할 수 있습니다. Gitaly Cluster(Praefect)에서:
  • 읽기 요청은 여러 Gitaly 노드 간에 분산되어 성능이 향상될 수 있습니다.
  • 쓰기 요청은 리포지터리 복제본에 브로드캐스트됩니다.

다음은 Gitaly에 직접 액세스하도록 설정된 GitLab을 보여줍니다:

이 예시에서:

• 각 리포지터리는 세 개의 Gitaly 스토리지 중 하나인 storage-1, storage-2 또는 storage-3에 저장됩니다.
• 각 스토리지는 Gitaly 노드에서 서비스됩니다.
• 세 개의 Gitaly 노드가 파일 시스템에 데이터를 저장합니다.

디스크 요건#

Gitaly와 Gitaly Cluster(Praefect)는 I/O 집약적인 프로세스이므로 효과적으로 작동하려면 빠른 로컬 스토리지가 필요합니다. 따라서 모든 Gitaly 노드가 솔리드 스테이트 드라이브(SSD)를 사용하도록 강력히 권장합니다. Gitaly는 동시에 많은 작은 파일에서 작동하므로 이러한 SSD는 높은 읽기 및 쓰기 처리량을 가져야 합니다.

참고로 다음 차트는 1분 단위로 GitLab.com의 Gitaly 프로덕션 플릿 전반의 P99 디스크 IOPS를 보여줍니다. 데이터는 월요일 아침에 시작하고 끝나는 7일 대표 기간에서 쿼리되었습니다. 업무 주 동안 트래픽이 더 강해짐에 따라 IOPS의 규칙적인 스파이크를 확인합니다. 원시 데이터는 쓰기가 8000 IOPS로 최고치에 달하는 더 큰 스파이크를 보여줍니다. 사용 가능한 디스크 처리량은 Gitaly 요청에 대한 중단을 피하기 위해 이러한 스파이크를 처리해야 합니다.

• P99 디스크 IOPS(읽기):

  

• P99 디스크 IOPS(쓰기):

  

일반적으로 다음을 볼 수 있습니다:

• 초당 500 - 1000 읽기, 최대 초당 3500 읽기.
• 초당 약 500 쓰기, 최대 초당 3000 이상 쓰기.

작성 시점의 대부분의 Gitaly 플릿은 pd-ssd 디스크가 있는 t2d-standard-32 인스턴스입니다. 광고된 최대 쓰기 및 읽기 IOPS는 60,000입니다.

GitLab.com은 또한 GitLab Self-Managed 인스턴스에서 기본적으로 활성화되지 않은 비용이 많이 드는 Git 작업에 대해 더 엄격한 동시성 제한을 사용합니다. 완화된 동시성 제한, 특히 큰 모노리포에 대한 작업 또는 pack-objects 캐시의 사용도 디스크 활동을 크게 증가시킬 수 있습니다.

실제로 자체 환경에서 Gitaly 인스턴스에서 관찰하는 디스크 활동은 이러한 공개된 결과와 크게 다를 수 있습니다. 클라우드 환경에서 실행 중인 경우 더 큰 인스턴스를 선택하면 일반적으로 사용 가능한 디스크 IOPS가 증가합니다. 처리량을 보장하는 프로비저닝된 IOPS 디스크 유형을 선택할 수도 있습니다. IOPS를 올바르게 구성하는 방법에 대해서는 클라우드 공급자의 문서를 참조하세요.

리포지터리 데이터의 경우 성능 및 일관성 이유로 Gitaly 및 Gitaly Cluster(Praefect)에 대한 로컬 스토리지만 지원됩니다. NFS 또는 클라우드 기반 파일 시스템과 같은 대안은 지원되지 않습니다.

Gitaly 아키텍처#

Gitaly는 클라이언트-서버 아키텍처를 구현합니다:

• Gitaly 서버는 Gitaly 자체를 실행하는 모든 노드입니다.
• Gitaly 클라이언트는 Gitaly 서버에 요청하는 프로세스를 실행하는 모든 노드입니다. Gitaly 클라이언트는 Gitaly 소비자라고도 하며 다음을 포함합니다:
  • GitLab Rails 애플리케이션
  • GitLab Shell
  • GitLab Workhorse
  • GitLab Elasticsearch Indexer
  • GitLab Zoekt Indexer
  • GitLab Kubernetes Agent(KAS)

다음은 Gitaly 클라이언트-서버 아키텍처를 설명합니다:

%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart LR
    accTitle: Gitaly client-server architecture
    accDescr: GitLab clients connect to Gitaly server through gRPC to access local filesystem and object storage.
subgraph Gitaly clients
Rails[GitLab Rails]
Workhorse[GitLab Workhorse]
Shell[GitLab Shell]
Zoekt[Zoekt Indexer]
Elasticsearch[Elasticsearch Indexer]
KAS["GitLab Agent for Kubernetes (KAS)"]
end
subgraph Gitaly
GitalyServer[Gitaly server]
end
FS[Local filesystem]
ObjectStorage[Object storage]
Rails -- gRPC --> Gitaly
Workhorse -- gRPC --> Gitaly
Shell -- gRPC --> Gitaly
Zoekt -- gRPC --> Gitaly
Elasticsearch -- gRPC --> Gitaly
KAS -- gRPC --> Gitaly
GitalyServer --> FS
GitalyServer -- TCP --> Workhorse
GitalyServer -- TCP --> ObjectStorage

Gitaly 구성#

Gitaly는 Linux 패키지 설치와 함께 사전 구성되어 있으며, 이는 최대 20 RPS / 1,000 사용자에 적합한 구성입니다. 다음 경우:

• 최대 40 RPS / 2,000 사용자를 위한 Linux 패키지 설치는 특정 Gitaly 구성 지침을 참조하세요.
• 소스 컴파일 설치 또는 사용자 정의 Gitaly 설치는 Gitaly 구성을 참조하세요.

2,000명 이상의 활성 사용자가 매일 Git 쓰기 작업을 수행하는 GitLab 설치는 Gitaly Cluster(Praefect)를 사용하는 것이 가장 적합할 수 있습니다.

Gitaly CLI#

gitaly 명령은 Gitaly 관리자를 위한 추가 서브커맨드를 제공하는 명령줄 인터페이스입니다. 예를 들어, Gitaly CLI는 다음에 사용됩니다:

• 리포지터리에 대한 사용자 정의 Git 훅 구성.
• Gitaly 구성 파일 유효성 검사.
• 내부 Gitaly API 액세스 가능 여부 확인.
• 디스크의 리포지터리에 대해 Git 명령 실행.

다른 서브커맨드에 대한 자세한 내용은 sudo -u git -- /opt/gitlab/embedded/bin/gitaly --help를 실행합니다.

리포지터리 백업#

GitLab 이외의 도구를 사용하여 리포지터리를 백업하거나 동기화할 때 리포지터리 데이터를 복사하는 동안 쓰기를 방지해야 합니다.

번들 URI#

Gitaly와 함께 Git 번들 URI를 사용할 수 있습니다. 자세한 내용은 번들 URI 문서를 참조하세요.

리포지터리 직접 액세스#

GitLab은 Gitaly가 지속적으로 개선되고 변경되고 있으므로 Git 클라이언트나 다른 도구로 디스크에 저장된 Gitaly 리포지터리에 직접 액세스하는 것을 권장하지 않습니다. 이러한 개선 사항은 가정을 무효화하여 성능 저하, 불안정성, 심지어 데이터 손실을 초래할 수 있습니다. 예:

• Gitaly에는 공식 gRPC 인터페이스를 사용하여 Gitaly가 리포지터리에 대한 액세스를 제어하고 모니터링하는 것에 의존하는 info/refs 광고 캐시와 같은 최적화가 있습니다.
• Gitaly Cluster(Praefect)에는 리포지터리 상태를 결정하기 위해 gRPC 인터페이스와 데이터베이스에 의존하는 내결함성 및 분산 읽기와 같은 최적화가 있습니다.