지원되는 Geo 데이터 유형
Tier: Premium, Ultimate
Offering: GitLab Self-Managed
Offering: GitLab Self-Managed
요약
Geo 데이터 유형은 하나 이상의 GitLab 기능에서 관련 정보를 저장하는 데 필요한 특정 데이터 클래스입니다. Geo를 사용하여 이러한 기능에서 생성된 데이터를 복제하기 위해 여러 전략을 사용하여 데이터에 접근, 전송 및 확인합니다.
Geo 데이터 유형은 하나 이상의 GitLab 기능에서 관련 정보를 저장하는 데 필요한 특정 데이터 클래스입니다.
Geo를 사용하여 이러한 기능에서 생성된 데이터를 복제하기 위해 여러 전략을 사용하여 데이터에 접근, 전송 및 확인합니다.
데이터 유형#
다음과 같은 다양한 데이터 유형을 구별합니다:
복제하는 각 기능 또는 컴포넌트, 해당 데이터 유형, 복제 및 확인 방법 목록을 참조하세요:
| 유형 | 기능 / 컴포넌트 | 복제 방법 | 확인 방법 |
|---|---|---|---|
| Database | PostgreSQL의 애플리케이션 데이터 | Native | Native |
| Database | Redis | 해당 없음 1 | 해당 없음 |
| Database | 고급 검색 (Elasticsearch 또는 OpenSearch) | Native | Native |
| Database | 정확한 코드 검색 (Zoekt) | Native | Native |
| Database | SSH 공개 키 | PostgreSQL Replication | PostgreSQL Replication |
| Git | 프로젝트 리포지터리 | Geo with Gitaly | Gitaly Checksum |
| Git | 프로젝트 위키 리포지터리 | Geo with Gitaly | Gitaly Checksum |
| Git | 프로젝트 디자인 리포지터리 | Geo with Gitaly | Gitaly Checksum |
| Git | 프로젝트 스니펫 | Geo with Gitaly | Gitaly Checksum |
| Git | 개인 스니펫 | Geo with Gitaly | Gitaly Checksum |
| Git | 그룹 위키 리포지터리 | Geo with Gitaly | Gitaly Checksum |
| Blob | 사용자 업로드 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | 사용자 업로드 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | LFS 오브젝트 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | LFS 오브젝트 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | CI 잡 아티팩트 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | CI 잡 아티팩트 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 보관된 CI 빌드 추적 (파일 시스템) | Geo with API | 구현 안됨 |
| Blob | 보관된 CI 빌드 추적 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 컨테이너 레지스트리 (파일 시스템) | Geo with API/Docker API | SHA256 checksum |
| Blob | 컨테이너 레지스트리 (오브젝트 스토리지) | Geo with API/Managed/Docker API 2 | SHA256 checksum 3 |
| Blob | 패키지 레지스트리 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | 패키지 레지스트리 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | Packages Helm Metadata Cache (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | Packages Helm Metadata Cache (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | Terraform Module Registry (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | Terraform Module Registry (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 버전화된 Terraform 상태 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | 버전화된 Terraform 상태 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 외부 머지 리퀘스트 diff (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | 외부 머지 리퀘스트 diff (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 파이프라인 아티팩트 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | 파이프라인 아티팩트 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | Pages (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | Pages (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | CI 보안 파일 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | CI 보안 파일 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 인시던트 메트릭 이미지 (파일 시스템) | Geo with API/Managed | SHA256 checksum |
| Blob | 인시던트 메트릭 이미지 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | 알림 메트릭 이미지 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | 알림 메트릭 이미지 (오브젝트 스토리지) | Geo with API/Managed 2 | SHA256 checksum 3 |
| Blob | Dependency Proxy 이미지 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | Dependency Proxy 이미지 (오브젝트 스토리지) | Geo with API/managed 2 | SHA256 checksum 3 |
| Blob | Packages nuget 심볼 (파일 시스템) | Geo with API | SHA256 checksum |
| Blob | Packages nuget 심볼 (오브젝트 스토리지) | Geo with API/Docker API | SHA256 checksum 3 |
| Container Repository | 컨테이너 레지스트리 (파일 시스템) | Geo with API/Docker API | SHA256 checksum |
| Container Repository | 컨테이너 레지스트리 (오브젝트 스토리지) | Geo with API/Managed/Docker API 2 | SHA256 checksum 3 |
각주:
- Redis 복제는 Redis 센티넬을 사용하는 HA의 일부로 사용할 수 있습니다. Geo 사이트 간에는 사용되지 않습니다.
- 오브젝트 스토리지 복제는 Geo 또는 오브젝트 스토리지 공급자/어플라이언스 네이티브 복제 기능에 의해 수행될 수 있습니다.
- 오브젝트 스토리지 확인은 피처 플래그
geo_object_storage_verification뒤에 있으며 16.4에서 도입되어 기본적으로 활성화됩니다. 파일 크기의 체크섬을 사용하여 파일을 확인합니다.
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를 캐시 저장소와 백그라운드 잡 시스템을 위한 영구 데이터 보관에 모두 사용합니다. 두 사용 사례 모두 동일한 Geo 사이트에 독점적인 데이터가 있으므로 사이트 간에 복제하지 않습니다.
Elasticsearch는 고급 검색을 위한 선택적 데이터베이스입니다. 소스 코드 수준과 이슈, 머지 리퀘스트 및 토론의 사용자 생성 콘텐츠 모두에서 검색을 향상시킬 수 있습니다. Elasticsearch는 Geo에서 지원되지 않습니다.
복제된 데이터 유형#
피처 플래그 뒤의 복제된 데이터 유형#
히스토리
- 기본적으로 활성화된 피처 플래그 뒤에 배포됩니다.
- GitLab.com에서 활성화됩니다.
- 프로젝트별로 활성화하거나 비활성화할 수 없습니다.
- 프로덕션 사용에 권장됩니다.
- GitLab Self-Managed 인스턴스의 경우 GitLab 관리자는 비활성화를 선택할 수 있습니다.
Feature flag
이 기능의 가용성은 피처 플래그로 제어됩니다. 자세한 내용은 기록을 참조하세요.
복제 활성화 또는 비활성화 (일부 데이터 유형의 경우)#
일부 데이터 유형의 복제는 기본적으로 활성화된 피처 플래그 뒤에 릴리스됩니다. GitLab Rails 콘솔에 접근할 수 있는 GitLab 관리자는 인스턴스에 대해 비활성화하도록 선택할 수 있습니다. 아래 표의 비고 열에서 각 데이터 유형의 피처 플래그 이름을 찾을 수 있습니다.
예를 들어 패키지 파일 복제를 비활성화하려면:
Feature.disable(:geo_package_file_replication)
예를 들어 패키지 파일 복제를 활성화하려면:
Feature.enable(:geo_package_file_replication)
Warning
이 목록에 없거나 복제됨 열에 No가 있는 기능은 보조 사이트에 복제되지 않습니다. 해당 기능의 데이터를 수동으로 복제하지 않고 페일오버하면 데이터가 손실됩니다. 보조 사이트에서 해당 기능을 사용하거나 페일오버를 성공적으로 실행하려면 다른 방법으로 해당 데이터를 복제해야 합니다.
| 기능 | 복제됨 (GitLab 버전에 추가됨) | 확인됨 (GitLab 버전에 추가됨) | GitLab 관리 오브젝트 스토리지 복제 (GitLab 버전에 추가됨) | GitLab 관리 오브젝트 스토리지 확인 (GitLab 버전에 추가됨) | 비고 |
|---|---|---|---|---|---|
| PostgreSQL의 애플리케이션 데이터 | Yes (10.2) | Yes (10.2) | 해당 없음 | 해당 없음 | |
| 프로젝트 리포지터리 | Yes (10.2) | Yes (10.7) | 해당 없음 | 해당 없음 | 16.2에서 셀프 서비스 프레임워크로 마이그레이션됨. 자세한 내용은 GitLab 이슈 #367925를 참조하세요. 피처 플래그 geo_project_repository_replication 뒤에 있으며 (16.3)에서 기본적으로 활성화됩니다.보관된 프로젝트를 포함한 모든 프로젝트가 복제됩니다. |
| 프로젝트 위키 리포지터리 | Yes (10.2)2 | Yes (10.7)2 | 해당 없음 | 해당 없음 | 15.11에서 셀프 서비스 프레임워크로 마이그레이션됨. 자세한 내용은 GitLab 이슈 #367925를 참조하세요. 피처 플래그 geo_project_wiki_repository_replication 뒤에 있으며 (15.11)에서 기본적으로 활성화됩니다. |
| 그룹 위키 리포지터리 | Yes (13.10) | Yes (16.3) | 해당 없음 | 해당 없음 | 피처 플래그 geo_group_wiki_repository_replication 뒤에 있으며 기본적으로 활성화됩니다. |
| 사용자 업로드 | Yes (10.2) | Yes (14.6) | Yes (15.1) | Yes (16.4)3 | 복제는 피처 플래그 geo_upload_replication 뒤에 있으며 기본적으로 활성화됩니다. 확인은 피처 플래그 geo_upload_verification 뒤에 있었으며 14.8에서 제거됩니다. |
| LFS 오브젝트 | Yes (10.2) | Yes (14.6) | Yes (15.1) | Yes (16.4)3 | GitLab 버전 11.11.x 및 12.0.x는 새 LFS 오브젝트가 복제되지 않는 버그의 영향을 받습니다. 복제는 피처 플래그 geo_lfs_object_replication 뒤에 있으며 기본적으로 활성화됩니다. 확인은 피처 플래그 geo_lfs_object_verification 뒤에 있었으며 14.7에서 제거됩니다. |
| 개인 스니펫 | Yes (10.2) | Yes (10.2) | 해당 없음 | 해당 없음 | |
| 프로젝트 스니펫 | Yes (10.2) | Yes (10.2) | 해당 없음 | 해당 없음 | |
| CI 잡 아티팩트 | Yes (10.4) | Yes (14.10) | Yes (15.1) | Yes (16.4)3 | 확인은 피처 플래그 geo_job_artifact_replication 뒤에 있으며 14.10에서 기본적으로 활성화됩니다. |
| 파이프라인 아티팩트 | Yes (13.11) | Yes (13.11) | Yes (15.1) | Yes (16.4)3 | 파이프라인 완료 후 추가 아티팩트를 유지합니다. |
| CI 보안 파일 | Yes (15.3) | Yes (15.3) | Yes (15.3) | Yes (16.4)3 | 확인은 피처 플래그 geo_ci_secure_file_replication 뒤에 있으며 15.3에서 기본적으로 활성화됩니다. |
| 컨테이너 레지스트리 | Yes (12.3)1 | Yes (15.10) | Yes (12.3)1 | Yes (15.10) | 컨테이너 레지스트리 복제를 설정하려면 지침을 참조하세요. |
| Terraform Module Registry | Yes (14.0) | Yes (14.0) | Yes (15.1) | Yes (16.4)3 | 피처 플래그 geo_package_file_replication 뒤에 있으며 기본적으로 활성화됩니다. |
| 프로젝트 디자인 리포지터리 | Yes (12.7) | Yes (16.1) | Yes (16.4)3 | Yes (16.4)3 | 디자인에는 LFS 오브젝트 및 업로드 복제도 필요합니다. |
| 패키지 레지스트리 | Yes (13.2) | Yes (13.10) | Yes (15.1) | Yes (16.4)3 | 피처 플래그 geo_package_file_replication 뒤에 있으며 기본적으로 활성화됩니다. |
| Packages Helm Metadata Cache | Yes (18.10) | Yes (18.10) | Yes (18.10) | Yes (18.10) | 피처 플래그 geo_packages_helm_metadata_cache_replication 뒤에 있으며 18.10에서 기본적으로 활성화됩니다. |
| 버전화된 Terraform 상태 | Yes (13.5) | Yes (13.12) | Yes (15.1) | Yes (16.4)3 | 복제는 피처 플래그 geo_terraform_state_version_replication 뒤에 있으며 기본적으로 활성화됩니다. 확인은 피처 플래그 geo_terraform_state_version_verification 뒤에 있었으며 14.0에서 제거됩니다. |
| 외부 머지 리퀘스트 diff | Yes (13.5) | Yes (14.6) | Yes (15.1) | Yes (16.4)3 | 복제는 피처 플래그 geo_merge_request_diff_replication 뒤에 있으며 기본적으로 활성화됩니다. 확인은 피처 플래그 geo_merge_request_diff_verification 뒤에 있었으며 14.7에서 제거됩니다. |
| 버전화된 스니펫 | Yes (13.7) | Yes (14.2) | Yes (16.4)3 | Yes (16.4)3 | 확인은 13.11에서 피처 플래그 geo_snippet_repository_verification 뒤에 구현되었으며 피처 플래그는 14.2에서 제거됩니다. |
| Pages | Yes (14.3) | Yes (14.6) | Yes (15.1) | Yes (16.4)3 | 피처 플래그 geo_pages_deployment_replication 뒤에 있으며 기본적으로 활성화됩니다. 확인은 피처 플래그 geo_pages_deployment_verification 뒤에 있었으며 14.7에서 제거됩니다. |
| 프로젝트 수준 CI 보안 파일 | Yes (15.3) | Yes (15.3) | Yes (15.3) | Yes (16.4)3 | |
| 인시던트 메트릭 이미지 | Yes (15.5) | Yes (15.5) | Yes (15.5) | Yes (16.4)3 | 복제/확인은 업로드 데이터 유형을 통해 처리됩니다. |
| 알림 메트릭 이미지 | Yes (15.5) | Yes (15.5) | Yes (15.5) | Yes (16.4)3 | 복제/확인은 업로드 데이터 유형을 통해 처리됩니다. |
| 서버 측 Git 훅 | 계획 없음 | No | 해당 없음 | 해당 없음 | 현재 구현 복잡성, 낮은 고객 관심 및 훅 대안의 가용성으로 인해 계획이 없습니다. |
| Elasticsearch | 계획 없음 | No | No | No | 추가 제품 발견이 필요하고 Elasticsearch(ES) 클러스터를 재구축할 수 있으므로 계획이 없습니다. 보조는 기본과 동일한 ES 클러스터를 사용합니다. |
| Dependency Proxy 이미지 | Yes (15.7) | Yes (15.7) | Yes (15.7) | Yes (16.4)3 | |
| Packages NuGet Symbol | Yes (18.10) | Yes (18.10) | Yes (15.7) | Yes (16.4)3 | 피처 플래그 geo_packages_nuget_symbol_replication 뒤에 있으며 기본적으로 활성화됩니다. |
| 취약점 내보내기 | 계획 없음 | No | No | No | 임시적이고 민감한 정보이므로 계획이 없습니다. 요청 시 다시 생성할 수 있습니다. |
| Packages NPM 메타데이터 캐시 | 계획 없음 | No | No | No | 보조 사이트에서 재해 복구 기능이나 응답 시간을 눈에 띄게 향상시키지 않으므로 계획이 없습니다. |
| Packages Debian GroupComponentFile | 계획 없음 | No | No | No | |
| Packages Debian ProjectComponentFile | 계획 없음 | No | No | No | |
| Packages Debian GroupDistribution | 계획 없음 | No | No | No | |
| Packages Debian ProjectDistribution | 계획 없음 | No | No | No | |
| Packages RPM RepositoryFile | 계획 없음 | No | No | No | |
| VirtualRegistries Maven Cache Entry | 계획 없음 | No | No | No | |
| SBOM 취약점 스캔 데이터 | 계획 없음 | No | No | No | 데이터가 임시적이며 보조 사이트의 재해 복구 기능에 제한적인 영향으로 수명이 짧으므로 계획이 없습니다. |
각주:
- 15.5에서 셀프 서비스 프레임워크로 마이그레이션됨. 자세한 내용은 GitLab 이슈 #337436을 참조하세요.
- 15.11에서 셀프 서비스 프레임워크로 마이그레이션됨. 피처 플래그
geo_project_wiki_repository_replication뒤에 있으며 기본적으로 활성화됩니다. 자세한 내용은 GitLab 이슈 #367925를 참조하세요. - 오브젝트 스토리지에 저장된 파일의 확인이 GitLab 16.4에서
geo_object_storage_verification이라는 피처 플래그와 함께 도입되었으며 기본적으로 활성화됩니다.