• Goals
  • Scalability
  • Increased availability
  • A consistent experience
  • Regions
  • Market segment
  • Self-managed
• Requirements
  • 클러스터 전체 데이터 집계
  • 모든 Cell은 단일 GitLab.com 도메인에 있음
  • 사용자가 여러 Cell과 상호 작용할 수 있음
  • 기여자 작업에 대한 최소한의 영향
  • 온프레미스와 유사한 경험
  • 파괴적인 변경 최소화
• …
  • Small Cells
  • 강력한 롤백 및 재해 복구 시나리오
  • 기존 GitLab.com 데이터베이스 확장
  • 셀 재분배
  • 고객이 GitLab.com에서 Dedicated로 마이그레이션
  • 개발 환경에서 쉬운 사용
• 비목표
  • 다른 분명히 다른 GitLab 인스턴스 간 연합
  • 클라우드 관리형 서비스의 사용
  • 캐너리 배포 대체 여부
• 용어 해설
  • 셀
  • 클러스터
  • 조직
  • 최상위 그룹
  • 사용자

Cells: Goals

Goals

Scalability

이 새로운 공유 인프라 아키텍처의 주요 목표는 SaaS 플랫폼의 확장성을 더욱 추가하는 것입니다. GitLab.com은 주로 단일체(monolithic)이며 현재의 아키텍처에는 확장성 제약이 있다고 내부적으로 추정했습니다. 특히 PostgreSQL 데이터베이스 및 Redis를 수평적으로 확장할 수 없는 자원으로 특히 제한됩니다. 데이터베이스 분할 및 분해가 고려되어도 마찬가지입니다.

Cells는 추가적인 Cell을 필요에 따라 생성할 수 있기 때문에 수평적으로 확장 가능한 솔루션을 제공합니다. Cell은 최적의 확장성을 위해 필요에 따라 프로비저닝 및 튜닝될 수 있습니다.

Increased availability

공유 인프라 아키텍처의 주요 과제는 최상위 그룹 간의 격리 부재입니다. 이로 인해 소음 이웃 효과가 발생할 수 있습니다. 최상위 그룹 내에서 조직의 행동은 다른 모든 조직에 영향을 미칠 수 있습니다. 이는 매우 바람직하지 않습니다. Cells는 Cell 수준에서 격리를 제공합니다. 다른 Cell에 위치한 조직의 경우 다른 조직들과 완전히 격리됩니다. 이는 소음 이웃 효과를 최소화하면서도 공유 인프라의 비용 효율성을 누릴 수 있도록 합니다.

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

A consistent experience

조직은 자체 관리형 GitLab 인스턴스와 동일한 사용자 경험을 가져야 합니다.

Regions

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

Market segment

현재 GitLab.com에는 “소셜 네트워크”와 같은 기능이 있으며 더 이상 고립된 조직 모델과 잘 맞지 않을 수 있습니다. 그러나 이러한 기능을 제거하는 것은 어려움을 야기합니다:

1. 기존 gitlab-org 기여자들이 이름 공간에 기여하는 방법은?
2. 기존 최상위 그룹을 새로운 모델로 어떻게 이전해야 하는가 (사실상 그들의 소셜 기능을 파괴함)?

이러한 기능에 중소기업 및 중간 시장 세그먼트가 관심이 있는지, 또는 이러한 기능이 대부분의 경우에는 허용 가능한지에 대해 평가해야 합니다.

Self-managed

일관성을 유지하기 위해, 자체 관리형 인스턴스도 셀 아키텍처를 채택할 것으로 예상됩니다. 자체 관리형 인스턴스는 추가 Cell을 추가하는 옵션을 지원하는 동안에도 단일 Cell로 계속할 것으로 예상됩니다. 또한, 조직 및 가능한 사용자 분해도 자체 관리형 인스턴스에 채택될 것입니다.

Requirements

클러스터 전체 데이터 집계

이 아키텍처는 Cell들의 클러스터를 단일 뷰로 제공할 수 있어야 합니다. 이는 아래를 의미할 수 있습니다:

• 다른 조직들로부터 사용자 To-Do 집계
• 클러스터 전체에서 공개 프로젝트 또는 공개 소스 코드에 대한 검색 수행

모든 Cell은 단일 GitLab.com 도메인에 있음

일반 사용자는 Cell의 존재를 알 수 없어야 합니다. Cell은 인스턴스 관리자에게만 표시됩니다. 다른 Cell에 있는 조직을 사용하는 사용자 또는 저희가 조직을 이전하는 것은 사용자의 개입이 필요 없는 운영 상세 정보이거나 사용자에게가 시인(Acknowlwdgement)될 필요가 없어야 합니다.

사용자가 여러 Cell과 상호 작용할 수 있음

