Geo는 널리 분산된 개발 팀을 위한 솔루션이자 재해 복구 전략의 일부로 웜 스탠바이를 제공하는 솔루션입니다. Geo는 곧바로 쓸 수 있는 HA 솔루션은 아닙니다.

문서 버전이 맞는지 확인하려면 GitLab.com의 Geo 페이지로 이동해 Switch branch/tag 드롭다운 목록에서 해당 릴리스를 선택합니다. 예를 들면 v19.2.0-ee 입니다.

단일 GitLab 인스턴스에서 멀리 떨어진 팀과 러너는 대규모 리포지터리를 가져오는 데 오랜 시간이 걸릴 수 있습니다.

Geo는 원격 팀과 지리적으로 가까운 곳에 배치해 읽기 요청을 처리할 수 있는 로컬 캐시를 제공합니다. 이를 통해 대규모 리포지터리를 클론하고 가져오는 시간을 줄여 개발 속도를 높이고 원격 팀의 생산성을 높일 수 있습니다.

Geo 보조 사이트는 쓰기 요청을 기본 사이트로 투명하게 프록시합니다. 모든 Geo 사이트는 단일 GitLab URL에 응답하도록 구성할 수 있으므로, 사용자가 어느 사이트에 접속하든 일관되고 끊김 없는 전체 기능의 경험을 제공합니다.

Geo는 Geo 용어집에 설명된 정의된 용어 집합을 사용합니다. 해당 용어를 먼저 익혀 둡니다.

사용 사례#

Geo를 도입하면 여러 사용 사례를 해결할 수 있습니다. 이 섹션에서는 의도된 사용 사례 일부와 그 이점을 설명합니다.

리전 단위 재해 복구#

재해 복구 솔루션으로서의 Geo는 기본 사이트와 다른 리전에 웜 스탠바이 보조 사이트를 제공합니다. 데이터가 보조 사이트로 지속적으로 동기화되므로 항상 최신 상태가 유지됩니다. 데이터 센터나 네트워크 중단, 하드웨어 장애 같은 재해가 발생하면 완전히 동작하는 보조 사이트로 장애 조치할 수 있습니다. 계획된 장애 조치로 재해 복구 절차와 인프라를 테스트할 수 있습니다.

이점은 다음과 같습니다.

• 리전 단위 재해 발생 시 비즈니스 연속성을 확보합니다.
• 복구 시간 목표(RTO)와 복구 시점 목표(RPO)가 낮습니다.
• GitLab Environment Toolkit(GET)으로 자동화된(다만 자동 실행은 아닌) 장애 조치를 수행합니다.
• 운영 부담이 적습니다. 별도 개입 없이 지속적으로 복제와 검증이 이뤄지므로 보조 사이트가 최신 상태로 유지되고, 복제된 데이터가 전송 중과 저장 상태에서 손상되지 않습니다.

원격 팀 가속#

원격 팀과 지리적으로 가까운 곳에 Geo 보조 사이트를 구축해 읽기 작업을 가속하는 로컬 캐시를 제공합니다. Geo 보조 사이트는 여러 개 둘 수 있고, 각 사이트가 원격 팀에 필요한 프로젝트만 동기화하도록 맞출 수 있습니다. 투명 프록시와 통합 URL 기반 지리적 라우팅으로 일관되고 끊김 없는 개발자 경험을 보장합니다.

이점은 다음과 같습니다.

• 지리적으로 분산된 팀의 GitLab 경험을 개선합니다. Geo는 보조 사이트에서 완전한 GitLab 경험을 제공합니다. 하나의 기본 GitLab 사이트를 유지하면서, 분산된 각 팀에 읽기·쓰기 액세스와 완전한 UI 경험을 갖춘 보조 사이트를 제공합니다.
• 분산된 개발자가 대규모 리포지터리와 프로젝트를 클론하고 가져오는 시간을 몇 분에서 몇 초로 줄입니다.
• 위치에 관계없이 모든 개발자가 아이디어를 내고 병렬로 작업할 수 있습니다.
• 기본 사이트와 보조 사이트 사이에서 읽기 부하를 분산합니다.
• 멀리 떨어진 사무실 간의 느린 연결을 극복해 분산 팀의 속도를 높이고 시간을 절약합니다.
• 자동화 작업, 사용자 지정 통합, 내부 워크플로의 로딩 시간을 줄입니다.

