모노레포의 성능 문제에 관한 다음 제안을 검토합니다.

git clone 또는 git fetch 중 느림#

클론과 페치가 느려지는 데에는 몇 가지 주요 원인이 있습니다.

높은 CPU 사용률#

Gitaly 노드의 CPU 사용률이 높다면 특정 값을 필터링하여 클론이 CPU를 얼마나 사용하는지 확인할 수 있습니다.

특히 command.cpu_time_ms 필드는 클론과 페치가 CPU를 얼마나 사용하는지 나타냅니다.

대부분의 경우 서버 부하의 대부분은 클론과 페치 중에 시작되는 git-pack-objects 프로세스에서 발생합니다. 모노레포는 대체로 매우 분주하며 CI/CD 시스템은 서버에 많은 클론 및 페치 명령을 보냅니다.

높은 CPU 사용률은 성능 저하의 일반적인 원인입니다. 다음과 같이 서로 배타적이지 않은 원인이 있을 수 있습니다.

• Gitaly가 처리하기에 너무 많은 클론.
• Gitaly 클러스터(Praefect)의 읽기 분배 불량.

원인: 너무 많은 대형 클론#

Gitaly가 처리하기에 너무 많은 대형 클론이 있을 수 있습니다. Gitaly는 다음과 같은 여러 요인으로 따라가지 못할 수 있습니다.

• 리포지터리의 크기.
• 클론과 페치의 양.
• CPU 용량 부족.

Gitaly가 많은 대형 클론을 처리하도록 하려면 다음과 같은 최적화 전략으로 Gitaly 서버의 부담을 줄여야 할 수 있습니다.

• git-pack-objects가 수행해야 하는 작업을 줄이도록 pack-objects-cache를 켭니다.
• CI/CD 설정에서 Git 전략을 clone에서 fetch 또는 none으로 변경합니다.
• 테스트에 태그가 필요하지 않다면 태그 페치를 중지합니다.
• 가능한 경우 얕은 클론을 사용 합니다.

다른 방법은 Gitaly 서버의 CPU 용량을 늘리는 것입니다.

원인: 읽기 분배 불량#

Gitaly 클러스터(Praefect)의 읽기 분배가 불량할 수 있습니다.

읽기 트래픽 대부분이 클러스터 전체로 분배되지 않고 기본 Gitaly 노드로 향하는지 확인하려면 읽기 분배 Prometheus 메트릭을 사용합니다.

보조 Gitaly 노드가 트래픽을 많이 받지 못한다면 보조 노드가 계속 동기화되지 않은 상태일 수 있습니다. 이 문제는 모노레포에서 더 심해집니다.

모노레포는 대체로 크고 분주합니다. 이는 두 가지 결과로 이어집니다. 첫째, 모노레포에는 푸시가 자주 발생하고 많은 CI job이 실행됩니다. 브랜치 삭제와 같은 쓰기 작업이 보조 노드에 대한 프록시 호출에 실패하는 경우가 있습니다. 이때 Gitaly 클러스터(Praefect)에서 복제 job이 트리거되어 보조 노드가 결국 따라잡게 됩니다.

복제 job은 본질적으로 보조 노드에서 기본 노드로 수행하는 git fetch이며, 모노레포는 대체로 매우 크기 때문에 이 페치에는 오랜 시간이 걸릴 수 있습니다.

이전 복제 job이 완료되기 전에 다음 호출이 실패하고 이런 상황이 계속되면 모노레포가 보조 노드에서 지속적으로 뒤처진 상태가 될 수 있습니다. 이렇게 되면 모든 트래픽이 기본 노드로 향합니다.

프록시된 쓰기가 실패하는 한 가지 이유는 Git $GIT_DIR/packed-refs 파일의 알려진 이슈입니다. 파일에서 항목을 제거하려면 파일을 잠가야 하므로, 동시 삭제가 발생할 때 삭제가 실패하는 경쟁 조건이 생길 수 있습니다.

GitLab 엔지니어들은 참조 삭제를 일괄 처리하는 완화책을 개발했습니다.

GitLab이 참조 삭제를 일괄 처리하도록 다음 기능 플래그를 켭니다. 이 기능 플래그는 활성화할 때 다운타임이 필요하지 않습니다.

• merge_request_cleanup_ref_worker_async
• pipeline_cleanup_ref_worker_async
• pipeline_delete_gitaly_refs_in_batches
• merge_request_delete_gitaly_refs_in_batches

에픽 4220은 GitLab에 RefTable 지원을 추가하도록 제안하며, 이는 장기적인 해결책으로 간주됩니다.