다른 Cell에 있는 여러 계정을 사용하여 상호 작용하는 것은 강력히 권장되지 않습니다. 많은 계정을 사용하는 필요성은 채택을 줄이고 오픈 소스 프로젝트에 기여하고자 하는 사용자들에게 장벽을 설정할 것입니다.

앞으로 고객의 특정 기대에 따라 사용자별 설정이 있을 수 있습니다. 예를 들어, 사용자는 다른 조직에서 서로 다른 표시명을 사용할 수 있습니다.

사용자는 사용자가 많은 SSH 키를 관리하는 복잡성 때문에 서로 다른 SSH 키를 사용하기 위해 요구되어서는 안 됩니다.

기여자 작업에 대한 최소한의 영향

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

온프레미스와 유사한 경험

현재 온프레미스는 SaaS 제공과 비교하여 많은 이점을 가지고 있습니다.
온프레미스는 GitLab 설치의 모든 측면을 제어할 수 있게 해주며, 사용자, 접근 제어, 또는 인스턴스 전반적인 설정 등을 포함합니다.

SaaS와 온프레미스의 차이는 고객 및 우리에게 문제가 됩니다. 왜냐하면 이로 인해 사용자 경험이 달라지기 때문입니다.

파괴적인 변경 최소화

Cells의 도입은 GitLab.com 워크플로우에 변경 사항을 의미합니다.
Cells는 사람들이 GitLab을 사용하는 방식에 영향을 줄 수 있지만, 매력적인 사용자 경험 스토리를 제공한다면 영향을 줄일 수 있습니다.
도입된 각 변경은 운영적 가치 또는 사용자 가치 중 적어도 하나를 제공하는 것이 바람직하며, 이상적으로는 둘 다 제공해야 합니다.

…

(이하 생략)

Small Cells

셀 아키텍쳐는 소규모 셀을 실행하는데 경제적인 방법을 제공해야 합니다.
소규모 셀을 실행하는 것은 상당히 작은 데이터 세트를 처리하고 중요한 단일 노드 수직 확장을 허용하여 지연 시간이나 성능 측면에서 우수한 품질을 달성할 수 있습니다.

소규모 셀을 실행하는 능력은 개별 셀 배포의 복잡성을 줄일 수 있습니다.

• 능력을 증가시키기 위한 첫 번째 기술로 단일 노드 수직 확장을 선호합니다 (CPU 개수, 사용 가능한 메모리 증가).
• 셀 내에 저장된 데이터 양을 줄여 오류 발생 시 복구 시간을 단축합니다.
• 데이터가 적으면 더 빠른 데이터베이스 이주, 향상된 지연 시간 및 사용자 지향 성능을 제공합니다.

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

셀 아키텍쳐의 배포는 GitLab.com의 작동 방식에 대한 근본적인 변경입니다.
이로써 여러 개의 새로운 구성 요소를 도입하고 데이터를 다른 셀들에 수평적으로 분산시킬 것입니다.

어느 순간에는 뭔가 잘못될 것으로 예상됩니다. 셀 아키텍쳐의 각 배포 단계는 이전에 작동하던 상태로 롤백할 수 있는 방법을 제공해야 합니다. 이는 고객이 직면하는 변경과 인프라 구성 요소 모두를 포함합니다.

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

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

셀 재분배

어느 순간 셀들의 데이터 분배가 불균형하게 될 것으로 예상됩니다.

셀 재분배 문제는 꽤 복잡하지만 일정 수준에서 불균형한 셀의 운영 비용과 비교하여 긍정적인 투자 수익을 제공할 수도 있습니다.

이는 이미 존재하는 셀로 고객 데이터를 선택적으로 이주시키는 방법을 이해하는 것을 포함할 수 있습니다.

고객이 GitLab.com에서 Dedicated로 마이그레이션

셀은 보다 격리된 아키텍처를 강제할 것으로 예상됩니다. 그러나 일부 고객은 SaaS GitLab.com에서 GitLab Dedicated로 이동하길 원할 것으로 예상됩니다.

이는 GitLab.com 클러스터에서 Dedicated로 고객 데이터를 선택적으로 이주시킬 수 있어야 함을 의미합니다.
이는 다음과 같은 방법으로 달성될 수 있습니다:

• 고객을 GitLab.com 클러스터의 Dedicated Cell로 마이그레이션합니다.
• Cell을 GitLab.com 클러스터에서 분리하여 독립적인 독립형 Dedicated Cell로 전환합니다.

개발 환경에서 쉬운 사용

셀 아키텍처는 개발자가 필요에 따라 로컬에서 쉽게 실행할 수 있어야 합니다. 이를 위해 다음과 같은 기능을 할 수 있어야 합니다:

• 클러스터 전체 기능 구현
• 셀을 사용할 때 사용 불가능한 모델

비목표

다음 목표는 이 문서의 일부가 아닙니다. 어느 순간에는 고려되었지만 위에 문서화된 목표와 요구 사항으로부터 주의를 돌릴 뿐입니다.

