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

Cells: Goals

목표

확장성

이 새로운 공유 인프라 아키텍처의 주요 목표는 저희 SaaS 플랫폼에 추가적인 확장성을 제공하는 것입니다. GitLab.com은 대부분 모놀리식이며, 현재의 아키텍처는 특히 PostgreSQL 데이터베이스와 Redis와 같은 수평적으로 확장할 수 없는 자원에 대한 확장성 제약이 있다는 내부 추정이 있습니다. 데이터베이스 파티셔닝과 분해를 고려할 때라도 확장성에 제약이 있습니다.

Cells는 수평적으로 확장 가능한 솔루션을 제공하며 추가적인 Cells를 수요에 따라 생성할 수 있습니다. Cells는 최적의 확장성을 위해 필요에 따라 프로비저닝되고 튜닝될 수 있습니다.

가용성 증가

공유 인프라 아키텍처의 주요 도전 과제는 최상위 그룹 간의 격리 부족입니다. 이는 잘못된 이웃 효과를 일으킬 수 있습니다. 최상위 그룹 내 조직의 행동은 다른 모든 조직에 영향을 미칠 수 있습니다. 이는 매우 바람직하지 않습니다. Cells는 Cell 수준에서 격리를 제공합니다. 여러 조직으로 구성된 그룹은 다른 Cells에 위치한 다른 조직과 완전히 격리됩니다. 이로써 잡음이 발생하는 효과를 최소화하면서도 공유 인프라의 경제성을 누리게 됩니다.

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

일관된 경험

조직은 우리 SaaS 플랫폼에서 Self-managed GitLab 인스턴스와 동일한 사용자 경험을 가져야 합니다.

지역

GitLab.com은 미국에서만 호스팅됩니다. 다른 지역에 위치한 조직들은 지역별 SaaS 제공에 대한 수요를 표명했습니다. Cells는 다른 지리적 위치에 배치될 수 있기 때문에 GitLab 지역을 향한 길을 제공합니다. 조직의 데이터가 어떤 Cell 밖에 위치하는지에 따라, 이는 데이터 체류 및 규정 준수 문제를 해결할 수 있을 것입니다.

시장 세그먼트

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

1. 기존 gitlab-org 기여자들이 네임스페이스에 기여하는 방법은?
2. 기존 최상위 그룹을 새 모델로 옮기는 방법은 (사실상 그들의 소셜 기능을 파기하는 것)?

우리는 소규모 및 중소 규모 비지니스 및 중간 시장 세그먼트가 이러한 기능에 흥미를 갖는지, 또는 이러한 기능이 없어도 대부분의 경우에 수용 가능한지를 평가해야 합니다.

Self-managed

일관성을 유지하기 위해, Self-managed 인스턴스도 셀 아키텍처를 채택할 것으로 예상됩니다. Self-managed 인스턴스는 추가적인 Cells를 지원하면서 단일 Cell만 사용할 수 있을 것으로 기대됩니다. 조직 및 사용자 분해도 Self-managed 인스턴스에서 채택될 것입니다.

요구 사항

클러스터 전체 데이터 집계

이 아키텍처는 Cells 클러스터를 단일 뷰로 제시할 수 있는 방법을 제공해야 합니다. 이는 아마도 다음을 의미할 것입니다:

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

모든 Cells는 단일 GitLab.com 도메인 내에 있음

일반 사용자는 Cells의 존재를 모르도록 해야 합니다. Cells는 인스턴스 관리자에게만 표시될 것입니다. 다른 Cell에서 조직을 사용하고 있는 사용자 또는 우리가 조직을 Cells 간으로 마이그레이션하는 것은 사용자의 개입을 요구하지 않거나 사용자에게 표시되지 않는 운영상 세부 사항이어야 합니다.

사용자가 많은 Cells와 상호 작용할 수 있음

다양한 Cells에 있는 서로 다른 조직과 상호 작용하기 위해 여러 계정을 사용하는 것은 강력히 권장되지 않습니다. 많은 계정을 사용해야 하는 필요성은 사용자의 참여를 줄이고 오픈 소스 프로젝트에 기여하고자 하는 사용자들에게 장벽을 설정할 것입니다.

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

사용자는 복잡한 SSH 키 관리로 인해 다른 조직에 접근하기 위해 다른 SSH 키를 사용해야 하는 것이 필요하지 않아야 합니다.

기여자 워크플로에 최소한의 영향을 미침

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

온프레미스와 유사한 경험

