• 목표
  • 확장성
  • 증가된 가용성
  • 일관된 경험
  • 지역
  • 시장 세그먼트
  • Self-Managed형
• 요구 사항
  • 클러스터 전역 데이터 집계
  • 모든 Cells는 단일 GitLab.com 도메인 하에 위치
  • 사용자가 여러 Cells와 상호 작용 가능
  • 기여자 워크플로에 미미한 영향
  • 온프레미스와 유사한 경험
  • 기존 워크플로의 파괴를 최소화
  • 지역 지원 가능
  • 자기관리 고객에 대한 영향 최소화 (Omnibus/CNG)
  • 10배의 여유 공간 제공
  • 100배의 여유 공간 제공
  • 서비스 가용성 향상
  • 사용자 당 비용이 GitLab.com과 유사하거나 낮아야 함
  • Cells의 통합 배포 방법
  • 혼합 배포에서 실행되는 Cells
  • 단일 Cell 장애에 대한 높은 내구성
  • 작은 Cells
  • 강력한 롤백 및 재해 복구 시나리오
  • 기존의 GitLab.com 데이터베이스 확장
  • Cells의 가시화
  • 고객이 GitLab.com에서 Dedicated로 마이그레이션할 수 있음
  • 개발 환경에서 쉬운 사용
• 비목표
  • 서로 다른 GitLab 인스턴스 간의 연구
  • 클라우드 관리형 서비스의 사용
  • Cells는 카나리 배포를 대체해서는 안 됨
• 용어 해설
  • Cell
  • 클러스터
  • 조직
  • 최상위 그룹
  • 사용자

Cells: 목표

목표

확장성

새로운 공유 인프라 아키텍처의 주요 목표는 우리의 SaaS 플랫폼에 대한 추가적인 확장성을 제공하는 것입니다. GitLab.com은 대부분 모놀리식이며 현재의 아키텍처에는 확장성 제한이 있다고 내부적으로 추정했습니다. 특히 PostgreSQL 데이터베이스 및 Redis의 수평 확장이 불가능한 리소스가 있습니다. 데이터베이스 분할 및 분해를 고려해도 확장이 제한됩니다. Cells는 수평 확장 가능한 솔루션을 제공하여 수요에 따라 추가적인 Cells를 생성할 수 있습니다. Cells는 최적의 확장성을 위해 필요에 따라 프로비저닝되고 조정될 수 있습니다.

증가된 가용성

공유 인프라 아키텍처의 주요 도전 과제는 최상위 그룹 사이의 격리 부재입니다. 이러한 부재는 소음이 심한 이웃 효과로 이어질 수 있습니다. 최상위 그룹 내에서의 조직의 행동은 다른 모든 조직에 영향을 미칠 수 있습니다. 이는 매우 바람직하지 않습니다. Cells는 Cell 레벨에서 격리를 제공합니다. 여러 조직으로 구성된 그룹은 다른 Cell에 위치한 다른 조직에 완전히 격리됩니다. 이는 소음이 심한 이웃 효과를 최소화하고 공유 인프라의 비용 효율성을 여전히 누릴 수 있게 합니다.

또한, Cells는 재해 복구 기능을 구현하는 방법을 제공합니다. 전체 Cells는 자동 장애 조치 기능이 있는 읽기 전용 대기 모드로 복제될 수 있습니다.

일관된 경험

조직들은 Self-Managed형 GitLab 인스턴스와 동일한 사용자 경험을 가져야 합니다.

지역

GitLab.com은 미국 내에서만 호스팅됩니다. 다른 지역에 위치한 조직들은 현지 SaaS 제공에 대한 요구를 제시했습니다. Cells는 다른 지리적 위치에 배포할 수 있기 때문에 GitLab 지역에 대한 경로를 제공합니다. 조직의 데이터 중 어느 것이 Cell 외부에 위치하느냐에 따라 데이터 머무임 및 규정 준수 문제를 해결할 수 있습니다.

시장 세그먼트

현재 GitLab.com은 “소셜 네트워크”와 유사한 기능을 가지고 있는데, 이는 더 격리된 조직 모델과 잘 어울리지 않을 수 있습니다. 그러나 이러한 기능을 제거하는 것은 몇 가지 도전을 야기합니다:

1. 기존 gitlab-org 기여자들은 어떻게 네임스페이스에 기여할 것인가요?
2. 기존 최상위 그룹을 어떻게 새 모델로 이관할 것인가요 (사실상 그들의 소셜 기능을 망가뜨리지 않으려면)?

이러한 기능에 대한 관심이 있는지, 또는 이러한 기능이 없어도 대부분의 경우에는 수용 가능한지를 평가해야 합니다.

Self-Managed형

일관성 유지를 위해 예상되는 바는 Self-Managed형 인스턴스들도 단일 Cell 아키텍처를 채택할 것입니다. Self-Managed형 인스턴스는 경로 또는 토폴로지와 같은 추가적인 Cell 서비스 없이도 단일 Cell로 계속할 수 있을 것입니다. 조직 및 가능한 사용자 분해도 Self-Managed형 인스턴스에 채택될 것입니다.

요구 사항

클러스터 전역 데이터 집계

아키텍처는 Cells 클러스터를 단일 화면에서 표시할 수 있는 방법을 제공해야 합니다. 이는 다음을 의미할 수 있습니다:

• 다른 조직에서 사용자 To-Do 집계
• 클러스터 전역에서 공개 프로젝트나 게시된 소스 코드 검색 수행

모든 Cells는 단일 GitLab.com 도메인 하에 위치

일반 사용자들은 Cells의 존재를 인식해서는 안 됩니다. Cells는 인스턴스 관리자에게만 가시적입니다. 다른 Cell의 조직을 사용하는 사용자 또는 우리가 조직을 이동하는 경우는 사용자 개입을 필요로 하지 않거나 사용자에게 가시적이지 않아야 합니다.

사용자가 여러 Cells와 상호 작용 가능

여러 계정을 사용하여 서로 다른 Cells에 상호 작용하는 것은 강력히 권장되지 않습니다. 많은 계정을 사용하는 필요성은 공개 프로젝트에 기여하고자 하는 사용자들의 수용을 줄이고 사용자가 오픈소스 프로젝트에 기여하길 원하는 사용자들에게 장벽을 설정할 것입니다.

앞으로 사용자는 특정 고객 요구 사항에 따라 조직별 설정을 가질 수 있을 것입니다. 예를 들어, 사용자는 서로 다른 조직에서 서로 다른 표시 이름으로 표시될 수 있습니다.

사용자가 많은 SSH 키를 관리하기 어려워지지 않도록 사용자는 서로 다른 조직에 액세스하기 위해 서로 다른 SSH 키를 사용해야 하는 것이 아니어야 합니다.

기여자 워크플로에 미미한 영향

GitLab.com에는 오픈 소스 및 오픈 커어 프로젝트들이 많이 있습니다(gitlab-org/gitlab 포함). Cells는 공개 프로젝트에 기여하기 어렵게 만들어서는 안 됩니다. 새로운 기여 방법을 배우는 것은 Cells의 채택을 방해할 가능성이 큽니다. 소개된 아키텍처는 기존의 워크플로를 가능한 한 최소한의 방법으로 변경하는 데 초점을 둬야 합니다.

온프레미스와 유사한 경험

현재 온프레미스는 당사 SaaS 제공과 비교했을 때 다수의 장점을 갖고 있습니다. 온프레미스는 사용자, 액세스 제어, 또는 인스턴스 전체 설정을 포함하여 GitLab 설치의 모든 측면을 제어할 수 있는 환경을 제공합니다.

SaaS와 온프레미스 간의 차이는 고객에게 문제가 될 수 있는데, 이는 다른 사용자 경험을 초래할 수 있습니다.

기존 워크플로의 파괴를 최소화

Cells의 도입은 지원되는 GitLab.com 워크플로에 변경을 의미할 것입니다. Cells는 GitLab의 사용 방법에 어떤 영향을 미칠지도 모르지만, 그것이 사용자에게 흥미로운 사용자 경험을 제공한다면 가능한 줄이는 것이 바람직합니다.