다른 분명히 다른 GitLab 인스턴스 간 연합

셀 아키텍쳐는 신뢰할 수 있는 클러스터 내 통신을 제공하기 위한 것입니다. 연합은 데이터가 완전히 다른 외부 인스턴스 간의 데이터 흐름 문제를 해결하기 위한 것입니다.

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

셀은 클라우드에서 관리형 서비스를 사용하는 노력을 방해해서는 안 됩니다.

캐너리 배포 대체 여부

셀이 있으면 더 이상 캐너리 배포를 실행할 필요가 없습니다. 왜냐하면 변경 사항을 한 번에 단일 셀로 전개할 수 있기 때문입니다.
오늘날 캐너리 배포의 주요 이점은 내부 사용자에게 먼저 코드 변경을 배포할 수 있다는 것입니다.
셀을 사용하면 특정 Cell에 내부 사용자를 두어 먼저 배포할 수 있기 때문에 오늘날의 캐너리 배포 문제를 해결할 수도 있습니다.

게다가 셀은 오늘날 캐너리의 일부 문제를 해결할 수도 있습니다. 예를 들면 일부 사용자의 사이드킥 코드를 업그레이드할 방법이 없는 등의 문제가 있습니다.

용어 해설

셀

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

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

• 각 셀은 다른 셀과 독립적입니다.
• 인프라 구성 요소는 셀 내의 조직과 그들의 최상위 그룹에서 공유됩니다.
• 수평적 확장성을 제공하기 위해 더 많은 셀이 구성될 수 있습니다.
• 문제가 발생하는 셀은 다른 셀의 장애로 이어지지 않습니다.
• 노이즈 이웃 효과는 셀 내에서 한정됩니다.
• 셀은 조직에게는 보이지 않습니다 - 이는 구현 세부 정보입니다.
• 셀은 지리적으로 서로 다른 위치에 있을 수 있습니다 (예: EU, US, JP, UK).
• GitLab Dedicated 인스턴스는 클러스터에 참여하여 셀이 될 수 있습니다.

권장되지 않는 동의어: GitLab 인스턴스, 클러스터, shard, Pod

클러스터

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

• 클러스터에는 클러스터 전역 메타데이터가 보관됩니다. 예를 들어: 사용자, 라우트, 설정.

비권장 동의어: 고래, GitLab 전용 인스턴스, 인스턴스

조직

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

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

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

1. 사용자는 자신의 조직 내에서 발생하는 일에 관심이 있습니다.
2. 기능은 조직 내에서 작동해야 합니다.
3. 일부 기능만이 조직을 넘나들 수 있어야 합니다.
4. 사용자는 대부분의 페이지가 한 번에 하나의 조직에 대해만 범위를 가지고 있다는 것을 이해합니다.
5. 조직은 한 셀에 위치해 있습니다.

속성:

• 최상위 그룹은 조직에 속합니다.
• 조직은 기본적으로 서로 격리되어 있어서 교차 그룹 기능은 해당 조직 내에서만 작동합니다.
• 개인 네임스페이스는 반드시 어떤 조직에도 속하지 않아야 합니다.

비권장 동의어: 과금 대상 엔터티, 고객

최상위 그룹

예시:

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

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

최상위 그룹은 사실상 조직 엔터티로 기능해 왔습니다. 그러나 조직이 만들어지면 최상위 그룹은 조직 내에 중첩되어야 합니다.

시간이 지남에 따라 최상위 그룹과 그룹 간의 구분이 없어질 것입니다. 최상위 그룹을 그룹과 구분 지을 수 있는 모든 기능은 조직으로 옮겨질 것입니다.

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

비권장 동의어: 루트 레벨 네임스페이스

사용자

사용자는 전역적으로 사용 가능하며 특정 셀에 제한되지 않습니다. 사용자는 한 조직에 속하지만 권한에 따라 여러 조직을 통해 다양한 그룹 및 프로젝트에 참여할 수 있습니다. 조직 내에서 사용자는 여러 최상위 그룹을 생성할 수 있습니다. 사용자의 활동은 한 조직 내에서 집계되지만, 참여도(예: 할 일)는 조직 내에서만 집계됩니다. 이를 통해 셀 간 집계의 필요성을 없앨 수 있습니다.

• 사용자는 모든 셀에서 공유됩니다.
• 사용자는 여러 최상위 그룹을 생성할 수 있습니다.
• 사용자는 여러 최상위 그룹의 구성원이 될 수 있습니다.
• 사용자는 한 조직에 속합니다. 관련 이슈는 !395736를 참조하세요.
• 사용자는 여러 조직의 그룹 및 프로젝트 구성원이 될 수 있습니다.
• 사용자는 조직을 관리할 수 있습니다.
• 사용자의 활동은 조직 내에서 집계됩니다.
• 각 사용자는 개인 네임스페이스를 가지고 있습니다.