• 사용 사례
  • Gitaly 클러스터
• 작동 방식
  • 아키텍처
• Geo 실행에 필요한 사항
  • 방화벽 규칙
    • 내부 URL
  • Geo 추적 데이터베이스
  • Geo 로그 커서
• 제한 사항
  • 복제/확인 제한 사항
• 설정 지침
• 설치 후 문서
  • Geo 구성
  • Geo 업그레이드
  • 복제 일시 중지 및 재개
  • 여러 노드에 대한 Geo 구성
  • 객체 리포지터리와 함께 Geo 구성
  • 재해 복구
  • 컨테이너 레지스트리 복제
  • Geo 보조 프록시
  • 단일 로그인(SSO)
    • LDAP
  • 보안 검토
  • Geo 튜닝
  • 위치 인식 Git URL 설정
  • 역배치
  • 러너
• Geo 사이트 제거
• Geo 비활성화
• 자주 묻는 질문
• 로그 파일
• 문제 해결

Geo

Geo는 널리 분산된 개발 팀과 재해 복구 전략의 일부로 웜 스탠바이를 제공하기 위한 솔루션입니다.

팀 및 러너가 단일 GitLab 인스턴스에서 멀리 떨어진 위치에 있을 경우 대형 리포지터리를 가져오는 데 오랜 시간이 걸릴 수 있습니다.

Geo는 원격 팀과 지리적으로 가까운 위치에 배치된 지역 캐시를 제공하여 읽기 요청을 수행할 수 있습니다. 이로써 대형 리포지터리의 복제 및 가져오는 데 걸리는 시간을 줄이고 개발 속도를 높이며 원격 팀의 프로덕션성을 높일 수 있습니다.

Geo 보조 사이트는 기본 사이트로의 쓰기 요청을 투명하게 프록시화합니다. 모든 Geo 사이트는 단일 GitLab URL에 응답하도록 구성할 수 있어 사용자가 어느 사이트에 접속하더라도 일관된, 통합적이고 포괄적인 경험을 제공할 수 있습니다.

적절한 문서 버전을 사용 중인지 확인하려면 GitLab.com의 Geo 페이지로 이동하여 Switch branch/tag 드롭다운 디렉터리에서 적절한 릴리스를 선택하십시오. 예를 들어, v15.7.6-ee를 참조하십시오.

Geo는 Geo 용어집에 설명된 정의 용어 집합을 사용합니다. 이 용어에 익숙해지도록 하십시오.

사용 사례

Geo를 구현하면 다음과 같은 이점을 제공합니다:

• 분산된 개발자들이 대형 리포지터리 및 프로젝트를 복제하고 가져오는 데 걸리는 시간을 몇 분에서 몇 초로 줄일 수 있습니다.
• 원하는 곳에서 모든 개발자가 아이디어를 기여하고 병행하여 작업할 수 있습니다.
• 기본 및 보조 사이트 사이의 읽기 전용 부하를 균형있게 유지할 수 있습니다.

또한:

• 제한 사항을 참조하십시오. GitLab 웹 인터페이스에서 사용 가능한 모든 데이터를 읽는 것 외에 프로젝트를 복제하고 가져오는 데 사용할 수 있습니다.
• 먼 사무실 간의 느린 연결을 극복하여 분산된 팀의 속도를 향상시켜 시간을 절약할 수 있습니다.
• 자동화된 작업, 사용자 정의 통합 및 내부 워크플로우의 로딩 시간을 줄이는 데 도움이 됩니다.
• 재해 복구 시나리오에서 보조 사이트로 빠르게 장애 극복할 수 있습니다.
• 보조 사이트로 계획된 장애 극복을 수행할 수 있습니다.

Geo는 다음을 제공합니다:

• 보조 사이트에서 완전한 GitLab 경험: 단일 기본 GitLab 사이트를 유지한 상태로 분산된 팀 각각에 대한 완전한 읽기 및 쓰기 및 UI 경험을 제공할 수 있습니다.
• 인증 시스템 후크: 보조 사이트는 모든 인증 데이터(사용자 계정 및 로그인과 같은)를 기본 인스턴스로부터 수신합니다.

Gitaly 클러스터

Geo는 Gitaly 클러스터와 혼동해서는 안 됩니다. Geo와 Gitaly 클러스터의 차이에 대한 자세한 내용은 Geo와 비교를 참조하십시오.

작동 방식

