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는 읽기와 쓰기 처리량이 높아야 합니다. 참고로 다음 차트는 GitLab.com의 Gitaly 프로덕션 플릿 전반의 P99 디스크 IOPS를 1분 단위로 보여줍니다. 데이터는 월요일 아침에 시작해 월요일 아침에 끝나는 7일 대표 기간에서 쿼리했습니다. 업무 주중에 트래픽이 몰리면서 IOPS가 주기적으로 치솟는 점에 주목합니다. 원시 데이터에서는 더 큰 스파이크가 나타나며 쓰기는 8000 IOPS까지 올라갑니다. Gitaly 요청이 중단되지 않으려면 사용 가능한 디스크 처리량이 이러한 스파이크를 감당해야 합니다. P99 디스크 IOPS(읽기): P99 디스크 IOPS(쓰기): 일반적으로 다음 수치가 나타납니다