CI/CD 트래픽 분산#

CI/CD 러너가 Geo 보조 사이트에서 클론하도록 구성할 수 있습니다. 보조 사이트는 러너 워크로드의 요구에 맞게 구성할 수 있으며 기본 사이트를 그대로 미러링할 필요가 없습니다. 지원되는 읽기 요청은 보조 사이트의 캐시 데이터로 처리되고, 보조 사이트의 데이터가 오래되었거나 존재하지 않으면 요청이 기본 사이트로 투명하게 전달됩니다.

이점은 다음과 같습니다.

• 트래픽을 보조 사이트로 옮겨 기본 사이트에서 CI/CD 트래픽이 사용자 경험에 미치는 영향을 줄입니다.
• 리전 간 트래픽을 줄이고 조직에 가장 경제적인 위치에 CI/CD 컴퓨팅 시간을 배치합니다. 리전 간 데이터 복사본을 하나만 만들어 두고 보조 사이트에 대한 반복적인 읽기 요청에 사용합니다.

추가 사용 사례#

인프라 마이그레이션#

Geo를 사용해 새 인프라로 마이그레이션할 수 있습니다. GitLab 인스턴스를 새 서버나 데이터 센터로 옮길 때, 기존 인스턴스가 계속 사용자에게 서비스를 제공하는 동안 Geo로 GitLab 데이터를 백그라운드에서 새 인스턴스로 마이그레이션합니다. 활성 GitLab 데이터의 변경 사항은 새 인스턴스로 복사되므로 전환 시점에 데이터 손실이 없습니다.

Geo로 PostgreSQL 데이터베이스를 한 운영체제에서 다른 운영체제로 마이그레이션할 수는 없습니다. PostgreSQL 운영체제 업그레이드를 참고합니다.

이점은 다음과 같습니다.

• 백업·복원 마이그레이션 방식에 비해 마이그레이션 중 다운타임을 크게 줄입니다. 전환 다운타임 구간 이전에 활성 GitLab 인스턴스를 중단하지 않고 백그라운드에서 새 인스턴스로 데이터를 복사합니다.

GitLab Dedicated로 마이그레이션#

Geo를 사용해 GitLab Self-Managed에서 GitLab Dedicated로 마이그레이션할 수도 있습니다. GitLab Dedicated 로의 마이그레이션은 인프라 마이그레이션과 유사합니다.

자세한 내용은 Geo로 GitLab Dedicated 마이그레이션을 참고합니다.

이점은 다음과 같습니다.

• 다운타임이 크게 줄어 온보딩이 매끄럽습니다. 백그라운드에서 데이터 마이그레이션이 진행되는 동안 팀은 GitLab Self-Managed를 계속 사용할 수 있습니다.

Geo가 다루도록 설계되지 않은 영역#

Geo가 모든 사용 사례를 다루도록 설계된 것은 아닙니다. 이 섹션에서는 Geo가 적절한 해법이 아닌 사용 사례의 예를 설명합니다.

데이터 수출 규정 준수 강제#

Geo의 선택적 동기화 기능으로 보조 사이트에 동기화되는 프로젝트를 제한할 수 있지만, 이 기능은 수출 규정 준수를 강제하기 위해서가 아니라 리전 간 트래픽과 스토리지 요구 사항을 줄이기 위해 설계되었습니다. 개인정보 보호, 사이버 보안, 적용되는 무역 통제 법령과 관련한 법적 의무는 솔루션과 문서를 근거로 사용자가 지속적으로 직접 판단해야 합니다. 솔루션과 문서는 모두 변경될 수 있습니다.

액세스 제어 제공#

Geo의 읽기 전용 보조 사이트 기능은 정식 기능이 아니며 향후 지원되지 않을 수 있습니다. 액세스 제어 목적으로 이 기능에 의존하지 않아야 합니다. GitLab은 이 목적에 더 적합한 인증 및 권한 부여 제어 기능을 제공합니다.

무중단 업그레이드의 대안#

Geo는 무중단 업그레이드를 위한 해법이 아닙니다. 보조 사이트를 업그레이드하기 전에 기본 Geo 사이트를 먼저 업그레이드해야 합니다.

