• 1. 셀 이전 - 단일 아키텍처
• 2. 개발 셀 - 셀러 아키텍처에 맞게 응용 프로그램 조정
• 3. 초기 셀 배포 - 단일 아키텍처에서 셀 아키텍처로 변환
• 4. 하이브리드 셀 배포 - 초기 완전한 셀 아키텍처
• 5. 대상 셀 - 완전히 분리된 셀 아키텍처
  • 클러스터 전체 서비스
  • 셀 로컬 서비스
  • 하이브리드 서비스

이 설계안은 인프라 구성 설계안에 의해 앞지른 바가 있습니다.

Cells: 배포 아키텍처

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

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

이 다이어그램은 Cells 아키텍처를 도입하기 전의 단순화된 GitLab.com 배포 컴포넌트를 나타냅니다. 이 다이어그램은 아키텍처 개요에 관련이 없는 일부 서비스들을 의도적으로 생략했습니다(Cloudflare, Consul, PgBouncers, …). 이러한 서비스들은 셀 로컬로 간주되며(Cloudflare는 예외), 그 예외입니다.

컴포넌트 블록:

• 독립적으로 배포할 수 있는 별도의 컴포넌트들.
• 다른 컴포넌트와 독립적이며 다양한 버전 호환성을 제공합니다.

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

• 강하게 연결되어 있으며 동일한 버전의 응용 프로그램을 실행해야 합니다. !131657에서 자세히 알아보세요.
• 각 서비스는 여러 노드에 걸쳐 실행되어 처리량을 충분히 제공하기 위해 수평으로 확장됩니다.
• 다른 서비스와 상호 작용하기 위해 API(REST, gRPC), Redis 또는 DB를 사용하는 서비스.

의존 서비스:

• 자주 업데이트되고 선택적으로 사용됩니다.
• 클라우드 관리형 서비스를 사용할 수 있습니다.
• 각 서비스는 클러스터링되어 다양한 가용 영역에 걸쳐 실행될 수 있어 고가용성을 제공합니다.
• 객체 리포지터리는 사전 서명된 URL을 제공함으로써 사용자가 직접 액세스할 수도 있습니다.

2. 개발 셀 - 셀러 아키텍처에 맞게 응용 프로그램 조정

개발 셀의 목적은 변경 사항을 테스트하고 검증하기 위해 프로덕션과 유사한 아키텍처를 모델링하는 것입니다. 이는 참조 아키텍처 위에 테스트 셀을 구성함으로써 달성될 수 있습니다. #425197에서 자세히 알아보세요.

셀 이전과 비교했을 때의 차이점:

• 루팅 서비스는 셀에 의해 개발되었습니다.
• 개발 셀은 오직 개발 환경에서만 실행되어 셀 프로토타입을 수행할 수 있도록 합니다.
• 개발 셀은 필수적으로 분리되어야 하는 서비스에만 초점을 맞춘 단순화된 GitLab.com 아키텍처를 나타냅니다.
• 개발 셀은 프로덕션에서 사용할 목적으로 만들어진 것이 아닙니다.
• 클러스터 전체의 데이터 공유는 셀 1의 주 데이터베이스에 대한 읽기-쓰기 연결을 통해 이루어집니다: PostgreSQL 메인 데이터베이스 및 Redis 사용자 세션 데이터베이스.

3. 초기 셀 배포 - 단일 아키텍처에서 셀 아키텍처로 변환

개발 셀과 비교했을 때의 차이점:

• 셀에 의해 클러스터 전체 데이터 제공자가 도입되었습니다.
• 클러스터 전체 데이터 제공자는 셀 1과 함께 배포되어 직접 클러스터 전체 데이터에 액세스할 수 있게 됩니다.
• 클러스터 전체 데이터베이스는 주 PostgreSQL 데이터베이스와 격리됩니다.
• 클러스터 전체 데이터 제공자는 사용자 데이터, 사용자 세션(현재 Redis 세션 클러스터에 저장), 라우팅 정보, 그리고 모든 셀에 걸쳐 클러스터 전체 설정을 저장하고 공유하는 책임을 집니다.
• 클러스터 전체 데이터베이스 액세스는 비동기적으로 이루어집니다:
  • 읽기 액세스는 항상 데이터베이스 복제본을 사용합니다.
  • 데이터베이스 복제본은 셀과 함께 배포될 수 있습니다.
  • 쓰기 액세스는 전용 클러스터 전체 데이터 제공자 서비스를 사용합니다.
