This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
rejected -

이 청사진은 인프라 청사진에 의해 뛰어넘어졌습니다.

셀: 배포 아키텍처

이 섹션에서는 GitLab.com의 현존하는 배포 아키텍처를 설명하고 기대되는 Cells 아키텍처와 비교합니다.

1. 셀 이전 - 단일체 아키텍처

이 다이어그램은 Cells 아키텍처가 도입되기 전의 간소화된 GitLab.com 배포 구성 요소를 나타냅니다. 이 다이어그램은 아키텍처 개요에 관련이 없는 일부 서비스(Cloudflare, Consul, PgBouncers 등)를 고의로 생략했습니다. 이러한 서비스는 셀 내에서만 사용되며(Cloudflare를 제외하고) 셀간 연결이 유지됩니다.

구성 요소 블록은 다음과 같습니다:

  • 독립적으로 배포할 수 있는 개별 구성 요소
  • 다른 구성 요소와 독립적이며 다양한 버전 호환성을 제공하는 구성 요소

응용 프로그램 레이어 서비스:

  • 강하게 연결되어 있으며 응용 프로그램의 동일한 버전을 실행해야 함 자세한 내용은 !131657을 참조하십시오.
  • 각 서비스는 많은 노드에서 실행되어 수평으로 확장되어 충분한 처리량을 제공합니다.
  • API(REST, gRPC), Redis 또는 DB를 사용하여 다른 서비스와 상호 작용하는 서비스

의존하는 서비스:

  • 드물고 선택적으로 업데이트됩니다.
  • 클라우드 관리 서비스를 사용할 수 있음
  • 각 서비스는 클러스터링되어 고가용성을 제공하기 위해 다양한 가용 영역에서 실행될 수 있습니다.
  • 사전 서명된 URL이 제공되면 객체 저장소를 사용자가 직접 액세스할 수 있습니다.

2. 개발 Cells - 셀룰러 아키텍처에 맞는 응용 프로그램의 적응

개발 Cells의 목적은 도입된 변경 사항을 테스트하고 검증하기 위해 제품과 유사한 아키텍처를 모델링하는 것입니다. 이를 위해 참조 아키텍처 위에 테스트 Cells를 사용하여 이를 달성할 수 있습니다. 자세한 내용은 #425197을 참조하십시오.

셀 이전과 비교한 차이점은 다음과 같습니다:

  • 라우팅 서비스는 Cells에 의해 개발되었습니다.
  • 개발 Cells는 프로토타입을 만들고 모든 보조 서비스를 관리하는 과부하 없이 개발 환경에서만 실행할 수 있도록합니다.
  • 개발 Cells는 필수적으로 분리되어야 하는 서비스에만 초점을 맞추어 간소화된 GitLab.com 아키텍처를 나타냅니다.
  • 개발 Cells는 제품에서 사용되지 않아야 합니다.
  • 클러스터 전체 데이터 공유는 Cell 1의 주요 데이터베이스인 PostgreSQL 주 데이터베이스 및 Redis 사용자 세션 데이터베이스에 대한 읽기-쓰기 연결을 통해 이루어집니다.

3. 초기 Cells 배포 - 단일체 아키텍처를 Cells 아키텍처로 변환