악의적이거나 의도치 않은 손상 방지#

Geo는 기본 사이트의 손상을 모든 보조 사이트로 복제합니다. 악의적이거나 의도치 않은 손상에 대비하려면 Geo를 백업과 함께 사용해야 합니다.

액티브-액티브 고가용성 구성#

Geo는 액티브-패시브 고가용성 솔루션으로 설계되었습니다. Geo는 최종 일관성 동기화 모델로 동작하므로 보조 사이트가 기본 사이트와 엄밀하게 동기화되지는 않습니다. 보조 사이트는 약간의 지연을 두고 기본 사이트를 따라가므로 재해 발생 시 소량의 데이터 손실이 생길 수 있습니다. 재해 발생 시 보조 사이트로의 장애 조치에는 사람의 개입이 필요합니다. 다만 모든 사이트를 GET으로 배포했다면 보조 사이트를 기본 사이트로 승격하는 과정의 상당 부분은 GitLab Environment Toolkit(GET)으로 자동화됩니다.

Gitaly Cluster (Praefect)#

Geo를 Gitaly Cluster (Praefect)와 혼동하지 않아야 합니다. Geo와 Gitaly Cluster (Praefect)의 차이에 관한 자세한 내용은 Geo와의 비교를 참고합니다.

Geo 동작 방식#

GitLab 환경에서 Geo가 동작하는 방식을 간단히 요약하면 다음과 같습니다. 자세한 내용은 Geo 개발 문서를 참고합니다.

Geo 인스턴스는 데이터를 읽는 것 외에도 프로젝트를 클론하고 가져오는 데 사용할 수 있습니다. 덕분에 먼 거리에서 대규모 리포지터리를 다루는 작업이 훨씬 빨라집니다.

Geo를 활성화하면 다음과 같이 부릅니다.

• 원본 인스턴스는 기본 사이트입니다.
• 복제 사이트는 보조 사이트입니다.

다음 사항에 유의합니다.

• 보조 사이트는 다음을 위해 기본 사이트와 통신합니다.
  • 로그인용 사용자 데이터 조회(API).
  • 리포지터리, LFS 오브젝트, 첨부 파일 복제(HTTPS + JWT).
• 기본 사이트는 복제 상세 정보를 보기 위해 보조 사이트와 통신합니다. 기본 사이트는 동기화 및 검증 데이터를 얻기 위해 보조 사이트에 GraphQL 쿼리를 실행합니다(API).
• Git LFS를 포함해 HTTP와 SSH 모두 보조 사이트로 직접 푸시할 수 있으며, 보조 사이트는 그 요청을 기본 사이트로 프록시합니다.
• Geo를 사용할 때 몇 가지 알려진 문제가 있습니다.

아키텍처#

다음 다이어그램은 Geo의 기반 아키텍처를 보여 줍니다.

이 다이어그램의 내용은 다음과 같습니다.

• 기본 사이트와 보조 사이트 한 곳의 상세 구성이 있습니다.
• 데이터베이스 쓰기는 기본 사이트에서만 수행할 수 있습니다. 보조 사이트는 PostgreSQL 스트리밍 복제로 데이터베이스 업데이트를 받습니다.
• LDAP 서버가 있다면 재해 복구 상황에 대비해 복제하도록 구성해야 합니다.
• 보조 사이트는 JWT로 보호되는 특수 인증을 사용해 기본 사이트를 대상으로 여러 유형의 동기화를 수행합니다.
  • 리포지터리는 HTTPS 상의 Git으로 클론·업데이트됩니다.
  • 첨부 파일, LFS 오브젝트, 기타 파일은 비공개 API 엔드포인트를 통해 HTTPS로 다운로드됩니다.

Git 작업을 수행하는 사용자 관점에서는 다음과 같습니다.

• 기본 사이트는 읽기·쓰기가 모두 가능한 완전한 GitLab 인스턴스로 동작합니다.
• 보조 사이트도 읽기·쓰기가 모두 가능한 완전한 GitLab 인스턴스로 동작합니다. 보조 사이트는 몇 가지 주요 예외를 제외한 모든 작업을 기본 사이트로 투명하게 프록시합니다. 특히 보조 사이트가 최신 상태이면 Git fetch를 보조 사이트가 직접 처리합니다.

