• 데이터 유형
  • Git 리포지터리
  • 블롭
  • 데이터베이스
• 복제/확인에 대한 제한
  • 피처 플래그 뒤에 숨겨진 복제된 데이터 유형
    • 일부 데이터 유형의 복제 활성화/비활성화

지원되는 Geo 데이터 유형

Geo 데이터 유형은 하나 이상의 GitLab 기능에서 필요로 하는 특정 데이터 클래스로서 관련 정보를 저장하는 데 필요합니다.

이러한 기능에서 생성된 데이터를 Geo로 복제하기 위해 접근, 전송 및 검증을 위해 여러 전략을 사용합니다.

데이터 유형

우리는 세 가지 다른 데이터 유형을 구별합니다:

• Git 리포지터리
• Blobs
• 데이터베이스

아래 디렉터리에서는 복제하는 각 기능 또는 컴포넌트, 해당 데이터 유형, 복제 및 검증 방법을 보여줍니다:

• (1): Redis 복제는 Redis Sentinel의 HA의 일부로 사용할 수 있습니다. 이것은 Geo 사이트 사이에서 사용되지 않습니다.
• (2): 객체 리포지터리 복제는 Geo나 귀하의 객체 리포지터리 제공업체/장치의 네이티브 복제 기능으로 수행될 수 있습니다.
• (3): 객체 리포지터리 검증은 16.4에 도입된 피처 플래그, geo_object_storage_verification을 사용하여 기본적으로 활성화됩니다. 이는 파일 크기의 체크섬을 사용하여 파일을 확인합니다.

Git 리포지터리

GitLab 인스턴스는 하나 이상의 리포지터리 샤드를 가질 수 있습니다. 각 샤드에는 로컬로 저장된 Git 리포지터리에 대한 액세스 및 작업을 허용하는 Gitaly 인스턴스가 있습니다. 이는 다음과 같은 머신에서 실행될 수 있습니다:

• 단일 디스크를 사용한 경우
• 하나의 마운트 지점으로 여러 디스크를 마운트한 경우 (예: RAID 배열 사용)
• LVM을 사용하는 경우

GitLab은 특별한 파일 시스템이 필요하지 않으며, 마운트된 리포지터리 장치와 함께 작동할 수 있습니다. 그러나 원격 파일 시스템을 사용할 경우 성능 제한과 일관성 문제가 발생할 수 있습니다.

Geo는 Gitaly에서 쓰레기 수집을 트리거하여 Geo 보조 사이트에서 포크된 리포지터리를 중복 제거합니다.

Gitaly gRPC API는 통신을 수행하며, 동기화에는 세 가지 가능한 방법이 있습니다:

• 특별한 인증을 사용하여 Geo 사이트 간에 정규 Git clone/fetch를 사용합니다.
• 리포지터리 스냅숏을 사용합니다 (첫 번째 방법이 실패하거나 리포지터리가 손상된 경우).
• 관리 영역에서 매뉴얼 트리거를 사용합니다 (위 두 방법을 결합한 것).

각 프로젝트는 최대 3개의 다른 리포지터리를 가질 수 있습니다:

• 프로젝트 리포지터리: 소스 코드가 저장되는 곳
• 위키 리포지터리: 위키 콘텐츠가 저장되는 곳
• 디자인 리포지터리: 디자인 자산이 인덱싱되는 곳 (실제 자산은 LFS에 저장됨)

모든 리포지터리는 동일한 샤드에 존재하며 위키 및 디자인 리포지터리의 경우 -wiki 및 -design 접미사가 있는 동일한 기본 이름을 공유합니다.

또한 스니펫 리포지터리도 있습니다. 이는 프로젝트 또는 특정 사용자에 연결될 수 있으며 두 유형 모두 보조 사이트로 동기화됩니다.

블롭

GitLab은 이슈 첨부 파일이나 LFS 객체와 같은 파일과 블롭을 다음 중 하나에 저장합니다.