어떤 Cells 아키텍처도 새로운 파괴적인 변경을 소개하지 않도록 초점을 맞춰야 하며, 그렇지 않으면 변경을 지원할 충분한 시간창을 제공해야 합니다. 파괴적인 변경을 소개하는 것은 채택률과 Cells의 효과성을 줄이고 아키텍처의 출시를 더 위험하게 만들 수 있습니다.

개별적인 breaking change의 심각성 간의 차이를 명확히 하는 것이 중요합니다:

• 필수: 새 아키텍처로의 마이그레이션은 의도적으로 파괴적인 변경을 도입할 수 있습니다. 이 경우에 고객은 새로운 워크플로, 새로운 API 또는 새로운 엔드포인트를 즉시 사용해야 하고, 한 번에 모든 변경에 적응해야 합니다. 고객은 회복할 수 있는 옵션을 가지고 있지 않습니다.

• 선택적: 새 아키텍처로의 마이그레이션은 파괴적인 변경을 강요하지 않습니다. 이 경우 고객은 도입된 변경에 점진적으로 적응할 수 있습니다: 새로운 워크플로, 새로운 API, 또는 새로운 엔드포인트를 사용하게 됩니다. 그러나 시스템의 주요 측면을 이전과 동일하게 작동하도록 유지할 수 있는 방법이 있습니다. 고객은 이전에 알려진 작동 중인 상태로 롤백할 수 있습니다.

지역 지원 가능

지역 지원은 GitLab을 다른 가용 영역 또는 완전히 다른 데이터 센터에서 실행할 수 있도록 해야 합니다.

이는 유럽, 미서부 또는 미동부에서 조직을 만들 수 있도록 허용하는 것을 포함하며, GitLab Inc.가 다른 클라우드 인프라 제공자(Google Cloud, AWS)를 사용해 고객을 제공하는 데 사용할 수 있습니다.

Cells는 GitLab.com에서 지원하는 GitLab이 지원하는 서로 다른 배포 지역/데이터 센터 사이에서 조직을 이동할 수 있게 합니다.

자기관리 고객에 대한 영향 최소화 (Omnibus/CNG)

Cells의 도입은 작은 설치에 영향을 미치지 않아야 합니다. Cells는 자기관리 고객이 추가 구성요소를 실행할 필요가 없어야 하며, Cells가 리소스 요구 사항을 증가시키는 Cells에 관심이 없는 경우에는 달라져서는 안 됩니다.

10배의 여유 공간 제공

Cells 아키텍처는 적어도 10배의 여유 공간을 제공해야 합니다. 따라서 우리의 아키텍처는 최소 10개의 Cells를 실행할 수 있어야 합니다. 우리는 초기에 10개 이상의 Cells를 실행하는 데 따르는 복잡성을 해결할 필요가 없습니다.

100배의 여유 공간 제공

Cells 아키텍처는 10개 이상의 Cells를 실행할 수 있어야 합니다.

서비스 가용성 향상

Cells 아키텍처는 클러스터의 특정 Cells에 고객을 배치함으로써 우리가 어떤 고객에 대해 더 나은 SLA를 제공할 수 있어야 합니다:

• Cells는 정당한 사용에 의한 튀는 워크로드로 인한 즉각적인 사용과 같은 소음 이웃의 영향을 줄여야 합니다.
• Cells는 암호화폐 채굴을 위해 CI가 사용됨과 같은 남용에 의한 영향을 줄여야 합니다.

사용자 당 비용이 GitLab.com과 유사하거나 낮아야 함

현재의 GitLab.com 아키텍처는 상당히 비용 효율적입니다. Cells의 도입은 데이터 분배로 인해 더 많은 인프라 구성요소를 야기할 것입니다.

• 제안된 Cells 아키텍처는 추가 Cells를 실행하는 비용을 평가해야 하며, 달성된 인프라 구성요소 격리에 따라 실행 비용을 줄이기 위해 일부 경우에는 인프라 구성요소를 재사용하는 것이 유익할 수 있습니다.
• 제안된 Cells 아키텍처는 Cells에서의 고도의 다중 테넌시를 보장해야 합니다.
• 제안된 Cells 아키텍처는 장기적으로 Cells 부하를 균형 있게 유지할 수 있는 방법을 허용할 수 있습니다.