현재 온프레미스는 저희 SaaS 제공과 비교해서 수많은 장점을 갖고 있습니다. 온프레미스는 사용자, 액세스 제어 또는 인스턴스 전반적인 설정을 포함한 GitLab 설치의 모든 측면을 제어할 수 있게 해줍니다.

SaaS와 온프레미스 간의 차이는 고객과 우리에게 문제가 됩니다. 또한 이는 다른 사용자 경험으로 이어집니다.

중단을 최소화하는 변경

Cells의 도입은 GitLab.com에서 지원하는 워크플로우에 변경을 야기할 것입니다. Cells는 사람들이 GitLab을 사용하는 방식에 영향을 미칠 수 있지만, 매력적인 사용자 경험 이야기를 제공하는 한 상관 없습니다. 도입된 변경은 운영 가치 또는 사용자 가치 중 적어도 하나를 제공하는 것이 바람직합니다.

어떤 Cells 아키텍처도 중단을 일으키지 않는데 초점을 맞춰야 합니다. 또한, 중단을 일으키는 변경을 도입하는 경우 긴 호환성 지원 기간을 제공하여야 할 것입니다. 중단을 일으킴으로써 채택률과 Cells의 효과적인 구현에 위험을 야기할 수 있습니다.

중단 변경의 다양한 심각성을 구별하는 것이 중요합니다:

• 필수: 새 아키텍처로의 마이그레이션은 의도적으로 중단을 일으키는 변경을 함께 도입합니다. 이 경우 고객은 새로운 워크플로우, 새 API 또는 즉시 모든 변경에 적응해야 하며, 변화에 대한 제한된 옵션을 갖게 됩니다.

• 선택 사항: 새 아키텍처로의 마이그레이션은 중단을 일으키는 변경을 강요하지 않습니다. 이 경우 고객은 소프트하게 변화를 적응할 수 있습니다. 새로운 워크플로우, 새 API 또는 변화된 부분을 유지한 채 지난 시스템으로 롤백할 수 있는 방법을 갖게 됩니다.

지역 지원 활성화

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

이는 유럽, 미국 서부 또는 미국 동부에서 조직을 생성할 수 있도록 허용하는 것을 포함하지만 이에 국한되지는 않습니다. 그리고 GitLab Inc.은 고객에게 서비스하기 위해 Google Cloud, AWS와 같은 다른 클라우드 인프라 제공업체를 사용할 수 있어야 합니다.

셀은 GitLab.com에서 지원하는 서로 다른 배포 지역/데이터 센터로 기존 고객이 자신들의 조직을 이동할 수 있도록 합니다.

Self-managed 고객에 미치는 영향 제한

셀의 도입은 소규모 설치에 영향을 미치지 않아야 합니다. 셀은 Self-managed 고객이 추가 컴포넌트를 실행할 필요가 없어야 하며, Cells를 사용하기를 희망하는 경우에만 리소스 요구 사항을 늘릴 수 있어야 합니다.

10배 여유 공간 제공

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

100배 여유 공간 제공

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

서비스 가용성 향상

셀 아키텍처는 클러스터의 특정 셀에 특정 고객에 대한 더 나은 SLA를 제공할 수 있어야 합니다:

• 셀은 예를 들어 암호화폐 채굴을 위해 CI가 사용됨과 같은 합법적인 사용에 의해 발생한 사용량과 같은 소란스러운 이워에 대한 영향을 줄여야 합니다.
• 셀은 남용에 의해 발생한 영향을 줄여야 합니다.

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

현재의 GitLab.com 아키텍처는 비용 효율적입니다. 셀의 도입은 데이터 분산으로 인해 더 많은 인프라 컴포넌트를 초래할 것입니다:

• 제안된 셀 아키텍처는 추가 셀을 실행하는 데 드는 비용을 평가해야 하며, 이를 통해 인프라 컴포넌트 격리를 달성해야 합니다. 경우에 따라 셀이 실행 비용을 줄이기 위해 인프라 컴포넌트를 재사용하는 것이 이점이 될 수 있습니다.
• 제안된 셀 아키텍처는 셀에서의 고도의 다중 테넌시를 보장해야 합니다.
• 제안된 셀 아키텍처는 장기적으로 셀 부하를 균형있게하는 방법을 가능하게 할 수 있습니다.

셀 배포의 통일된 방법

