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는 읽기와 쓰기 처리량이 높아야 합니다.

참고로 다음 차트는 GitLab.com의 Gitaly 프로덕션 플릿 전반의 P99 디스크 IOPS를 1분 단위로 보여줍니다. 데이터는 월요일 아침에 시작해 월요일 아침에 끝나는 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 operation에 적용합니다. 동시성 제한을 완화하거나, 특히 큰 모노리포에 대해 operation을 수행하거나, pack-objects 캐시를 사용하는 경우에도 디스크 활동이 크게 늘어날 수 있습니다.

실제 환경에서 Gitaly 인스턴스에 관측되는 디스크 활동은 여기 공개된 결과와 크게 다를 수 있습니다. 클라우드 환경에서 실행 중이라면 대개 더 큰 인스턴스를 선택할수록 사용 가능한 디스크 IOPS가 늘어납니다. 처리량이 보장되는 프로비저닝 IOPS 디스크 유형을 선택할 수도 있습니다. IOPS를 올바르게 구성하는 방법은 사용 중인 클라우드 공급자의 문서를 참고합니다.

리포지터리 데이터의 경우 성능과 일관성을 위해 Gitaly와 Gitaly Cluster(Praefect)는 로컬 스토리지만 지원합니다. NFS나 클라우드 기반 파일 시스템 같은 대안은 지원하지 않습니다.

각 Gitaly 노드는 자체 전용 스토리지 디스크를 사용해야 합니다. IOPS 요건은 각 노드에 독립적으로 적용됩니다. 여러 Gitaly 노드가 디스크 하나를 공유하면 해당 디스크의 I/O 부하가 배가되어 심각한 성능 병목이 발생할 수 있습니다.

Gitaly 아키텍처#

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

• Gitaly 서버는 Gitaly 자체를 실행하는 노드입니다.
• Gitaly 클라이언트는 Gitaly 서버에 요청을 보내는 프로세스를 실행하는 노드입니다. Gitaly 클라이언트는 Gitaly 소비자라고도 하며 다음을 포함합니다.
  • GitLab Rails 애플리케이션
  • GitLab Shell
  • GitLab Workhorse
  • GitLab Elasticsearch Indexer
  • GitLab Zoekt Indexer
  • GitLab Agent for Kubernetes(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 구성을 참고합니다.

활성 사용자가 2000명을 넘고 매일 Git 쓰기 operation을 수행하는 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에는 info/refs 광고 캐시와 같은 최적화가 있으며, 이는 Gitaly가 공식 gRPC 인터페이스를 통해 리포지터리 액세스를 제어하고 모니터링하는 것을 전제로 합니다.
• Gitaly Cluster(Praefect)에는 내결함성과 분산 읽기 같은 최적화가 있으며, 이는 리포지터리 상태를 판단하기 위해 gRPC 인터페이스와 데이터베이스에 의존합니다.