모노레포 성능 개선

모노레포를 최적화하고 성능 문제를 식별하는 전략을 알아봅니다.

모노레포는 하위 프로젝트를 포함하는 저장소입니다. 단일 애플리케이션에는 종종 상호 의존적인 프로젝트가 포함됩니다. 예를 들어 백엔드, 웹 프론트엔드, iOS 애플리케이션, Android 애플리케이션이 있습니다. 모노레포는 일반적이지만 성능 위험을 초래할 수 있습니다. 일반적인 문제: 대용량 바이너리 파일. 긴 기록을 가진 많은 파일. 많은 동시 클론 및 푸시. 수직 확장 제한. 네트워크 대역폭 제한. 디스크 대역폭 제한. GitLab 자체는 Git을 기반으로 합니다. GitLab의 Git 저장소 서비스인 Gitaly 는 모노레포와 관련된 성능 제약을 경험합니다. 저희가 배운 것이 자신의 모노레포를 더 잘 관리하는 데 도움이 될 수 있습니다. 어떤 저장소 특성이 성능에 영향을 미칠 수 있는지. 모노레포를 최적화하는 도구 및 단계. 모노레포를 위한 Gitaly 최적화 # Git은 공간을 덜 사용하기 위해 객체를 팩파일 로 압축합니다. 클론, 페치 또는 푸시할 때 Git은 팩파일을 사용합니다. 팩파일은 디스크 공간과 네트워크 대역폭을 줄이지만 팩파일 생성에는 많은 CPU와 메모리가 필요합니다. 대규모 모노레포는 소규모 저장소보다 더 많은 커밋, 파일, 브랜치, 태그를 가집니다. 객체가 커지고 전송 시간이 길어질수록 팩파일 생성이 더 비용이 많이 들고 느려집니다. Git에서 git-pack-objects 프로세스가 가장 리소스 집약적인 작업입니다. 이 프로세스는: 커밋 기록과 파일을 분석합니다. 클라이언트에 다시 보낼 파일을 결정합니다. 팩파일을 만듭니다. git clone 및 git fetch 에서의 트래픽은 서버에서 git-pack-objects 프로세스를 시작합니다. GitLab CI/CD와 같은 자동화된 지속적 통합 시스템은 이 트래픽의 많은 부분을 일으킬 수 있습니다. 많은 자동화된 CI/CD 트래픽은 많은 클론 및 페치 요청을 보내며 Gitaly 서버에 부담을 줄 수 있습니다. Gitaly 서버의 부하를 줄이기 위해 다음 전략을 사용하세요. Gitaly pack-objects 캐시 활성화 # 클론과 페치에 대한 서버 부하를 줄이는 Gitaly pack-objects 캐시 를 활성화합니다. Git 클라이언트가 클론 또는 페치 요청을 보낼 때 git-pack-objects 가 생성한 데이터를 재사용을 위해 캐시할 수 있습니다. 모노레포가 자주 클론되는 경우 Gitaly pack-objects 캐시 를 활성화하면 서버 부하가 줄어듭니다. 활성화되면 각 클론 또는 페치 호출마다 응답 데이터를 재생성하는 대신 Gitaly는 인메모리 캐시를 유지합니다. 자세한 내용은 팩 객체 캐시 를 참조하세요. Git 번들 URI 구성 # CDN과 같은 낮은 지연 시간을 가진 서드파티 저장소에 Git 번들 을 만들고 저장합니다. Git은 먼저 번들에서 패키지를 다운로드한 다음 Git 원격에서 나머지 객체와 참조를 페치합니다. 이 방법은 객체 데이터베이스를 더 빠르게 부트스트랩하고 Gitaly의 부하를 줄입니다. GitLab 서버에 대한 네트워크 연결이 좋지