모노레포 성능 문제 해결

모노레포 성능 문제에 대한 제안 사항을 검토합니다.

모노레포의 성능 문제에 대한 이러한 제안을 검토합니다. 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이 완료되기 전에 다음 호출이 실패하고 이것이 계속 발생하면 모노레포가 보조 노드에서 지속적으로 뒤처진 상태로 끝날 수 있습니다. 이로 인해 모든 트래픽이