Geo 인스턴스를 사용하면 프로젝트 복제, 가져오기 및 모든 데이터 읽기 외에도 사용할 수 있습니다. 이는 멀리 떨어진 위치에서 대형 리포지터리를 다루는 것을 훨씬 더 빠르게 만듭니다.

Geo를 활성화하면:

• 원본 인스턴스는 기본 사이트로 알려져 있습니다.
• 복제 사이트는 보조 사이트로 알려져 있습니다.

기억해야 할 사항은:

• 보조 사이트는 기본 사이트에게 다음과 같은 정보를 전달합니다:
  • 로그인을 위한 사용자 데이터(API).
  • HTTPS + JWT를 통한 리포지터리, LFS 객체 및 첨부 파일 복제.
• 기본 사이트는 변경 사항을 통보하기 위해 보조 사이트에게 전달하지 않습니다(API).
• 보조 사이트로 직접 푸시할 수 있습니다(HTTP 및 SSH 모두에 대해, Git LFS를 포함).
• Geo 사용 시 제한 사항이 존재합니다.

아키텍처

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

이 다이어그램에서:

• 기본 사이트와 보조 사이트의 세부 사항이 나와 있습니다.
• 데이터베이스에 대한 쓰기는 오직 기본 사이트에서만 수행될 수 있습니다. 보조 사이트는 PostgreSQL 스트리밍 복제를 이용하여 데이터베이스 업데이트를 수신합니다.
• LDAP 서버가 있는 경우 재해 복구 시나리오에 대비하여 LDAP 서버를 구성해야 합니다.
• 보조 사이트에서는 JWT로 보호된 특별한 인증을 사용하여 기본 사이트에 대해 서로 다른 유형의 동기화를 수행합니다:
  • 리포지터리는 HTTPS를 통해 복제/업데이트됩니다.
  • 첨부 파일, LFS 객체 및 기타 파일은 특정한 API 엔드포인트를 사용하여 HTTPS를 통해 다운로드됩니다.

Git 작업을 수행하는 사용자의 관점에서:

• 기본 사이트는 전체 쓰기 가능한 GitLab 인스턴스로 동작합니다.
• 보조 사이트는 읽기 전용이지만 Git 푸시 작업을 기본 사이트로 프록시화합니다. 이로써 보조 사이트는 스스로 푸시 작업을 지원하는 것처럼 보입니다.
• 보조 사이트는 웹 UI 요청을 기본 사이트로 프록시화합니다. 이로써 보조 사이트는 전체적인 UI 읽기/쓰기 동작을 지원하는 것처럼 보입니다.

다이어그램을 단순화하기 위해 필요하지 않은 컴포넌트가 생략되어 있습니다.

• SSH를 통한 Git은 gitlab-shell과 OpenSSH가 필요합니다.
• HTTPS를 통한 Git은 gitlab-workhorse가 필요합니다.

보조 사이트에는 두 가지 다른 PostgreSQL 데이터베이스가 필요합니다:

• 주 데이터베이스로부터 데이터를 스트리밍하는 읽기 전용 데이터베이스 인스턴스.
• 보조 사이트 내부적으로 사용하는 읽기/쓰기 데이터베이스로 레플리케이션된 데이터를 기록하는 데 사용됩니다.

보조 사이트에서는 추가적인 데몬이 필요합니다: Geo 로그 커서.

Geo 실행에 필요한 사항

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

• OpenSSH 6.9 이상을 지원하는 운영 체제 (빠른 SSH 키를 데이터베이스에서 검색하기 위해 필요) 현재 버전의 OpenSSH를 제공하는 알려진 운영 체제는 다음과 같습니다:
  • CentOS 7.4 이상
  • Ubuntu 16.04 이상
• 가능한 경우, 모든 Geo 사이트에서 동일한 운영 체제 버전을 사용해야 합니다. 다른 운영 체제 버전을 사용하는 경우 모든 Geo 사이트 간에 OS 로캘 데이터 호환성을 확인하여 데이터베이스 인덱스가 손상되지 않도록 해야 합니다.
• 지원되는 PostgreSQL 버전 및 스트리밍 복제.
  • PostgreSQL 논리 복제는 지원되지 않습니다.
