GitLab은 재해 복구(Disaster Recovery) 전략을 지원하고, GitLab 오리지널 인스턴스에서 멀리 떨어진 개발팀의 지연을 줄이는 기능을 제공합니다. 바로 ‘GitLab Geo’(이하 Geo)인데요. Geo는 조직에 재해 복구 전략이 필요하거나, 여러 지역에 흩어진 개발팀이 GitLab에 접속해 작업을 수행할 때 도움이 됩니다.
Geo를 사용하면 재해 복구 환경을 조성하는 시간과 노력을 크게 절감할 수 있고요. 분산된 개발팀은 거리에 구애받지 않은 채 GitLab의 리포지터리, 프로젝트를 신속히 복제하고 가져올 수 있습니다. 이 글에서는 Geo 기능과 이점, 아키텍처를 소개하고요. GitLab의 Geo 로드맵을 알아보며, 향후 기능 개선 방향을 살펴보겠습니다!
GitLab Geo란?
개념
Geo는 지리적으로 분산된 개발팀을 위한 솔루션입니다. 이는 재해 복구 전략의 일환으로 ‘웜 스탠바이(warm standby)’*도 제공하죠. GitLab Premium, Ultimate 사용자라면, 자체 관리형 환경에서 Geo를 이용할 수 있습니다.
주요 기능
Geo는 ‘원격팀과 지리적으로 가까운 곳에 위치해 읽기 요청을 처리하는’ 로컬 캐시를 제공합니다. 이는 대용량 리포지터리를 복제하고 가져오는 시간을 줄여주죠. 그 결과, 개발 속도가 높아지고, 원격팀의 생산성도 향상될 수 있습니다.
Geo는 주요 GitLab 데이터 유형을 복제하고 검증하는 구조로, 장애 발생 시 프로세스에 따라 연속성 있게 GitLab을 사용·운영하는 재해 복구 기능도 지원합니다. 참고로 Geo는 GitLab의 재해 복구 솔루션 기반 기술을 사용합니다.
동작 원리
Geo 보조 사이트는 기본 사이트에 쓰기 요청을 투명하게 프록시 처리합니다. 모든 Geo 사이트는 단일 GitLab URL에 응답하도록 구성할 수 있는데요. 이로써 사용자는 ‘자신이 접속하는 Geo 사이트와 관계없이’ GitLab에 원활히 들어갈 수 있습니다.
아울러 Geo는 다양한 GitLab 데이터세트를 ‘조정되고, 검증할 수 있으며, 일관된 방식으로’ 새로운 사이트에 복제하는데요. 이로써 여러 곳에 있는 GitLab 서버 구성을 확장할 수 있죠. 사용자 요청은 위치 인식 URL을 사용해 사용자와 가장 가까운 Geo 사이트로 전달되고요. 지능형 프록시 기술은 사용자가 최신 데이터에 접근하도록 보장합니다.
*웜 스탠바이: 재해 복구 전략 중 하나로, 데이터를 백업하고, 실행할 때 더 능동적임. 이는 백그라운드에서 지속적으로 실행됨. 따라서 기술 재해가 발생하면 백업 시스템이 기본 시스템을 미러링해 모든 걸 정상화할 수 있음. 단, 보조 시스템은 핫 시스템(hot system)만큼 빠르게 백업하지 않음. 이에 기술 재해가 발생하기 전 백업이 아주 신속하게 이뤄지지 않으면 데이터는 다를 수 있음. 웜 스탠바이는 만일의 상황을 대비해 항상 대기하는 게 특징임.
GitLab Geo 이점
Geo를 사용하면 다음 장점을 누릴 수 있습니다.
- GitLab 인스턴스를 여러 위치에 구성할 수 있습니다.
- 재해 복구 시나리오에서 보조 사이트로 신속하게 장애 조치를 취할 수 있습니다.
- 보조 사이트로 '계획한 장애 조치'도 취할 수 있습니다.
- 기본 사이트와 보조 사이트 간에 읽기 전용 부하를 분산할 수 있습니다.
- GitLab의 다양한 데이터를 복제할 수 있습니다(제한 사항 및 지원 데이터 유형 참조).
- GitLab 서버와 멀리 떨어진 사용자의 연결 속도를 높여 ‘분산된 개발팀’의 작업 속도를 향상하고, 시간을 절약할 수 있습니다.
- 자동화된 작업, 맞춤형 통합, 내부 워크플로의 로딩 시간을 단축할 수 있습니다.
- 분산된 개발자가 대용량 리포지터리, 프로젝트를 복제하고 가져오는 소요 시간을 분 단위에서 초 단위로 줄일 수 있습니다.
- 개발팀은 지역에 상관없이 아이디어와 코드를 기여하고 리뷰하며, 동시에 작업할 수 있습니다.
GitLab Geo 아키텍처
동작 방식
위 이미지는 Geo 동작 방식을 나타냈습니다. 미국 샌프란시스코에 있는 기본 사이트(Primary Site)와 네덜란드에 있는 보조 사이트(Secondary Site)에서 Geo가 동작하는 방식을 보여줍니다. 참고로 Geo가 활성화될 때, 오리지널 인스턴스를 ‘기본 사이트’, 복제 사이트를 ‘보조 사이트’라고 합니다.
기본적인 동작 방식은 아래와 같습니다.
- 보조 사이트는 기본 사이트와 통신해 로그인을 위한 사용자 데이터(API)를 가져옵니다. 또 리포지터리·LFS 개체, 첨부 파일(HTTPS + JWT) 데이터를 복제합니다.
- 보조 사이트로 직접 push 할 수 있습니다(Git LFS를 포함한 HTTP, SSH 모두).
- 기본 사이트는 변경 사항을 알리기 위해 보조 사이트와 통신하지 않습니다(API).
아키텍처
위 이미지는 Geo 기본 아키텍처를 설명한 다이어그램인데요. 기본 사이트(Primary Site)와 보조 사이트(Secondary Site)의 세부 사항을 볼 수 있습니다. 각 컴포넌트와 동작 방식은 아래와 같은데요.
- ‘데이터베이스(DB)에 쓰기’는 기본 사이트에서만 수행할 수 있습니다. 보조 사이트는 PostgreSQL 스트리밍 복제를 사용해 DB 업데이트를 받습니다.
- 보조 사이트에는 ‘Geo Log Cursor’라는 추가 데몬을 실행합니다.
- LDAP 서버는 재해 복구 시나리오를 위해 복제하도록 구성합니다.
- 보조 사이트는 JWT로 보호되는 특수 권한을 사용해 기본 사이트에 다양한 유형의 동기화를 수행합니다.
- 리포지터리는 HTTPS를 통해 Git으로 복제/업데이트됩니다.
- 첨부 파일, LFS 개체, 기타 파일은 비공개 API 엔드포인트를 사용해 HTTPS를 통해 다운로드됩니다.
Git 작업을 수행하는 사용자 관점에서
- 기본 사이트는 전체 읽기-쓰기가 가능한 GitLab 인스턴스로 작동합니다.
- 보조 사이트는 읽기 전용이지만 기본 사이트에 Git push 작업을 프록시 처리합니다. 이로써 보조 사이트가 push 작업 자체를 지원하는 걸로 보입니다.
- 보조 사이트는 웹 UI 요청을 기본 사이트에 프록시 처리합니다. 이로써 보조 사이트가 전체 UI 읽기/쓰기 작업을 지원하는 걸로 보입니다.
한편, 보조 사이트는 복제된 데이터를 기록하기 위해 보조 사이트에서 내부적으로 사용하는 읽기/쓰기 DB 인스턴스(추적 DB)가 필요합니다.
아울러 위 이미지에 빠졌지만 Geo에는 다음 필수 구성 요소도 포함됩니다.
- Git SSH를 사용하려면
gitlab-shell과 OpenSSH가 필요합니다. - Git HTTPS를 사용하려면
gitlab-workhorse가 필요합니다.
Geo 로드맵과 개선 방향
GitLab은 Geo를 재해 복구, Geo 복제, 백업과 복원 등 세 가지 카테고리로 나눠 성숙도를 각각 측정합니다. 카테고리별 성숙도와 기능 내용은 아래와 같습니다(2024년 1분기 기준).
- 재해 복구(성숙도: Competitive) - 자연재해 또는 인재에 따른 재해가 발생했을 때, 기본 사이트로 승격할 수 있는 보조 사이트에 중요한 GitLab 데이터를 모두 복제합니다.
- Geo 복제(성숙도: Viable) - 지리적 위치에 더 가까운 Geo 사이트의 데이터를 제공해 사용자가 GitLab 데이터에 더 빨리 접근하고, 더 효과적으로 작업할 수 있습니다.
- 백업과 복원(성숙도: Minimal) - 중요한 GitLab 데이터 모두를 백업, 복원합니다.
아울러 GitLab은 Geo를 발전시키기 위해 다음 로드맵을 계획하고 있습니다(2024년 1분기 기준).
Geo 옵저버빌리티 향상
Geo에서 시스템 관리자가 현재 실행 중인 작업, 앞으로 실행하려는 작업, 실패한 작업을 모니터링하도록 해당 작업의 옵저버빌리티를 개선하려 합니다. 실패한 작업 관련 기능으로, Geo는 실패의 근본 원인을 해결하도록 돕는 정보를 UI에 표시할 예정입니다. ‘보조 사이트 설정이 성공적이었는지’, ‘복제 프로세스가 잘 진행되는지’ 피드백을 바로 제공하려는데요. 이로써 보조 사이트를 처음 설정하는 시스템 관리자의 경험을 향상하고자 합니다.
다양한 데이터 유형 가속화 지원
컨테이너 레지스트리, CI job, 파이프라인 아티팩트와 같이 규모가 크고, 가장 자주 접근하는 데이터 유형을 확인해 고객에게 가장 큰 가치를 전달하는, 영향력이 큰 데이터 유형에 집중할 계획입니다. 이를 위해 Geo는 보조 사이트에서 기본 사이트로 프록시 처리되는 데이터 유형의 통계를 수집할 예정입니다. 이로써 ‘앞으로 어떤 데이터 유형을 가속화할지’ 더 많은 정보를 참조해 결정할 수 있습니다.
UI에서 데이터 유형별 Geo 복제 비활성화 기능
관리자가 Geo Administrator UI에서 데이터 유형별로 복제를 활성화 또는 비활성화하는 간편한 방법을 제공하고자 합니다.
더 쉽고 간단한 설정 지원
단일, 다중 노드 사이트에서 Geo 설치와 구성을 간소화해 시스템 구성과 운영의 어려움을 해소하고, GitLab 아키텍처 선택에 도움을 줄 예정입니다.
CI job에 Geo 보조 사이트 사용
앞으로 Geo는 CI 러너가 Geo 보조 사이트에서 복제하도록 지원해 CI job을 가속화할 계획입니다. 이는 CI 러너가 가장 가까운 보조 사이트에서 직접 복제된 데이터를 가져와 기본 사이트의 부하를 줄이는 데 도움이 될 수 있습니다. 쓰기는 일관성을 유지하기 위해 기본 사이트로 계속 프록시 처리될 예정입니다.
Geo 메트릭 대시보드 게시
현재 시스템 관리자는 Geo 웹 UI를 사용해 Geo 상태의 기본 개요를 얻을 수 있습니다. 또한 Geo는 다양한 Prometheus 메트릭 목록을 생성합니다. 그러나 이러한 메트릭을 적절하게 사용하기란 쉽지 않습니다. Grafana 대시보드를 활용하면 시스템 관리자가 이러한 메트릭에 더 쉽게 접근하고 이를 유용하게 사용할 수 있습니다. GitLab은 이러한 대시보드를 이미 만들었는데요. Geo 팀은 이 대시보드의 유지 관리와 업데이트를 맡을 계획입니다. 아울러 이 대시보드를 게시해 고객이 다운로드하고, 자신의 Grafana 인스턴스로 가져오도록 지원할 예정입니다.
DB 분리 지원
자체 관리형 고객에게 분리된 DB를 배포할 계획입니다. 여기에는 메인 Rails DB를 메인 DB와 CI DB로 분리해 확장성과 성능을 개선하는 작업도 포함됩니다.
맺음말
지금까지 Geo의 기능과 이점, 아키텍처, 로드맵을 살펴봤는데요. Geo는 기업 규모에 상관없이 어디서나 사용자 경험을 향상하고, 부하를 분산하며, 재해 복구 계획을 세우는 데 유용합니다. GitLab은 사용자와 관리자 경험을 향상하기 위해 꾸준히 로드맵을 업데이트하고요. Geo 지원 범위와 기능을 업그레이드합니다. 이 글이 Geo 이해도를 높이고, 여러분 환경에 적합한 GitLab 아키텍처를 선택하는 데 도움이 되길 바랍니다.
인포그랩은 GitLab과 DevOps를 맞춤형으로 기술 지원합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 지원이 필요하시면 문의하기로 연락해 주십시오.