개발 Cells와 비교한 차이점은 다음과 같습니다:

  • 클러스터 전체 데이터 제공자가 Cells에 의해 도입되었습니다.
  • 클러스터 전체 데이터 제공자는 클러스터 전체 데이터에 직접 액세스할 수 있도록 Cell 1과 함께 배포됩니다.
  • 클러스터 전체 데이터베이스는 주 PostgreSQL 데이터베이스와 격리되어 있습니다.
  • 클러스터 전체 데이터 제공자는 사용자 데이터, 사용자 세션(Redis 세션 클러스터에 현재 저장됨), 라우팅 정보 및 클러스터 전체 설정을 저장하고 공유하는 역할을 합니다.
  • 클러스터 전체 데이터베이스에 대한 액세스는 비동기적으로 이루어집니다:
    • 읽기 액세스는 항상 데이터베이스 복제본을 사용합니다.
    • 데이터베이스 복제본은 Cell과 함께 배포될 수 있습니다.
    • 쓰기 액세스는 전용 클러스터 전체 데이터 제공자 서비스를 사용합니다.
  • 추가 Cells는 GitLab Dedicated와 유사한 제어 플레인을 통해 배포, 업그레이드 및 유지보수될 수 있습니다.
  • 각 Cell은 가능한 한 많은 서비스를 분리하여 실행해야 합니다.
  • Cell은 자체 Gitaly 클러스터를 실행하거나 공유 Gitaly 클러스터를 사용하거나 둘 다를 사용할 수 있습니다. 자세한 내용은 !131657을 참조하십시오.
  • GitLab에서 제공하는 공유 실행자는 Cell에서 지역적으로 실행될 것으로 예상됩니다.
  • 인프라 구성 요소는 클러스터 전체에서 공유되어 다른 Cells에서 사용될 수 있습니다.
  • Elasticsearch 서비스가 클러스터 전체에서 실행하는 것이 더 나은지 또는 Cell 내에서 실행하는 것이 더 나은지에 대한 결정은 되지 않았습니다.
  • GitLab Pages - gitlab.io 구성요소를 어떻게 확장할 지에 대한 결정을 유예합니다.
  • 레지스트리 - registry.gitlab.com 구성요소를 어떻게 확장할 지에 대한 결정을 유예합니다.

4. 하이브리드 Cells 배포 - 초기 완전한 Cells 아키텍처

초기 Cells 배포와 비교한 차이점은 다음과 같습니다:

  • Cell N을 Cell 1에 연결을 제거합니다.
  • 클러스터 전체 데이터 제공자가 Cell 1에서 격리됩니다.
  • 클러스터 전체 데이터베이스(포스트그리SQL, Redis)가 클러스터 전체 데이터 제공자와 함께 실행되도록 이동되었습니다.
  • 클러스터 전체 데이터에 대한 모든 응용 프로그램 데이터 액세스 경로는 클러스터 전체 데이터 제공자를 사용합니다.
  • 일부 서비스는 여러 Cells간에 공유됩니다.

5. 대상 셀 - 완전 분리된 셀 아키텍처

deployment-target-cells

하이브리드 셀 배포와 비교한 차이점은 다음과 같습니다.

서비스 격리

각 서비스는 요구 사항, 서비스 확장에 따른 리스크, 위치(클러스터 전역 또는 셀 내부), 셀 간 데이터 이관 능력 등을 고려하여 개별적으로 고려할 수 있습니다.

클러스터 전역 서비스

서비스 유형 사용 설명
라우팅 서비스 GitLab-built 클러스터 전역 데이터 제공자 모든 GitLab SaaS 도메인의 요청을 셀로 리디렉션할 수 있는 일반적인 목적의 라우팅 서비스
클러스터 전역 데이터 제공자 GitLab-built PostgreSQL, Redis, 이벤트 큐 모든 클러스터화된 서비스에 사용자 프로필 및 라우팅 정보를 제공합니다

아키텍처에 따라 위의 서비스는 클러스터 전역에서 실행되어야 합니다.

  • 이러한 서비스는 셀 아키텍처에서 추가로 도입되는 추가적인 서비스입니다.

셀 내부 서비스

서비스 유형 사용 클러스터 전역에서 셀로 이관 설명
Redis 클러스터 관리형 서비스 디스크 저장소 문제 없음 Redis는 사용자 세션, 애플리케이션 캐시 또는 Sidekiq 큐를 보관하는 데 사용됩니다. 대부분의 데이터는 셀에만 적용됩니다.
GitLab 러너 관리자 관리형 서비스 API, Google Cloud VM 인스턴스 사용 문제 없음 API 및 CI 작업 실행에 중대한 변경이 필요합니다.

아키텍처에 따라 위의 서비스는 셀 내부에서 실행되어야 합니다.

  • 셀 내부 서비스가 소비하는 데이터는 다른 셀로 이관 가능해야 합니다.
  • 서비스로 생성된 계산이 상당하며, 단일 셀 장애에 대한 고도의 내구성의 영향을 줄이는 것이 강력하게 원합니다.
  • 셀 아키텍처에서 이 서비스를 클러스터 전역으로 실행하는 것은 복잡합니다.