• 모든 사이트에서 동일한 PostgreSQL 버전을 실행해야 합니다.
• Git 2.9 이상
• LFS를 사용하는 경우 사용자 측에서 Git-lfs 2.4.2 이상
• 모든 사이트에서 정확히 동일한 GitLab 버전을 실행해야 합니다. 주 버전, 부 버전, 패치 버전이 모두 일치해야 합니다.
• 모든 사이트에서 동일한 리포지터리 스토리지 경로를 정의해야 합니다.

또한, GitLab 최소 요구 사항을 확인하고 더 나은 경험을 위해 GitLab의 최신 버전을 사용하십시오.

방화벽 규칙

다음 표는 Geo를 위한 주 및 보조 사이트 간에 열어둘 필요가 있는 기본 포트를 나열합니다. 장애 조치(Failover)를 간소화하기 위해 양방향으로 포트를 열어야 합니다.

GitLab에서 사용하는 포트의 전체 디렉터리은 패키지 기본값을 참조하십시오.

내부 URL

어떠한 Geo 보조 사이트에서도 주 Geo 사이트로의 HTTP 요청은 주 Geo 사이트의 내부 URL을 사용합니다. 이는 주 Geo 사이트 설정의 관리 영역에서 명확히 정의되지 않은 경우 주 사이트의 공개 URL이 사용됩니다.

주 Geo 사이트의 내부 URL을 업데이트하려면:

1. 좌측 사이드바에서 아래에서 관리 영역(Admin Area)을 선택합니다.
2. Geo > 사이트(Sites)를 선택합니다.
3. 주 사이트에서 편집(Edit)을 선택합니다.
4. 내부 URL을 변경한 다음 변경 사항 저장(Save changes)을 선택합니다.

Geo 추적 데이터베이스

추적 데이터베이스 인스턴스는 로컬 인스턴스에서 업데이트해야 할 메타데이터로 사용됩니다. 예를 들어,

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

복제된 데이터베이스 인스턴스는 읽기 전용이기 때문에 각 보조 사이트에 대해 이 추가 데이터베이스 인스턴스가 필요합니다.

Geo 로그 커서

이 데몬은 다음과 같은 작업을 수행합니다:

• 주 사이트가 보조 데이터베이스 인스턴스에 복제한 이벤트 로그를 읽습니다.
• 변경이 필요한 내용을 가진 Geo 추적 데이터베이스 인스턴스를 업데이트합니다.

추적 데이터베이스 인스턴스에서 업데이트해야 할 내용이 표시되면 보조 사이트에서 실행 중인 비동기 작업이 필요한 조치를 취하고 상태를 업데이트합니다.

이 새로운 아키텍처를 통해 GitLab은 사이트 간의 연결 문제에 대해 탄력적으로 대처할 수 있습니다. 보조 사이트가 주 사이트와 연결이 끊겨 있는 경우, 모든 이벤트를 올바른 순서대로 다시 재생하고 다시 주 사이트와 동기화될 수 있기 때문에 얼마나 긴 시간 동안 연결이 끊어져 있더라도 문제가 되지 않습니다.

제한 사항

