Geo 데이터 유형은 하나 이상의 GitLab 기능이 관련 정보를 저장하는 데 필요로 하는 특정 데이터 부류입니다.

Geo로 이러한 기능이 생성한 데이터를 복제하기 위해, 데이터에 접근하고 전송하고 확인하는 여러 전략을 사용합니다.

데이터 유형#

다음 데이터 유형을 구분합니다.

• Git 리포지터리
• 컨테이너 리포지터리
• 블롭
• 데이터베이스

복제 대상인 각 기능 또는 컴포넌트와 그에 해당하는 데이터 유형, 복제 방법, 확인 방법은 아래 목록을 참고합니다.

각주:

1. Redis 복제는 Redis 센티널을 사용하는 HA 구성의 일부로 쓸 수 있습니다. Geo 사이트 간에는 사용하지 않습니다.
2. 오브젝트 스토리지 복제는 Geo가 수행하거나, 오브젝트 스토리지 공급자·어플라이언스의 네이티브 복제 기능이 수행할 수 있습니다.
3. 오브젝트 스토리지 확인은 GitLab 16.4에서 geo_object_storage_verification이라는 기능 플래그와 함께 도입되었습니다. 기본값으로 활성화되어 있습니다.

Git 리포지터리#

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

• 디스크가 하나인 머신
• RAID 어레이처럼 여러 디스크를 단일 마운트 포인트로 마운트한 머신
• LVM을 사용하는 머신

GitLab은 특별한 파일 시스템을 요구하지 않으며 마운트된 스토리지 어플라이언스에서도 동작합니다. 다만 원격 파일 시스템을 사용하면 성능 제약과 일관성 문제가 생길 수 있습니다.

Geo는 Geo 보조 사이트에서 포크된 리포지터리를 중복 제거하도록 Gitaly에서 가비지 컬렉션을 트리거합니다.

통신은 Gitaly gRPC API가 담당하며, 동기화 방식은 다음 세 가지입니다.

• 한 Geo 사이트에서 다른 사이트로 일반 Git clone/fetch를 사용합니다(별도 인증 포함).
• 리포지터리 스냅샷을 사용합니다(첫 번째 방식이 실패하거나 리포지터리가 손상된 경우).
• Admin 영역에서 수동으로 트리거합니다(나열된 다른 방식을 조합합니다).

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

• 소스 코드를 저장하는 프로젝트 리포지터리
• 위키 콘텐츠를 저장하는 위키 리포지터리
• 디자인 아티팩트를 인덱싱하는 디자인 리포지터리(자산은 실제로 LFS에 있습니다)

세 리포지터리는 모두 같은 샤드에 있고 같은 기본 이름을 공유하며, 위키와 디자인 리포지터리에는 각각 -wiki와 -design 접미사가 붙습니다.

그 밖에 스니펫 리포지터리가 있습니다. 스니펫 리포지터리는 프로젝트나 특정 사용자에 연결할 수 있습니다. 두 유형 모두 보조 사이트로 동기화됩니다.

컨테이너 리포지터리#

컨테이너 리포지터리는 컨테이너 레지스트리에 저장됩니다. 컨테이너 리포지터리는 컨테이너 레지스트리를 데이터 저장소로 삼아 구축한 GitLab 고유 개념입니다.

블롭#

GitLab은 이슈 첨부 파일이나 LFS 오브젝트 같은 파일과 블롭을 다음 중 한 곳에 저장합니다.

• 특정 위치의 파일 시스템
• 오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음과 같습니다.
  • Amazon S3나 Google Cloud Storage 같은 클라우드 기반 스토리지
  • 자체 호스팅 S3 호환 오브젝트 스토리지
  • 오브젝트 스토리지 호환 API를 노출하는 스토리지 어플라이언스

오브젝트 스토리지 대신 파일 시스템 저장소를 사용하고 노드를 둘 이상 사용한다면, 네트워크 마운트 파일 시스템으로 GitLab을 실행합니다.

복제와 확인 측면에서는 다음과 같습니다.

• 파일과 블롭은 내부 API 요청으로 전송합니다.
• 오브젝트 스토리지에서는 다음 중 하나를 선택할 수 있습니다.
  • 클라우드 공급자의 복제 기능을 사용합니다.
  • GitLab이 대신 복제하도록 합니다.

데이터베이스#

GitLab은 사용 사례별로 여러 데이터베이스에 저장된 데이터에 의존합니다. PostgreSQL은 이슈 콘텐츠와 댓글은 물론 권한과 자격 증명까지, 웹 인터페이스에서 생성되는 사용자 콘텐츠의 단일 진실 공급원입니다.

PostgreSQL은 HTML로 렌더링한 Markdown이나 캐시된 머지 리퀘스트 diff 같은 캐시 데이터도 일부 보관할 수 있습니다. 이 데이터는 오브젝트 스토리지로 오프로드하도록 구성할 수도 있습니다.

기본 사이트에서 보조 사이트로 데이터를 복제할 때는 PostgreSQL 자체 복제 기능을 사용합니다.

Redis는 캐시 저장소로도, 백그라운드 job 시스템의 영속 데이터 보관용으로도 사용합니다. 두 사용 사례 모두 같은 Geo 사이트에만 해당하는 데이터를 다루므로 사이트 간에 복제하지 않습니다.

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

복제되는 데이터 유형#

기능 플래그 뒤의 복제되는 데이터 유형#

히스토리

• 기본값으로 활성화된 기능 플래그 뒤에 배포됩니다.
• GitLab.com에서 활성화되어 있습니다.
• 프로젝트별로 활성화하거나 비활성화할 수 없습니다.
• 프로덕션 사용을 권장합니다.
• GitLab Self-Managed 인스턴스에서는 GitLab 관리자가 비활성화를 선택할 수 있습니다.

복제 활성화 또는 비활성화(일부 데이터 유형)#

일부 데이터 유형의 복제는 기본값으로 활성화된 기능 플래그 뒤에서 릴리스됩니다. GitLab Rails 콘솔에 접근할 수 있는 GitLab 관리자는 인스턴스에서 이를 비활성화할 수 있습니다. 각 데이터 유형의 기능 플래그 이름은 아래 표의 비고 칼럼에서 확인할 수 있습니다.

패키지 파일 복제를 예로 들면, 비활성화는 다음과 같습니다.

Feature.disable(:geo_package_file_replication)

패키지 파일 복제를 예로 들면, 활성화는 다음과 같습니다.

Feature.enable(:geo_package_file_replication)

geo_<replicable>_replication 플래그를 비활성화하면 보조 사이트의 복제와 확인이 중단됩니다. 기본 사이트에서는 그에 대응하는 geo_<replicable>_force_primary_checksumming 플래그가 활성화되어 있는 동안(기본값) 체크섬 계산이 계속됩니다. 기본 사이트의 체크섬 계산도 중단하려면 두 플래그를 모두 비활성화합니다.

Feature.disable(:geo_package_file_replication)
Feature.disable(:geo_package_file_force_primary_checksumming)

각주:

1. 15.5에서 셀프 서비스 프레임워크로 이전되었습니다. 자세한 내용은 GitLab 이슈 #337436을 참고합니다.
2. 15.11에서 셀프 서비스 프레임워크로 이전되었습니다. 기능 플래그 geo_project_wiki_repository_replication 뒤에 있으며 기본값으로 활성화되어 있습니다. 자세한 내용은 GitLab 이슈 #367925를 참고합니다.
3. 오브젝트 스토리지 확인은 GitLab 16.4에서 geo_object_storage_verification이라는 기능 플래그와 함께 도입되었습니다. 기본값으로 활성화되어 있습니다.