제안된 셀 아키텍처는 클러스터에서 100개 이상의 셀을 실행해야 한다고 예상합니다. 이는 운영 부담이 됩니다. 셀 아키텍처는 다음과 같은 것들에 대해 가능한 한 기존 인프라 도구를 재사용하기를 강력히 원합니다: 배포, 모니터링, 로깅, 재해 복구 및 고객 지원.

혼합 배포에서 실행되는 셀

셀 아키텍처는 클러스터 전반에서 다른 버전의 응용 프로그램을 실행해야 합니다. 이는 클러스터의 일부에서 변경 사항을 테스트하고 클러스터의 일부를 덜 자주 업데이트하는 것을 허용하기 위함입니다.

또한, 셀은 기본 인프라 컴포넌트의 다른 버전과 함께 작동할 수 있어야 합니다: PostgreSQL 버전, Redis 버전, Gitaly 버전, Elasticsearch 버전.

셀 내에서 다른 버전을 사용하는 것은 다른 셀에는 영향을 주지 않아야 합니다.

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

단일 셀의 가용성 문제가 다른 셀이 제대로 기능하지 못할 수 있도록 해서는 안됩니다:

• 셀 간 클러스터 내 통신은 단일 셀의 장애에 대해 내구성이 있어야 합니다.
• 클러스터 내 통신은 다른 셀에 저장된 데이터에 대한 의존성을 제한해야 합니다.
• 클러스터 공유 데이터는 단일 셀이 클러스터 전체 장애를 발생시키지 않도록 방지하는 손상 방지 계층을 제공해야 합니다.
• 셀은 모니터링되어 있어야 하며, 가용성 상태는 모든 다른 셀에게 액세스 가능해야 합니다.
• 클러스터 전체 데이터 집계는 각 셀의 가용성 상태를 고려해야 합니다.
• 셀 로컬 데이터(그룹 및 프로젝트)의 손실은 해당 셀에 위치한 데이터에 대한 액세스에만 영향을 줍니다.

소형 셀

셀 아키텍처는 소형 셀을 실행할 수 있는 비용 효율적인 방법을 제공해야 합니다. 소형 셀을 실행하는 것은 데이터 집합이 지나치게 작아지므로 우수한 품질을 달성할 수 있고, 중요한 단일 노드 수직 스케일링을 허용하여 지연 시간 또는 성능 면에서 우수성을 얻을 수 있습니다.

소형 셀을 실행하는 능력은 개별 셀 배포의 복잡성을 감소시킬 수 있습니다:

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

견고한 롤백 및 재해 복구 시나리오

셀 아키텍처의 롤아웃은 GitLab.com이 운영되는 방식에 대한 근본적인 변화입니다. 이는 기존의 컴포넌트를 도입하고 데이터를 클러스터 전체로 가로방향으로 분산할 것입니다.

어떤 시점에서 무언가 잘못될 것으로 예상됩니다. 셀 아키텍처의 각 배포 단계는 이전 작동 상태로 롤백할 수 있는 방법을 제공해야 합니다. 이는 사용자의 변경 사항 뿐 아니라 배포된 인프라 컴포넌트에 대해서도 적용됩니다.

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

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

셀 리밸런싱

어느 순간에는 셀에서 데이터 분산이 불균형해질 것으로 예상됩니다.

셀의 재분산 문제는 상당히 복잡하지만 어느 정도 규모에 도달하면 불균형한 셀 제어 비용에 비해 양호한 ROI를 제공할 수 있습니다.

이는 기존 셀에 데이터를 선택적으로 이주하는 방법을 이해하는 것일 수 있습니다.

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

셀은 더 많은 격리를 제공하는 아키텍처를 강제할 것입니다. 그러나 SaaS GitLab.com에서 GitLab Dedicated로 이동하고자 하는 고객도 예상할 수 있습니다.

이것은 GitLab.com 클러스터에서 전용 셀로 고객을 선택적으로 마이그레이션하고자 하는 경우를 의미합니다.

개발 환경에서의 쉬운 사용

셀 아키텍처는 필요한 경우 개발자들이 로컬로 쉽게 실행할 수 있어야 합니다:

• 클러스터 전반 기능을 구현합니다.
• 셀이 사용 불가능한 모델링.

비목표

다음 목적은 이 문서의 일부가 아닙니다. 어느 정도까지는 고려되었지만 위에 문서로부터의 목표와 요구 사항으로 인해 주의를 산만하게 만들었다고 여겨집니다.

고유한 GitLab 인스턴스 간 연맹