Cells의 통합 배포 방법

제안된 Cells 아키텍처는 클러스터에서 100개 이상의 Cells를 실행해야 할 필요가 예상됩니다. 이것은 운영 오버헤드가 됩니다. Cells 아키텍처가 기존 인프라 도구를 배포, 모니터링, 로깅, 재해 복구 및 고객 지원을 최대한 재사용할 수 있도록 강력히 원합니다.

혼합 배포에서 실행되는 Cells

Cells 아키텍처가 클러스터 전체에서 다른 버전의 애플리케이션을 실행할 수 있어야 하는 것이 강력히 요구됩니다. 이는 클러스터 일부에서 변경사항을 테스트하고 클러스터의 일부를 덜 자주 업데이트할 수 있도록 함으로써 단계적 배포를 제공하는 목적입니다.

또한, Cells는 기본 인프라 구성요소의 다른 버전과 함께 작동할 수 있어야 합니다: PostgreSQL 버전, Redis 버전, Gitaly 버전, Elasticsearch 버전.

Cell 내에서 다른 버전을 사용하는 것은 다른 Cells에 영향을 주어서는 안 됩니다.

단일 Cell 장애에 대한 높은 내구성

단일 Cell의 가용성 문제는 다른 Cells가 정상적으로 작동하지 못하게해서는 안 됩니다:

• Cells 간 클러스터 통신은 단일 Cell 장애와 견고해야 합니다.
• 클러스터 내 통신은 다른 Cells에 저장된 데이터에 대한 의존성을 제한해야 합니다.
• 클러스터 공유 데이터는 단일 Cell에서 클러스터 전체 장애를 방지하는 방식으로 데이터의 훼손을 막아야 합니다.
• Cells는 모니터링되어야 하며, 다른 Cells 모두에게 가용성 상태가 액세스 가능해야 합니다.
• 클러스터 전체 데이터 집계는 각 Cell의 가용성 상태를 고려해야 합니다.
• Cell 지역 데이터 (그룹 및 프로젝트)의 손실은 해당 Cell에 있는 데이터에만 영향을 미칩니다.

작은 Cells

Cells 아키텍처는 작은 Cells를 실행하는 비용 효율적인 방법을 제공해야 합니다. 작은 Cells를 실행하면 상당히 작은 데이터 세트를 처리함으로써 지연 시간이나 성능 면에서 우수한 품질을 달성할 수 있습니다고 합니다 그리고 상당한 단일 노드 수직 확장을 허용합니다.

작은 Cells를 실행함으로써 개별 Cell 배포의 복잡성이 줄어들 수 있습니다:

• 능력을 증가시키는 첫 번째 기술로 단일 노드 수직 확장을 선호합니다 (CPU 수 증가, 사용 가능한 메모리).
• Cell 내에서 저장된 데이터 양을 줄여서 장애 복구 시간을 줄입니다.
• 데이터가 적으면 빠른 데이터베이스 마이그레이션, 개선된 지연 시간 및 사용자에게 더 나은 성능을 제공합니다.

강력한 롤백 및 재해 복구 시나리오

Cells 아키텍처의 롤아웃은 GitLab.com이 운영 방식의 기본적인 변경입니다. 이로 인해 여러 개의 새로운 구성요소를 도입하고 다양한 Cells에 데이터를 수평적으로 분산시키게 됩니다.

우리는 어느 순간에는 결정적으로 뭔가 잘못될 것이라고 예상합니다. Cells 아키텍처의 각 배포 단계는 이전에 작동했던 상태로 롤백할 수 있는 방법을 제공해야 합니다. 이에는 사용자 직면한 변경사항 및 인프라 배포된 구성요소도 포함됩니다.

기존의 GitLab.com 데이터베이스 확장

기존의 GitLab.com 데이터베이스는 Cells를 배포하는 동안 계속해서 성장할 것입니다. Cells 아키텍처는 가능한 한 빨리 Cell 1 (기존의 GitLab.com) 용량을 증가시킬 방법을 제공해야 합니다.