GitLab UI를 탐색하거나 API를 사용하는 사용자 관점에서는 다음과 같습니다.

• 기본 사이트는 읽기·쓰기가 모두 가능한 완전한 GitLab 인스턴스로 동작합니다.
• 보조 사이트도 읽기·쓰기가 모두 가능한 완전한 GitLab 인스턴스로 동작합니다. 보조 사이트는 몇 가지 주요 예외를 제외한 모든 작업을 기본 사이트로 투명하게 프록시합니다. 특히 웹 UI 자산은 보조 사이트가 제공합니다.

다이어그램을 단순하게 유지하기 위해 일부 필수 구성 요소는 생략했습니다.

• SSH 상의 Git에는 gitlab-shell 이 필요합니다.
• HTTPS 상의 Git에는 workhorse가 필요합니다.

보조 사이트에는 두 개의 서로 다른 PostgreSQL 데이터베이스가 필요합니다.

• 메인 GitLab 데이터베이스에서 데이터를 스트리밍받는 읽기 전용 데이터베이스 인스턴스.
• 어떤 데이터가 복제되었는지 기록하기 위해 보조 사이트가 내부적으로 사용하는 읽기·쓰기 데이터베이스 인스턴스(추적 데이터베이스).

보조 사이트는 추가 데몬인 Geo Log Cursor도 실행합니다.

Geo 실행 요구 사항#

Geo를 실행하려면 다음이 필요합니다.

• OpenSSH 6.9 이상을 지원하는 운영체제 (데이터베이스에서 인가된 SSH 키 빠른 조회에 필요합니다). 다음 운영체제는 최신 버전의 OpenSSH를 함께 제공하는 것으로 알려져 있습니다.
  • CentOS 7.4 이상
  • Ubuntu 16.04 이상
• 가능하다면 모든 Geo 사이트에서 동일한 운영체제 버전을 사용해야 합니다. Geo 사이트 간에 서로 다른 운영체제 버전을 사용한다면 데이터베이스 인덱스가 조용히 손상되는 것을 막기 위해 Geo 사이트 전반에 걸쳐 OS 로캘 데이터 호환성을 확인해야 합니다.
• 스트리밍 복제를 지원하는, 해당 GitLab 릴리스의 지원되는 PostgreSQL 버전.
  • PostgreSQL 논리적 복제는 지원되지 않습니다.
• 모든 사이트가 동일한 PostgreSQL 버전을 실행해야 합니다.
• Git 2.9 이상
• LFS를 사용할 때 사용자 측의 Git-lfs 2.4.2 이상
• 모든 사이트가 정확히 동일한 GitLab 버전을 실행해야 합니다. 메이저, 마이너, 패치 버전이 모두 일치해야 합니다. 사이트의 GitLab 버전을 확인하려면 sudo gitlab-rake gitlab:env:info를 실행합니다. 자세한 내용은 GitLab 및 시스템 정보 수집을 참고합니다.
• 모든 사이트가 동일한 리포지터리 스토리지를 정의해야 합니다.
• Geo와 함께 컨테이너 레지스트리를 사용할 때는 각 사이트에서 컨테이너 레지스트리 메타데이터 데이터베이스용으로 별도의 외부 PostgreSQL 인스턴스를 구성해야 합니다. 자세한 내용은 보조 사이트의 컨테이너 레지스트리를 참고합니다.

추가로 GitLab 최소 요구 사항을 확인하고, 더 나은 사용 경험을 위해 최신 버전의 GitLab을 사용합니다.

Geo는 기본 GitLab 설치본 위에 추적 데이터베이스와 복제 메타데이터를 추가하므로, 리포지터리 데이터가 없는 최소 Geo 배포에서도 사이트당 최소 40GB의 디스크 공간을 확보해야 합니다. 자세한 내용은 스토리지 요구 사항을 참고합니다.

방화벽 규칙#

다음 표는 Geo를 위해 기본 사이트와 보조 사이트 사이에 열어야 하는 기본 포트를 정리한 것입니다. 장애 조치를 단순하게 하려면 양방향으로 포트를 열어야 합니다.