셀 아키텍처는 신뢰할 수 있는 클러스터 내 통신을 제공할 것으로 기원합니다. 연맹은 완전히 다른 외부 인스턴스 간의 데이터 흐름 문제를 해결하기 위해 고안되었습니다.

클라우드 관리 서비스 사용

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

캐너리 배포 대체

셀을 갖게 되면 더 이상 캐너리 배포를 실행할 필요가 없어질 것입니다. 우리의 현재 캐너리 배포의 주요 이점은 코드 변경을 먼저 내부 사용자에게 롤아웃할 수 있다는 것입니다. 셀을 갖게 되면 특정 Cell에서 내부 사용자를 갖게 될 것이므로 먼저 배포할 수 있습니다.

게다가 셀은 현재 캐너리들과 관련된 문제를 해결할 수 있을 것입니다. 예를 들어 일부 사용자의 Sidekiq 코드를 업그레이드할 방법이 없는 등의 문제를 해결할 수 있음입니다.

용어 해설서

Cell

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

Cell은 여러 조직에 속하는 다양한 최상위 그룹을 포함하는 인프라 컴포넌트 집합입니다. 이 컴포넌트에는 데이터 리포지터리(PostgreSQL, Redis 등) 및 상태 없는 서비스(web 등)가 모두 포함됩니다. Cell 내에서 제공되는 인프라 컴포넌트는 조직 및 그들의 최상위 그룹 간에 공유되지만 다른 Cell과는 공유되지 않습니다. 이러한 인프라 컴포넌트의 격리로, Cell은 서로 독립적입니다.

• 각 Cell은 다른 Cell과 상호 독립적입니다.
• 인프라 컴포넌트는 Cell 내에서 조직 및 그들의 최상위 그룹에 의해 공유됩니다.
• 수평 확장성을 제공하기 위해 더 많은 Cell을 추가로 설정할 수 있습니다.
• Cell의 장애는 다른 Cell의 장애로 이어지지 않습니다.
• 소음 이웃 효과는 Cell 내로 제한됩니다.
• 조직에서는 Cell을 볼 수 없습니다. 이는 구현 세부 사항입니다.
• Cell은 지리적으로 다른 지역(EU, US, JP, UK 등)에 위치할 수 있습니다.
• GitLab Dedicated 인스턴스는 클러스터에 참여하여 Cell이 될 수 있습니다.

비권장 동의어: GitLab instance, cluster, shard, Pod

클러스터

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

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

비권장 동의어: Whale, GitLab Dedicated instance, instance

조직

하나 이상의 최상위 그룹을 위한 대장입니다. 조직은 기본적으로 서로 격리되어 있으며, 이는 교차 네임스페이스 기능이 단일 조직 내에서만 작동한다는 것을 의미합니다.

조직 설계도를 확인하세요.

조직은 AWS 및 GCP 등에서 이미 알려진 개념으로, 다음 가정에 따라 작동합니다:

1. 사용자는 자신의 조직 내에서 발생하는 일에 관심이 있습니다.
2. 기능은 조직 내에서 작동해야 합니다.
3. 교차 조직 기능은 소수의 기능만 지원해야 합니다.
4. 사용자는 자신이 볼 대부분의 페이지가 한 번에 한 조직에만 규정되는 것으로 이해합니다.
5. 조직은 하나의 Cell에 위치합니다.

속성:

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

비권장 동의어: Billable entities, customers

최상위 그룹

예시:

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

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

최상위 그룹은 사실상 조직 엔터티로 작용했습니다. 조직이 생성되면 최상위 그룹은 조직에 중첩되어 위치하게 됩니다.

시간이 흐른 뒤에는 최상위 그룹과 그룹 간의 구별이 없어질 것입니다. 최상위 그룹이 그룹과 다른 점을 만드는 모든 기능은 조직으로 이동합니다.

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

비권장 동의어: Root-level namespace

사용자

사용자는 전역적으로 사용 가능하며 특정 Cell에 제한되지 않습니다. 사용자는 하나의 조직에 속하지만 다양한 권한으로 그룹 및 프로젝트 멤버십을 통해 다양한 조직에 참여할 수 있습니다. 조직 내에서 사용자는 여러 최상위 그룹을 생성할 수 있습니다. 사용자 활동은 하나의 조직에서만 집계되지만 그들의 기여(예: 할 일)는 조직 내에서만 집계됩니다. 이는 Cell 간의 집계를 피하기 위한 것입니다.

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