모노레포 성능 개선

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

모노레포는 하위 프로젝트를 포함하는 리포지터리입니다. 하나의 애플리케이션은 서로 의존하는 여러 프로젝트로 구성되는 경우가 많습니다. 예를 들어 백엔드, 웹 프론트엔드, iOS 애플리케이션, Android 애플리케이션이 있습니다. 모노레포는 흔하지만 성능 위험을 안고 있습니다. 대표적인 문제는 다음과 같습니다: 대용량 바이너리 파일. 히스토리가 긴 다수의 파일. 동시에 발생하는 다수의 클론과 푸시. 수직 확장의 한계. 네트워크 대역폭의 한계. 디스크 대역폭의 한계. GitLab 자체도 Git을 기반으로 합니다. GitLab의 Git 스토리지 서비스인 Gitaly 역시 모노레포에 따르는 성능 제약을 겪습니다. GitLab 이 얻은 경험은 사용자가 모노레포를 더 잘 관리하는 데 도움이 됩니다. 성능에 영향을 줄 수 있는 리포지터리 특성. 모노레포를 최적화하는 도구와 단계. 모노레포를 위한 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는 클론 또는 페치 호출마다 응답 데이터를 다시 만들지 않고 메모리 내 캐시를 유지합니다. 자세한 내용은 Pack-objects 캐시 를 참고합니다. Git 번들 URI 구성 # Git 번들 을 만들어 CDN처럼 지연 시간이 짧은 서드파티 스토리지에 저장합니다. Git은 먼저 번들에서 패키지를 내려받은 다음, 남은 객체와 참조를 Git 원격에서 페치합니다. 이 방식은 객체 데이터베이스를 더 빠르게 준비하고 Gitaly의 부하를 줄입니다. GitLab 서버와의 네트워크 연결 상태가 좋지