Gitaly

Git 리포지터리 액세스를 관리하는 Gitaly 서비스의 아키텍처, 구성, CLI 및 모범 사례.

Gitaly 는 Git 리포지터리에 대한 고수준 원격 프로시저 호출(RPC) 액세스를 제공합니다. GitLab이 Git 데이터를 읽고 쓰는 데 사용됩니다. Gitaly는 모든 GitLab 설치에 포함되어 있으며 Git 리포지터리 스토리지 및 검색을 조정합니다. Gitaly는 다음과 같이 설정할 수 있습니다: 단일 인스턴스 Linux 패키지 설치(한 머신에 모든 GitLab)에서 백그라운드 서비스로 실행. 확장 및 가용성 요건에 따라 별도 인스턴스로 분리하여 전체 클러스터 구성으로 구성. Note Gitaly는 GitLab의 Git 리포지터리 액세스만 관리합니다. 다른 유형의 GitLab 데이터는 Gitaly를 사용하여 액세스하지 않습니다. 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 - 1