• 보조 사이트로 직접 푸시하면(HTTP의 경우) 요청이 직접 처리될 대신 주 사이트로 리디렉션됩니다(HTTP에 대해서) 또는 프록시가 됩니다(SSH에 대해서). 이 제한으로 HTTP를 통해 URI에 포함된 자격 증명을 사용할 수 없습니다. 예를 들어 https://user:personal-access-token@secondary.tld와 같이 Git을 사용할 수 없습니다. 자세한 내용은 Geo 사이트 사용을 참조하십시오.
• OAuth 로그인을 위해서는 주 사이트가 온라인 상태여야 합니다. 기존 세션 및 Git에는 영향을 미치지 않습니다. 보조 사이트가 주 사이트와 독립된 OAuth 프로바이더를 사용할 수 있도록 하는 지원은 계획 중입니다.
• 설치는 여러 매뉴얼 단계가 필요합니다. 상황에 따라 약 1시간 정도 걸릴 수 있습니다. GitLab 환경 도구상자 Terraform 및 Ansible 스크립트를 사용하여 참조 아키텍처를 기반으로 프로덕션 GitLab 인스턴스를 배포하고 작동시키는 공통 일일 작업을 자동화하는 것을 고려하십시오. Epic 1465은 Geo 설치를 더 개선하는 것을 제안합니다.
• 실시간 이슈/Merge Request 업데이트(예: 롱 폴링을 사용)는 보조 사이트에서 동작하지 않습니다.
• Geo 보조 사이트를 사용하여 실행기를 가속화하는 것은 공식적으로 지원되지 않습니다. 이 기능을 지원하기 위한 계획이 있으며 epic 9779에서 추적할 수 있습니다. 주 사이트와 보조 사이트 사이에 복제 지연이 발생하고 파이프라인 참조가 실행되어 있지 않을 때 작업이 실행되면 작업이 실패합니다.
• 선택적 동기화는 어떤 리포지터리 및 파일이 복제되는지에 대한 제한만을 설정합니다. 전체 PostgreSQL 데이터는 여전히 복제됩니다. 선택적 동기화는 컴플라이언스/수출 통제 사용 사례를 수용하도록 구축되지 않았습니다.
• 페이지 액세스 제어는 보조 사이트에서 동작하지 않습니다. 자세한 내용은 GitLab 이슈 #9336를 참조하십시오.
• 다중 보조 사이트를 갖는 배포의 재해 복구는 모든 비전도된 보조를 새로운 주 사이트를 따르도록 완전히 다시 동기화하고 다시 구성해야 하므로 다운타임이 발생합니다.
• Git SSH를 이용한 프로젝트 클론 URL을 어떤 사이트를 브라우징하더라도 올바르게 표시하려면 보조 사이트는 주 사이트와 같은 포트를 사용해야 합니다. GitLab 이슈 #339262은 이 제한을 제거하기 위해 제안되었습니다.
• Git SSH를 통해 1.86GB를 초과하는 푸시는 보조 사이트에서 작동하지 않습니다. GitLab 이슈 #413109가 이 버그를 추적하고 있습니다.
• 백업은 보조에서 실행할 수 없습니다. (replication/troubleshooting/replication.md#message-error-canceling-statement-due-to-conflict-with-recovery).
• SSH를 통한 옵션 --depth로 Git 클론 및 가져오기 요청은 보조 사이트가 최신 상태가 아닌 경우 불명확하지 않게 작동하며 무기한 대기합니다. 자세한 내용은 이슈 391980을 참조하십시오.
• SSH를 통해 보조 사이트로 옵션을 사용한 Git 푸시는 작동하지 않으며 연결이 종료됩니다. 자세한 내용은 이슈 417186을 참조하십시오.
• 대부분의 경우 Geo 보조 사이트는 파이프라인의 첫 번째 단계에 대한 복제 요청을 가속화하지 않습니다. 나중에 나올 단계들에 대해 장담할 수 없습니다. 예를 들어 Git 변경 사항이 크거나 대역폭이 작거나 파이프라인 단계가 짧을 경우입니다. 일반적으로 그것은 후속 단계에 대한 클론 요청을 제공합니다. 이슈 446176에서 이것의 이유를 논의하고 Runner 클론 요청이 보조 사이트에서 제공될 확률을 높이기 위한 개선을 제안합니다.

복제/확인 제한 사항

GitLab의 모든 데이터 유형 및 복제 및 확인을 위한 기존 지원에 대한 전체 디렉터리이 있습니다.

설정 지침

설정 지침은 Geo 설정을 참조하십시오.

설치 후 문서

GitLab을 보조 사이트에 설치한 후 초기 구성을 완료하면, 설치 후 정보를 얻기 위해 다음 문서를 참조하십시오.

Geo 구성

Geo 구성에 대한 정보는 Geo 구성을 참조하십시오.

Geo 업그레이드

최신 GitLab 버전으로 Geo 사이트를 업데이트하는 방법에 대한 정보는 Geo 사이트 업그레이드를 참조하십시오.

복제 일시 중지 및 재개

업그레이드나 계획된 장애 교대와 같은 일부 상황에서는 주 사이트와 보조 사이트 간 복제를 일시 중지하는 것이 바람직할 수 있습니다.

업그레이드 중에 보조 사이트에서 사용자 활동을 허용할 계획이라면, 제로 다운타임 업그레이드를 위해 복제를 중지하지 마십시오. 일시 중지되는 동안 보조 사이트는 점점 더 오래된 정보가 됩니다. 알려진 효과 중 하나는 Git fetch가 더 많이 주 사이트로 리디렉션되거나 프록시된다는 것입니다. 추가되는 알 수 없는 효과가 있을 수 있습니다.

복제 일시 중지 및 재개는 보조 사이트의 특정 노드에서 명령줄 도구를 통해 수행됩니다. 데이터베이스 구조에 따라 이는 postgresql 또는 patroni 서비스를 대상으로 할 것입니다.

• 보조 사이트에서 모든 서비스에 대한 단일 노드를 사용하는 경우, 이러한 명령을 해당 단일 노드에서 실행해야 합니다.
• 보조 사이트에서 독립적인 PostgreSQL 노드를 사용하는 경우, 이러한 명령을 해당 독립적인 PostgreSQL 노드에서 실행해야 합니다.
• 보조 사이트가 Patroni 클러스터를 사용하는 경우, 이러한 명령을 보조 Patroni 스탠바이 리더 노드에서 실행해야 합니다.

보조 사이트에서 모든 서비스에 대한 단일 노드를 사용하고 있지 않은 경우, PostgreSQL 또는 Patroni 노드의 /etc/gitlab/gitlab.rb가 구성 줄 gitlab_rails['geo_node_name'] = 'node_name'을 포함하는지 확인하십시오. 여기서 node_name은 애플리케이션 노드의 geo_node_name과 동일해야 합니다.

일시 중지: (보조 사이트에서)

또한, 복제 일시 중지 후 PostgreSQL이 다시 시작되면(VM을 다시 시작하거나 gitlab-ctl restart postgresql로 서비스를 다시 시작하는 경우), PostgreSQL은 업그레이드나 계획된 장애 교대 시에 원치 않는 자동 복제를 재개합니다.

gitlab-ctl geo-replication-pause

재개: (보조 사이트에서)

gitlab-ctl geo-replication-resume

여러 노드에 대한 Geo 구성

여러 노드에 대한 Geo 구성에 대한 정보는 여러 서버용 Geo를 참조하십시오.

객체 리포지터리와 함께 Geo 구성

객체 리포지터리와 함께 Geo를 구성하는 방법에 대한 정보는 객체 리포지터리와 함께 Geo를 참조하십시오.

재해 복구

재해 복구 상황에서 데이터 손실을 완화하고 서비스를 복구하는 방법에 대한 정보는 재해 복구를 참조하십시오.

컨테이너 레지스트리 복제

컨테이너 레지스트리를 복제하는 방법에 대한 자세한 내용은 보조 사이트용 컨테이너 레지스트리를 참조하십시오.

Geo 보조 프록시

보조 사이트에서 Geo 프록시를 사용하는 방법에 대한 자세한 내용은 보조 사이트용 Geo 프록시를 참조하십시오.

단일 로그인(SSO)

단일 로그인(SSO) 구성에 대한 자세한 내용은 단일 로그인(SSO)을 사용한 Geo를 참조하십시오.

LDAP

LDAP 구성에 대한 자세한 내용은 단일 로그인(SSO) > LDAP를 사용한 Geo를 참조하십시오.

보안 검토

Geo 보안에 대한 자세한 내용은 Geo 보안 검토를 참조하십시오.

Geo 튜닝

Geo 튜닝에 대한 자세한 내용은 Geo 튜닝를 참조하십시오.

위치 인식 Git URL 설정

AWS Route53을 사용하여 위치 인식 Git 원격 URL을 설정하는 예제에 대한 자세한 내용은 AWS Route53를 사용한 위치 인식 Git 원격 URL을 참조하십시오.

역배치

보조 사이트가 설정되면, 주 사이트에서 알려진 역배치 프로세스에서 주 사이트에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

역배치 중 발생하는 오류는 역배치 평가의 마지막에서 다시 시도될 예정입니다.

러너

• 저희 표준적인 러너 플릿 배포 방법에 추가하여, 러너는 작업 부하를 분산시키기 위해 Geo 보조에 연결할 수도 있습니다. 보조에 러너 등록을 참조하십시오.
• 러너와 함께 재해 복구를 처리하는 방법도 참조하십시오.

Geo 사이트 제거

Geo 사이트를 제거하는 방법에 대한 자세한 내용은 보조 Geo 사이트 제거를 참조하십시오.

Geo 비활성화

Geo 비활성화 방법에 대한 자세한 내용은 Geo 비활성화를 참조하십시오.

자주 묻는 질문

자주 묻는 질문에 대한 답변은 Geo FAQ를 참조하십시오.

로그 파일

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

Geo 로그에 액세스하고 사용하는 방법에 대한 자세한 내용은 로그 시스템 설명서의 Geo 섹션를 참조하십시오.

문제 해결

문제 해결 단계에 대한 자세한 내용은 Geo 문제 해결을 참조하십시오.