GitLab 이 사용하는 포트 전체 목록은 패키지 기본값을 참고합니다.

추가로 다음 사항을 확인합니다.

• 웹 터미널을 지원하려면 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때는 로드 밸런서가 Connection 및 Upgrade 홉 바이 홉 헤더를 그대로 전달하도록 구성해야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참고합니다.
• 포트 443에 HTTPS 프로토콜을 사용할 때는 로드 밸런서에 SSL 인증서를 추가해야 합니다. 대신 GitLab 애플리케이션 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용합니다.
• 외부·내부 URL에 HTTPS만 사용한다면 방화벽에서 포트 80을 열 필요가 없습니다.

내부 URL#

Geo 보조 사이트에서 기본 Geo 사이트로 보내는 HTTP 요청은 기본 Geo 사이트의 내부 URL을 사용합니다. Admin 영역의 기본 Geo 사이트 설정에 내부 URL 이 명시되어 있지 않으면 기본 사이트의 공개 URL 이 사용됩니다.

사전 요구 사항:

• 관리자 액세스 권한.

기본 Geo 사이트의 내부 URL을 업데이트하는 방법은 다음과 같습니다.

1. 오른쪽 위 모서리에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.
3. 기본 사이트에서 Edit를 선택합니다.
4. Internal URL을 변경한 다음 Save changes를 선택합니다.

Geo 추적 데이터베이스#

추적 데이터베이스 인스턴스는 로컬 인스턴스에서 무엇을 업데이트해야 하는지 제어하는 메타데이터로 사용됩니다. 예를 들면 다음과 같습니다.

• 새 자산 다운로드.
• 새 LFS 오브젝트 가져오기.
• 최근 업데이트된 리포지터리에서 변경 사항 가져오기.

복제된 데이터베이스 인스턴스는 읽기 전용이므로 보조 사이트마다 이 추가 데이터베이스 인스턴스가 필요합니다.

Geo Log Cursor#

이 데몬은 다음을 수행합니다.

• 기본 사이트가 보조 데이터베이스 인스턴스로 복제한 이벤트 로그를 읽습니다.
• 실행해야 하는 변경 사항으로 Geo 추적 데이터베이스 인스턴스를 업데이트합니다.

추적 데이터베이스 인스턴스에서 업데이트 대상으로 표시되면, 보조 사이트에서 실행 중인 비동기 job 이 필요한 작업을 수행하고 상태를 업데이트합니다.

이 아키텍처 덕분에 GitLab은 사이트 간 연결 문제에 견딜 수 있습니다. 보조 사이트가 기본 사이트와 얼마나 오래 끊겨 있었는지는 문제가 되지 않습니다. 모든 이벤트를 올바른 순서로 다시 재생해 기본 사이트와 다시 동기화할 수 있기 때문입니다.

알려진 문제#