• 특정 위치의 파일 시스템.
• 객체 리포지터리 솔루션. 객체 리포지터리 솔루션은 다음과 같을 수 있습니다:
  • Amazon S3나 Google Cloud Storage와 같은 클라우드 기반.
  • MinIO와 같이 사용자가 호스팅하는 경우.
  • 객체 리포지터리 호환 API를 노출하는 리포지터리 장치.

여러 노드를 사용할 때 GitLab을 실행할 때 Object Storage 대신 파일 시스템 리포지터리를 사용하는 경우 네트워크 마운트된 파일 시스템을 사용합니다.

복제 및 확인과 관련하여:

• 우리는 내부 API 요청을 사용하여 파일과 블롭을 전송합니다.
• 객체 리포지터리를 사용하면 다음과 같이 할 수 있습니다:
  • 클라우드 제공자 복제 기능 사용.
  • GitLab이 대신 복제하도록 지시.

데이터베이스

GitLab은 다양한 사용 사례에 대해 여러 데이터베이스에 저장된 데이터에 의존합니다. PostgreSQL은 Web 인터페이스에서 사용자 생성 콘텐츠(이슈 콘텐츠, 코멘트)뿐만 아니라 권한과 자격 증명과 같은 사용자 생성 콘텐츠의 한계점에 대한 단일 진실 지점입니다.

또한 PostgreSQL은 HTML로 렌더링된 Markdown 및 캐시된 Merge Request 차이와 같은 일부 수준의 캐시된 데이터를 보유할 수 있습니다. 이를 객체 리포지터리로 오프로드하도록 구성할 수도 있습니다.

우리는 PostgreSQL의 자체 복제 기능을 사용하여 기본(primary)에서 보조(secondary) 사이트로 데이터를 복제합니다.

Redis는 캐시 리포지터리로 사용되며 백그라운드 작업 시스템에 지속적인 데이터를 보유하는 데에도 사용됩니다. 두 사용 사례 모두 동일한 Geo 사이트에 독점적인 데이터가 있기 때문에 우리는 사이트 간에 데이터를 복제하지 않습니다.

Elasticsearch는 고급 검색을 위한 선택적 데이터베이스입니다. 이는 소스 코드 수준과 이슈, Merge Request, 토의에서 사용자 생성 콘텐츠의 검색을 개선할 수 있습니다. Elasticsearch는 Geo에서 지원되지 않습니다.

복제/확인에 대한 제한

다음 표에서는 보조 사이트에 대한 GitLab 기능과 해당 복제 및 확인 상태를 나열합니다.

이러한 누락된 요소를 구현하기 위한 진행 상황을 이슈/업무에서 추적할 수 있습니다.

• Geo: 자체 서비스 Geo 복제 프레임워크 개선
• 기존 블롭을 프레임워크로 이동

피처 플래그 뒤에 숨겨진 복제된 데이터 유형

일부 데이터 유형에 대한 복제는 해당 피처 플래그 뒤에 있습니다:

• 피처 플래그 뒤에 배포되어 있으며 기본적으로 사용 중입니다.
• GitLab.com에서 사용 중입니다.
• 프로젝트 단위로 사용/비사용을 설정할 수 없습니다.
• 운영 환경에서 권장됩니다.
• GitLab Self-Managed 인스턴스의 경우, GitLab 관리자는 이들을 비활성화할 수 있습니다.

일부 데이터 유형의 복제 활성화/비활성화

일부 데이터 유형에 대한 복제를 위한 피처 플래그가 기본적으로 사용 중인 피처 플래그 뒤에 배포되었습니다. GitLab Rails 콘솔에 액세스할 수 있는 GitLab 관리자는 인스턴스에 대해 이를 비활성화할 수 있습니다. 이러한 데이터 유형의 피처 플래그 이름은 아래 표의 참고 열에 있습니다.

예를 들어 패키지 파일 복제를 비활성화하는 경우:

Feature.disable(:geo_package_file_replication)

예를 들어 패키지 파일 복제를 활성화하는 경우:

Feature.enable(:geo_package_file_replication)