• 추가 셀은 GitLab Dedicated과 유사한 제어 평면을 통해 배포, 업그레이드, 유지됩니다.
• 각 셀은 가능한 한 많은 서비스를 독립적으로 실행하도록 목표를 합니다.
• 셀은 자체 Gitaly 클러스터를 실행하거나 공유 Gitaly 클러스터를 사용하거나 그 둘 다 사용할 수 있습니다. !131657에서 자세히 알아보세요.
• GitLab이 제공하는 공유 러너는 셀에서 지역적으로 실행될 것으로 예상됩니다.
• 인프라 컴포넌트는 클러스터 전체에 공유될 수 있으며 다른 셀에서 사용될 수 있습니다.
• Elasticsearch 서비스를 클러스터 전체로 실행하는 것이 더 나은지 Cell 로컬로 실행하는 것이 더 나은지에 대한 결정은 아직 정의되지 않았습니다.
• GitLab Pages - gitlab.io 컴포넌트의 확장 방법을 결정 지연합니다.
• Registry - registry.gitlab.com 컴포넌트의 확장 방법을 결정 지연합니다.

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

초기 Cells 배포와 비교했을 때의 차이점:

• 셀 N과 셀 1 사이의 결합이 제거되었습니다.
• 클러스터 전체 데이터 제공자가 셀 1에서 격리되었습니다.
• 클러스터 전체 데이터베이스(PostgreSQL, Redis)가 클러스터 전체 데이터 제공자와 함께 실행될 수 있도록 이동되었습니다.
• 클러스터 전체 데이터에 대한 모든 응용 프로그램 데이터 액세스 경로는 클러스터 전체 데이터 제공자를 사용합니다.
• 일부 서비스들은 여러 셀에 걸쳐 공유됩니다.

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

하이브리드 셀 배포와 비교했을 때의 차이점:

• 루팅 서비스는 GitLab Pages와 GitLab 컨테이너 레지스트리를 지원하기 위해 확장되었습니다.
• 각 셀에는 모든 서비스가 분리되어 있습니다.
• 일부 셀이 하이브리드 아키텍처를 따르는 것을 허용합니다.

서비스의 분리

각 서비스는 요구 사항, 서비스 확장과 관련된 위험, 위치(클러스터 전체 또는 셀 로컬) 및 셀 간 데이터 이주 능력에 대해 개별적으로 고려될 수 있습니다.

클러스터 전체 서비스

아키텍처에 따르면 위 서비스들은 클러스터 전체로 실행되어야 합니다:

• 이러한 서비스는 Cells 아키텍처에서 도입된 추가 서비스입니다.

셀 로컬 서비스

아키텍처에 따르면 위 서비스들은 셀 로컬로 실행되어야 합니다:

• 셀 로컬 서비스에 의해 보유된 소비자 데이터는 다른 셀로 이주될 수 있어야 합니다.
• 서비스에 의해 생성된 컴퓨트가 상당히 크며, 단일 셀 장애에 대한 높은 내구성의 영향을 줄이는 것이 강력하게 원하는 바입니다.
• Cells 아키텍처 관점에서 클러스터 전체로 서비스를 실행하는 것이 복잡합니다.

하이브리드 서비스

아키텍처에 따르면 위 서비스들은 클러스터 전체 또는 셀 로컬로 실행되어야 합니다:

• 하이브리드 서비스가 클러스터 전체로 실행될 수 있는 능력은 몇몇 서비스가 공유되기 때문에 셀 간 데이터 마이그레이션에 필요한 작업량을 줄일 수 있습니다.
• 클러스터 전체로 실행되는 하이브리드 서비스는 단일 셀 장애에 대한 내구성 증가로 인해 셀 가용성과 내구성에 부정적인 영향을 미칠 수 있습니다.

위와 같은 서비스들은 클러스터 전체 또는 셀 로컬로 실행될 수 있는 것으로 허용됩니다:

• 위 서비스를 클러스터 전체로 실행시키는 능력은 몇몇 서비스가 공유되기 때문에 셀 간 데이터 마이그레이션에 필요한 작업량을 줄일 수 있습니다.
• 클러스터 전체로 실행되는 하이브리드 서비스는 단일 셀 장애에 대한 내구성 증가로 인해 셀 가용성과 내구성에 부정적인 영향을 미칠 수 있습니다.