GitLab 저장소 백업 시간을 48시간에서 41분으로 단축한 방법

• GitLab은 대용량 저장소 백업 시 오래 걸리는 문제를 발견하고 개선 작업을 수행함
• 핵심 원인은 15년 된 Git 함수의 O(N²) 복잡도였으며, 알고리듬 최적화를 통해 성능을 대폭 향상시킴
• 최적화 결과, 가장 큰 저장소의 백업 시간이 48시간에서 41분으로 줄어듦
• 개선된 방식은 리소스 효율성과 신뢰성을 제공함과 동시에 다른 Git 기반 툴과 커뮤니티에도 긍정적인 영향을 줌
• GitLab 18.0 버전부터 모든 사용자들이 추가 설정 없이 이러한 이점을 누릴 수 있게 됨

저장소 백업의 중요성과 과제

• 저장소 백업은 비상 복구 전략의 핵심 요소임
• 저장소 크기가 커질수록 신뢰할 만한 백업 과정의 복잡성이 증가함
• GitLab의 자체 Rails 저장소는 백업에 48시간이 소요되어, 백업 빈도와 시스템 성능 사이에서 선택의 어려움이 있었음
• 대규모 저장소에서 발생하는 시간, 리소스, 실패 위험, 레이스 컨디션 등 다양한 문제가 존재함
  • 예약 백업이 어렵거나, 외부 도구 의존 또는 백업 횟수 감소 등 조직별로 일관적이지 못한 전략이 나오게 됨

성능 병목 현상 분석과 원인 파악

• GitLab의 백업 기능은 git bundle create 명령을 활용하여 저장소 스냅샷을 생성함
• 이 명령의 구현 과정에서 reference(레퍼런스) 수 증가에 따라 성능 병목이 발생했음
• 수백만 개의 레퍼런스를 가진 대형 저장소의 백업에 48시간 이상이 소요되는 경우가 발생함

원인 분석

• 명령 실행 중 Flame Graph 분석으로 병목 구간 확인
• 레퍼런스가 10,000개일 때, 실행 시간의 약 80%가 object_array_remove_duplicates() 함수에서 소비됨
• 이 함수는 2009년에 해당 커밋에서 중복 레퍼런스 처리 목적으로 도입된 것임
  • git bundle create 사용 시 중복된 레퍼런스가 포함될 경우 문제 발생을 방지
  • 그러나 중복 검출이 중첩 for 루프 형태로 되어 있어 O(N²) 복잡도가 생김
  • 레퍼런스 수가 많아질수록 병목이 심화되는 구조임

O(N²)에서 효율적 매핑으로의 전환

• GitLab은 중첩 루프 대신 맵 자료구조를 이용한 방식으로 Git에 패치를 기여함
  • 각 레퍼런스를 맵에 추가하여 자동으로 중복을 제거하고, 효율적으로 처리함
• 이 변경으로 git bundle create 성능이 대폭 향상되고, 대규모 레퍼런스 환경에서도 확장 가능해짐
• 벤치마크 결과, 레퍼런스 10만 개 기준 6배 이상의 성능 개선 확인

대폭 줄어든 백업 시간과 효과

• 최대 저장소 백업 소요 시간이 48시간에서 41분(1.4% 수준)으로 감소함
• 저장소 크기와 무관하게 일관된 성능 제공이 가능함
• 서버 부하 감소, 백업 기반 Git 명령 전반의 성능 향상 등 부가 이점 확보
• 해당 패치는 업스트림 Git에 적용됐고, GitLab에서는 즉시 적용해 고객의 빠른 경험이 가능하도록 함

GitLab 고객을 위한 실제 변화

• 대기업 고객은 연속된 밤샘 백업을 개발 워크플로와 충돌 없이 실행할 수 있게 됨
• 복구 목표 지점(RPO) 이 줄어든 덕분에, 재해 상황에서 데이터 손실 위험이 대폭 축소됨
• 리소스 소비와 유지보수 시간, 클라우드 비용 등 운영 오버헤드까지 줄어듦
• 저장소 규모가 증가해도, 백업 빈도와 시스템 성능 사이에서 고민하지 않아도 됨
• 이제 모든 GitLab 사용자는 구성 변경 없이 이러한 이점을 누릴 수 있음

다음 단계 및 의미

• 이번 개선은 확장성 높은 엔터프라이즈급 Git 인프라 구축에 대한 GitLab의 지속적인 노력의 일부임
• GitLab이 기여한 변경사항은 업스트림 Git 프로젝트에도 반영되어, 업계 전반과 오픈소스 커뮤니티에 긍정적 파급 효과를 미침
• 이 같은 인프라 개선 노력이 다른 핵심 성능 개선 작업의 모델로 자리 잡고 있음

GitLab의 성능 접근 방식에 대한 더 깊은 이야기는 GitLab 18 버추얼 런치 이벤트에서 확인 가능함