• 보조 사이트로 직접 푸시하면 요청이 직접 처리되지 않고 기본 사이트로 리디렉션(HTTP)되거나 프록시(SSH)됩니다. https://user:personal-access-token@secondary.tld처럼 URI에 자격 증명을 포함한 HTTP 상의 Git은 사용할 수 없습니다. 자세한 내용은 Geo 사이트 사용을 참고합니다.
• OAuth 로그인이 이뤄지려면 기본 사이트가 온라인 상태여야 합니다. 기존 세션과 Git은 영향을 받지 않습니다. 보조 사이트가 기본 사이트와 독립적인 OAuth 공급자를 사용하도록 지원하는 방안이 계획되어 있습니다.
• 설치에는 여러 수동 단계가 필요하며, 상황에 따라 전체적으로 한 시간 정도 걸릴 수 있습니다. 참조 아키텍처에 기반한 프로덕션 GitLab 인스턴스를 배포·운영하고 일상적인 작업을 자동화하려면 GitLab Environment Toolkit의 Terraform 및 Ansible 스크립트 사용을 고려합니다. 에픽 1465는 Geo 설치를 한층 더 개선할 것을 제안합니다.
• 이슈·머지 리퀘스트의 실시간 업데이트(예: 롱 폴링)는 HTTP 프록시가 비활성화된 보조 사이트에서는 동작하지 않습니다.
• 선택적 동기화는 어떤 리포지터리와 파일을 복제할지만 제한합니다. PostgreSQL 데이터 전체는 여전히 복제됩니다. 선택적 동기화는 규정 준수나 수출 통제 사용 사례를 위해 만들어진 기능이 아닙니다.
• Pages 액세스 제어는 보조 사이트에서 동작하지 않습니다. 자세한 내용은 이슈 9336을 참고합니다.
• 보조 사이트가 여러 개인 배포의 재해 복구에서는 승격되지 않은 모든 보조 사이트가 새 기본 사이트를 따르도록 PostgreSQL 스트리밍 복제를 다시 초기화해야 하므로 다운타임이 발생합니다.
• SSH 상의 Git에서는 어느 사이트를 탐색하든 프로젝트 클론 URL 이 올바르게 표시되도록 보조 사이트가 기본 사이트와 동일한 포트를 사용해야 합니다. 자세한 내용은 이슈 339262를 참고합니다.
• 백업은 Geo 보조 사이트에서 실행할 수 없습니다.
• Geo 보조 사이트는 대부분의 경우 파이프라인 첫 Stage의 클론 요청을 가속(직접 처리)하지 않습니다. 이후 Stage도 보조 사이트가 처리한다고 보장되지는 않습니다. 예를 들어 Git 변경이 크거나, 대역폭이 작거나, 파이프라인 Stage가 짧은 경우입니다. 일반적으로는 이후 Stage의 클론 요청을 처리합니다. 이슈 446176에서 그 이유를 설명하고, 러너 클론 요청이 보조 사이트에서 처리될 가능성을 높이는 개선안을 제안합니다.
• 하나의 Git 리포지터리가 충분히 높은 빈도로 푸시를 받으면 보조 사이트의 로컬 사본이 계속 최신 상태가 되지 못할 수 있습니다. 이 경우 해당 리포지터리의 모든 Git fetch가 기본 사이트로 전달됩니다. 자세한 내용은 이슈 455870을 참고합니다.
• 프록시는 Puma 서비스 또는 Web 서비스의 GitLab 애플리케이션에만 구현되어 있으므로 다른 서비스는 이 동작의 혜택을 받지 못합니다. 요청이 항상 기본 사이트로 전달되도록 별도 URL을 사용해야 합니다. 해당 서비스는 다음과 같습니다.
  • GitLab 컨테이너 레지스트리. registry.example.com처럼 자체 도메인을 사용하도록 구성할 수 있습니다. 보조 사이트의 컨테이너 레지스트리는 재해 복구 용도로만 사용합니다. 데이터가 기본 사이트로 전파되지 않으므로 사용자를 그쪽으로 라우팅하지 않아야 하며, 특히 푸시는 더욱 그렇습니다.
  • GitLab Pages. GitLab Pages 실행 사전 요구 사항에 따라 항상 별도 도메인을 사용해야 합니다.
• 통합 URL을 사용할 때 Let's Encrypt는 같은 도메인으로 두 IP에 모두 도달할 수 있어야 인증서를 생성할 수 있습니다. Let's Encrypt로 TLS 인증서를 사용하려면 도메인을 Geo 사이트 중 하나로 수동으로 지정해 인증서를 생성한 다음 다른 모든 사이트로 복사할 수 있습니다.
• 보조 사이트가 기본 사이트와 별도 URL을 사용하는 경우, SAML로 보조 사이트에 로그인하는 것은 SAML IdP(ID 공급자)가 애플리케이션에 여러 콜백 URL을 구성하도록 허용할 때만 지원됩니다.
• 요청을 시작하는 시점에 보조 사이트가 최신 상태가 아니고 geo_proxy_fetch_ssh_to_primary 기능 플래그가 비활성화되어 있으면, 보조 사이트를 대상으로 SSH를 통해 --depth 옵션을 사용한 Git 클론·fetch 요청이 무한정 멈춥니다. 자세한 내용은 이슈 391980을 참고합니다. 이 플래그는 GitLab 19.4 이상에서 기본적으로 활성화되어 있습니다. 번들 NGINX Ingress를 사용하는 Cloud Native GitLab 배포는 19.4로 업그레이드하기 전에 조치해야 합니다.
• GitLab Geo에서는 상대 URL을 사용하지 않습니다. 사이트 간 프록시가 동작하지 않게 됩니다. 자세한 내용은 이슈 456427을 참고합니다.