Cells의 가시화

어느 순간에는 Cells의 데이터 분배가 불균형해질 것으로 예상됩니다.

Cells 재분배 문제는 상당히 복잡하지만, 일정 수준에서는 매우 불균형한 Cells를 실행하는 비용에 비해 양호한 ROI를 제공할 수도 있습니다.

이것은 기존 Cells 간에 고객 데이터를 선택적으로 마이그레이션하는 방법에 대한 이해를 포함할 수 있습니다.

고객이 GitLab.com에서 Dedicated로 마이그레이션할 수 있음

Cells는 더 많은 격리를 제공하는 아키텍처를 강제합니다. 그러나, SaaS GitLab.com에서 GitLab Dedicated로 이동하고 싶어하는 고객이 있을 것으로 예상됩니다.

이것은 GitLab.com 클러스터의 Dedicated Cell로 고객을 선택적으로 마이그레이션할 수 있음을 나타내고 있습니다. 이는 다음과 같이 달성할 수 있습니다:

• 고객을 GitLab.com 클러스터의 Dedicated Cell로 마이그레이션합니다.
• GitLab.com 클러스터에서 Cell 비스니스를 분리하여 독립적인 별도의 Dedicated Cell로 만듭니다.

개발 환경에서 쉬운 사용

Cells 아키텍처는 필요할 때 개발자들이 로컬에서 쉽게 실행할 수 있는 것으로 예상됩니다. 이는 다음과 같은 기능을 가능하게 합니다:

• 클러스터 전체 기능을 구현합니다.
• Cells가 사용할 수 없는 것을 모델링합니다.

비목표

다음 목표는 이 문서의 일부가 아닙니다. 이전에 고려되었지만 위의 목표 및 요구사항으로부터의 주의를 산만하게 만드는 것으로 간주되었습니다.

서로 다른 GitLab 인스턴스 간의 연구

Cells 아키텍처는 신뢰할 수 있는 클러스터 내 통신을 제공하기 위한 것이며, 일부 데이터가 공유되는 것을 의미합니다. 연구는 완전히 다른 외부 인스턴스 간의 데이터 흐름 문제를 해결하기 위한 것으로 생각해야 합니다.

클라우드 관리형 서비스의 사용

Cells는 클라우드에서 더 많은 관리형 서비스를 사용하는 방향으로의 노력에 방해가 되어서는 안 됩니다.

Cells는 카나리 배포를 대체해서는 안 됨

Cells가 있는 경우 더 이상 카나리 배포를 실행할 필요가 없습니다. 코드 변경사항을 한 번에 하나의 Cell로 롤백할 수 있기 때문입니다. 오늘의 카나리 배포의 주된 이점은 우리가 처음에 내부 사용자에게 코드 변경사항을 먼저 배포할 수 있다는 것입니다. Cells가 있는 경우, 우리는 특정 Cell에 내부 사용자가 있을 것이고, 그 Cell을 먼저 배포할 수 있습니다.

게다가, Cells는 현재 카나리 배포의 일부 문제를 해결할 수 있는데, 예를 들어 일부 사용자로 Sidekiq 코드를 업그레이드하는 방법이 없는 문제 등이 그 예입니다.

용어 해설

Cell

• Pod는 https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/121163에서 Cell로 이름이 변경되었습니다.

Cell은 서로 다른 조직에 속하는 여러 최상위 그룹을 포함하는 인프라 구성요소의 집합입니다. 데이터 리포지터리 (PostgreSQL, Redis 등)와 무상태 서비스 (웹 등)를 모두 포함합니다. Cell 내부에서 제공되는 인프라 구성요소는 조직과 그들의 최상위 그룹 사이에서 공유되지만, 다른 Cells와는 공유되지 않습니다. 이러한 인프라 구성물의 격리는 Cells가 서로 독립적이라는 것을 의미합니다.

