GitLab Geo 핵심 가이드(분산 배포와 재해 복구 구조 이해)-고슴도치 군단

GitLab Geo 개요

GitLab Geo는 GitLab 인스턴스를 전 세계 여러 데이터센터에 분산 배포할 수 있게 해주는 엔터프라이즈 기능임.

글로벌 팀 환경에서 원격 저장소 접근 시 발생하는 레이턴시 문제를 줄이고, 주 사이트 장애 시 보조 사이트로 빠르게 전환해 서비스 연속성을 확보할 수 있음.

GitLab Premium 이상 플랜에서 사용 가능하며, 주 사이트(Primary Site)와 하나 이상의 보조 사이트(Secondary Site)로 구성됨.

주요 기능과 동작 원리

GitLab Geo는 주 사이트에서 발생하는 모든 변경 사항을 보조 사이트로 비동기 복제하는 방식으로 동작함.

Git 저장소, LFS 오브젝트, CI/CD 아티팩트, 컨테이너 레지스트리 이미지 등 다양한 데이터 유형을 복제 대상으로 지원함.

보조 사이트는 기본적으로 읽기 전용(Read-only)으로 운영되며, 사용자는 가까운 보조 사이트에서 Git 클론·풀 작업을 수행해 다운로드 속도를 크게 높일 수 있음.

복제 상태는 GitLab 관리자 패널의 Geo 대시보드에서 실시간으로 확인할 수 있으며, 데이터 유형별 동기화 비율과 오류 현황도 함께 제공됨.

구성 요소 및 아키텍처

GitLab Geo는 PostgreSQL 스트리밍 복제(Streaming Replication)를 통해 데이터베이스를 동기화하며, 파일·오브젝트는 별도 백그라운드 워커가 처리함.

주 사이트에서 변경이 발생하면 Geo Log Cursor가 이벤트를 감지하고, Geo Tracking Database가 복제 작업 큐를 관리하는 구조임.

핵심 구성 요소를 정리하면 아래와 같음:

• Primary Site: 모든 쓰기 작업이 이루어지는 주 인스턴스
• Secondary Site: 읽기 및 복제본 역할을 수행하는 보조 인스턴스
• Geo Tracking Database: 복제 상태를 추적하는 별도 PostgreSQL DB
• Geo Log Cursor: 주 사이트 이벤트 스트림을 감시하는 서비스
• Geo Proxy: 보조 사이트의 쓰기 요청을 주 사이트로 전달하는 컴포넌트

각 보조 사이트는 독립된 GitLab 인스턴스로 운영되며, 별도의 도메인과 SSL 인증서가 필요함.

설정 방법 기본 흐름

GitLab Geo 구성은 주 사이트 설정 → 보조 사이트 설치 → 데이터베이스 복제 연결 → Geo 활성화 순서로 진행됨.

주 사이트 gitlab.rb에 노드명을 지정하고 gitlab-ctl reconfigure를 실행하는 것이 첫 번째 단계임.

# /etc/gitlab/gitlab.rb (Primary)
gitlab_rails['geo_node_name'] = 'primary-site'

이후 관리자 패널 → Geo → Sites → Add site에서 주 사이트를 등록한 뒤, 보조 사이트 데이터베이스 복제를 설정함.

# 보조 사이트에서 실행 — 주 DB로부터 스트리밍 복제 초기화
gitlab-ctl geo replicate-db \
  --host=<primary-db-host> \
  --slot-name=<replication-slot>

보조 사이트 gitlab.rb에도 노드명을 추가하고, 관리자 패널에서 Primary URL과 연결 키를 입력하면 복제가 자동으로 시작됨.

# /etc/gitlab/gitlab.rb (Secondary)
gitlab_rails['geo_node_name'] = 'secondary-site'

설정 완료 후 Geo 대시보드에서 Replication Details 탭을 통해 각 데이터 유형별 동기화 진행률을 확인할 수 있음.

활용 시나리오

GitLab Geo가 가장 효과적인 시나리오는 글로벌 분산 개발 팀 환경임.

미국에 주 사이트를 두고 유럽·아시아에 보조 사이트를 배치하면, 각 지역 개발자가 가까운 서버에서 클론·풀 작업을 수행해 수십 배 빠른 다운로드 속도를 경험할 수 있음.

재해 복구(DR) 관점에서도 핵심 솔루션으로 활용됨.

주 사이트가 장애가 발생했을 때 보조 사이트를 새로운 주 사이트로 승격(Promotion)시켜 서비스 중단 시간을 최소화할 수 있음.

CI/CD 파이프라인 아티팩트와 컨테이너 이미지도 복제 대상에 포함되므로, 지역 가까운 보조 사이트에서 이미지를 풀받으면 빌드 속도도 개선됨.

규제 준수(Compliance) 목적으로 특정 데이터를 특정 지역 서버에만 저장해야 하는 경우에도 Geo 구성을 활용할 수 있음.

제한 사항 및 주의점

GitLab Geo의 복제는 비동기 방식이기 때문에 주 사이트와 보조 사이트 간 데이터 지연(Replication Lag)이 발생할 수 있음.

최신 커밋이 보조 사이트에 즉시 반영되지 않으므로, 방금 푸시한 변경 사항을 보조 사이트에서 바로 확인하려는 경우 주의가 필요함.

모든 데이터 유형이 복제되는 것은 아니며, GitLab 버전에 따라 지원 범위가 다르므로 공식 문서의 호환성 매트릭스를 반드시 확인해야 함.

Failover(장애 조치) 과정은 완전 자동화가 아니며, 관리자가 수동으로 보조 사이트를 승격하는 절차가 필요함.

GitLab.com 관리형 서비스에서는 Geo를 사용자가 직접 구성할 수 없고, Self-managed 환경에서만 설정 가능함.

네트워크 지연이 높은 환경에서 보조 사이트 쓰기 프록시를 사용하면 응답 속도에 영향을 줄 수 있으므로 네트워크 품질을 사전에 평가하는 것이 중요함.

마무리 및 요약

GitLab Geo는 글로벌 팀의 생산성과 서비스 안정성을 동시에 향상시킬 수 있는 강력한 엔터프라이즈 기능임.

설정 복잡도가 높은 편이지만, GitLab 공식 문서와 Geo 대시보드를 충분히 활용하면 운영 부담을 줄일 수 있음.

분산 팀 환경이나 체계적인 재해 복구 구성이 필요한 조직이라면, GitLab Geo 도입을 적극적으로 검토해볼 만한 가치가 있음.