복제되는 데이터 유형#

GitLab의 전체 데이터 유형 및 복제되는 데이터 유형 목록이 있습니다.

설치 후 문서#

보조 사이트에 GitLab을 설치하고 초기 구성을 마친 다음에는 설치 후 정보를 다루는 아래 문서를 참고합니다.

Geo 설정#

Geo 구성에 관한 자세한 내용은 Geo 설정을 참고합니다.

오브젝트 스토리지와 함께 Geo 구성#

오브젝트 스토리지와 함께 Geo를 구성하는 방법은 오브젝트 스토리지와 함께 사용하는 Geo를 참고합니다.

컨테이너 레지스트리 복제#

컨테이너 레지스트리를 복제하는 방법에 관한 자세한 내용은 보조 사이트의 컨테이너 레지스트리를 참고합니다.

Geo 사이트용 통합 URL 설정#

AWS Route53 또는 Google Cloud DNS로 위치 인식 단일 URL을 설정하는 예시는 Geo 사이트용 통합 URL 설정을 참고합니다.

통합 인증(SSO)#

통합 인증(SSO) 구성에 관한 자세한 내용은 통합 인증(SSO)과 함께 사용하는 Geo를 참고합니다.

LDAP#

LDAP 구성에 관한 자세한 내용은 통합 인증(SSO)과 함께 사용하는 Geo > LDAP를 참고합니다.

Geo 튜닝#

Geo 튜닝에 관한 자세한 내용은 Geo 튜닝을 참고합니다.

복제 일시 중지 및 재개#

자세한 내용은 복제 일시 중지 및 재개를 참고합니다.

데이터 재동기화 및 재검증#

개별 구성 요소나 여러 구성 요소를 대상으로 복제 또는 검증을 수동으로 다시 시도하는 방법은 Geo 데이터 재동기화 및 재검증을 참고합니다.

백그라운드 job#

Geo 백그라운드 워커, 큐 안전성, 복구 메커니즘에 관한 자세한 내용은 Geo 백그라운드 job을 참고합니다.

백필#

보조 사이트를 설정하면 백필 이라고 하는 과정으로 기본 사이트에서 누락된 데이터를 복제하기 시작합니다. 브라우저에서 기본 사이트의 Geo Nodes 대시보드를 통해 각 Geo 사이트의 동기화 진행 상황을 모니터링할 수 있습니다.

백필 중에 발생한 실패는 백필이 끝난 뒤 재시도되도록 예약됩니다.

러너#

• 러너 플릿 배포에 관한 표준 모범 사례에 더해, job 부하를 분산하도록 러너가 Geo 보조 사이트에 연결하게 구성할 수도 있습니다. 보조 사이트에 러너 등록 방법을 참고합니다.
• 장애 조치 중 러너 연결 처리 방법도 함께 참고합니다.

Geo 업그레이드#

Geo 사이트를 최신 GitLab 버전으로 업데이트하는 방법은 Geo 사이트 업그레이드를 참고합니다.

보안 검토#

Geo 보안에 관한 자세한 내용은 Geo 보안 검토를 참고합니다.

Geo 사이트 제거#

Geo 사이트 제거에 관한 자세한 내용은 Geo 보조 사이트 제거를 참고합니다.

Geo 비활성화#

Geo를 비활성화하는 방법은 Geo 비활성화를 참고합니다.

로그 파일#

Geo는 구조화된 로그 메시지를 geo.log 파일에 저장합니다.

Geo 로그에 접근하고 활용하는 방법에 관한 자세한 내용은 로그 시스템 문서의 Geo 섹션을 참고합니다.

재해 복구#

데이터 손실을 줄이고 서비스를 복구하기 위해 재해 상황에서 Geo를 사용하는 방법은 재해 복구를 참고합니다.

자주 묻는 질문#

일반적인 질문에 대한 답변은 Geo FAQ를 참고합니다.

문제 해결#

• Geo 문제 해결 절차는 Geo 문제 해결을 참고합니다.
• 재해 복구 문제 해결 절차는 Geo 장애 조치 문제 해결을 참고합니다.