• 각 Cell은 다른 Cells와 독립적입니다
• 인프라 구성요소는 Cell 내의 조직과 그들의 최상위 그룹에서 공유됩니다
• 수평적 확장을 위해 더 많은 Cells를 제공할 수 있습니다
• 실패하는 Cell은 다른 Cells의 실패로 이어지지 않습니다
• 소음 이웃 효과는 Cell 안에서 제한됩니다
• Cells는 조직에서 볼 수 없습니다 - 이는 구현 상세 사항입니다
• Cells는 서로 다른 지리적 위치(예: EU, US, JP, UK)에 위치할 수 있습니다
• GitLab Dedicated 인스턴스는 클러스터에 참여하여 Cell이 될 수 있습니다

권장되지 않는 동의어: GitLab instance, cluster, shard, Pod

클러스터

클러스터는 셀(Cell)의 모음입니다.

• 클러스터에는 클러스터 전체의 메타데이터가 포함됩니다. 예: 사용자, 경로, 설정.

가능한 동의어: Whale, GitLab Dedicated 인스턴스, 인스턴스

조직

조직은 하나 이상의 최상위 그룹을 묶는 우산 역할을 합니다. 조직은 기본적으로 서로 격리되어 있어서, 교차 네임스페이스 기능은 기본적으로 단일 조직 내에서만 작동합니다.

조직 청사진을 참조하세요.

조직은 다음 가정에 따라 작동합니다:

1. 사용자는 자신의 조직 내에서 발생하는 일에 관심이 있습니다.
2. 기능은 조직 내에서 작동해야 합니다.
3. 소수의 기능만이 조직 간에 작동해야 합니다.
4. 사용자는 본사에서 볼 수 있는 페이지 대부분이 한 번에 하나의 조직에만 규제되어 있다는 것을 이해합니다.
5. 조직은 단일 셀(Cell)에 위치합니다.

속성:

• 최상위 그룹은 조직에 속합니다.
• 조직은 기본적으로 서로 격리되어 있어서, 교차 그룹 기능은 기본적으로 단일 조직 내에서만 작동합니다.
• 개인 네임스페이스는 조직에 속해서는 안 됩니다.

가능한 동의어: 과금 대상 엔터티, 고객

최상위 그룹

예:

https://gitlab.com/gitlab-org/gitlab/:

• gitlab-org는 최상위 그룹입니다. 해당 그룹은 조직의 모든 그룹 및 프로젝트의 루트입니다.
• gitlab은 프로젝트입니다. 해당 프로젝트는 조직의 프로젝트입니다.

최상위 그룹은 사실상 조직 엔터티로 활용되어 왔습니다. 조직이 생성되면 최상위 그룹은 조직 아래에 중첩될 것입니다.

시간이 지나면 최상위 그룹과 그룹 간에 차이가 없어질 것입니다. 최상위 그룹과 그룹을 구분하는 기능은 모두 조직으로 이동할 것입니다.

• 같은 조직에 속한 최상위 그룹은 동일한 셀(Cell)에 위치합니다.
• 최상위 그룹은 같은 조직에 속한 다른 최상위 그룹과 상호 작용할 수 있습니다.

가능한 동의어: 루트 레벨 네임스페이스

사용자

사용자는 전역적으로 사용 가능하며 단일 셀에 제한되지 않습니다. 사용자는 단일 조직에 속하지만 다양한 권한을 가진 그룹 및 프로젝트 멤버십을 통해 많은 조직에 참여할 수 있습니다. 조직 내에서 사용자는 여러 최상위 그룹을 생성할 수 있습니다. 사용자 활동은 단일 조직 내에서만 집계되지만, 기여(예: 할 일 디렉터리)는 조직 내에서만 집계됩니다. 이로써 셀 간 집계의 필요성이 없어집니다.

• 사용자는 전체 셀 간에 공유됩니다.
• 사용자는 여러 최상위 그룹을 만들 수 있습니다.
• 사용자는 여러 최상위 그룹의 멤버가 될 수 있습니다.
• 사용자는 하나의 조직에 속합니다. !395736 참조.
• 사용자는 여러 조직의 그룹 및 프로젝트 멤버가 될 수 있습니다.
• 사용자는 조직을 관리할 수 있습니다.
• 사용자 활동은 조직에서 집계됩니다.
• 모든 사용자는 개인 네임스페이스를 하나씩 가지고 있습니다.