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. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
proposed	`@pguinoiseau` `@jcstephenson` `@ayeung`	`@sxuereb` `@andrewn`	`@product-manager` `@sabrams`	devops data stores	2024-03-22

셀 아키텍처 및 도구

요약

이 청사진은 셀이 어떻게 설계되고, 어떤 컴포넌트가 셀 내부 또는 전역적으로 관리되며, 기존 및 새로운 도구가 어떻게 사용되어 새로운 셀을 프로비저닝할지를 설명합니다.

각 셀의 핵심은 본질적으로 GitLab.com 셀 클러스터의 일부를 형성할 수 있도록 구성된 전용 인스턴스입니다. 이를 통해 우리는 초기 셀의 프로비저닝과 구성에 대해 기존의 전용 도구(특히 Instrumentor 및 Amp)를 재사용할 수 있습니다. 한편, 전용에 의존하게 되면서 많은 결정은 이미 우리를 위해 내부적으로 어떻게 셀이 설계되어야 하는지에 관련하여 내려졌습니다.

기본 팀은 호출자가 셀과 상호 작용하려는 경우에 사용할 새로운 도구(cellctl이라고 일시적으로 명명됨)을 개발할 것입니다. 이 도구를 통해 호출자는 셀이 어떻게 구축되었는지에 대한 어떠한 지식을 가질 필요가 없습니다. 이 도구는 고객에게 셀 모델 스키마를 제시함으로써 고객이 사용할 수 있도록 만들어진 Dedicated 테넌트 모델 스키마의 축소판에 셀과 관련된 추가 필드를 추가하여, Dedicated 도구에서 사용할 수 있는 Dedicated 테넌트 모델 스키마로 변환합니다. cellctl은 또한 Terraform을 사용하여 GCP 리소스가 리소스 계층구조 내에서 적절한 위치에 있는지 확인할 것입니다. cells-tissue는 셀 정의의 진리의 원천(source of truth)으로 계속 유지될 것입니다.

셀 롤아웃의 초기 단계에서는 셀 로컬 인프라에 대한 별도의 프로비저닝 프로세스가 필요하지 않다고 여겨지지만, 셀과 Dedicated의 요구 사항이 너무 크게 이질화되어 Instrumentor 내에서 깔끔하게 통합되기 어려운 경우를 대비하여 이 옵션은 여전히 고려 대상에 둘 것입니다.

동기

한동안 GitLab.com에서 확장 가능성 한계에 부딪쳤음이 명백해졌습니다. 시끄럽고(noisye) 이웃 문제가 만연하며, 미해결된 기술 부채가 쌓이면서 인프라 관련 요구로부터 SRE(Site Reliability Engineering) 팀에게 점차 증가하는 노동 부담이 요구되었습니다.

이러한 문제들을 완화하기 위해 현재의 모놀리식 아키텍처를 견고하고 가로로 확장 가능한 다중 테넌트 아키텍처(“셀”)로 대체함으로써 이러한 문제들을 완화하고자 합니다. 이 아키텍처는 테넌트 간의 높은 수준의 격리를 제공하면서도 사용자에게는 크게 바뀌지 않은 경험을 제공합니다. 이 변경은 데이터 체류등과 같은 고객 요구 사항들의 구현 또한 가능하게 할 것으로 기대됩니다.

이를 통해 GitLab의 배포 방식에서 일정한 정도의 동질성(homogeneity)도 달성하려 합니다. 현재 GitLab.com은 다양한 도구들을 사용하여 프로비저닝: Helm, Chef, Tanka 및 Terraform 등이 있습니다. 셀은 GitLab Dedicated 테넌트의 프로비저닝에 사용된 도구를 사용하게 될 것입니다. 따라서 셀의 프로세스에 대한 모든 개선 사항은 전용 고객에게도 적용될 수 있으며 그 역도 가능합니다.

목표

이 청사진은 다음을 수행할 것입니다:

각 셀의 아키텍처 설명
특정 아키텍처적 결정이 왜 내려졌는지 설명
셀 프로비저닝에 기존 및 새로운 도구가 어떻게 사용될지에 대해 대략 설명

비목표

다음은 초과 범위에 속합니다:

셀 프로비저닝이나 구성 관리에 대한 세부 내용 - 이러한 내용들은 각각 별도의 청사진에서 다룰 것입니다(간결함을 위해)
프로세스 변경(예: 어떤 팀이 어떤 작업을 담당하는지)
도구의 저수준 구현 세부 사항
모놀리식(monolith)에서 셀로의 이전
- 모놀리식 및 셀을 함께 실행하는 방법

제안

각 셀은 사실상 나머지 GitLab.com과 원활하게 연동할 수 있는 자체 GitLab Dedicated 인스턴스이나 셀에 사용 가능한 리소스에만 제한을 둡니다. 셀의 사용자는 기본 리소스의 격리를 인식하지 못합니다.
Dedicated 도구(Instrumentor 및 Amp)가 새로운 셀을 프로비저닝하는 데 사용될 것입니다.
- 잠재적인 향후 중단을 줄이기 위해 일반 Terraform 모듈을 현재 Instrumentor 리포에서 분리하고 배포할 것입니다. Foundations 팀은 Dedicated 팀과 함께 이러한 모듈의 소유권을 공유할 것입니다.
- 셀용 별도의 Amp 환경이 설정될 것입니다.
cellctl은 셀 모델 스키마를 Dedicated 테넌트 모델 스키마로 변환하고, Instrumentor를 호출하여 테넌트를 프로비저닝하고 구성하기 위해 Foundations에 의해 개발된 도구입니다.
- cellctl은 또한 GCP의 자원 계층 구조가 cells-tissue에서 정의된 계층 구조와 일치하도록 하는 책임을 갖게 될 것입니다.

디자인 및 구현 세부 내용

아키텍처

컴포넌트

각 셀은 Cloud Native Hybrid deployment에 GitLab이 예상 작업 부하에 맞게 적절히 크기가 조절된 것입니다. 이는 GitLab Environment Toolkit (GET)을 통해 제공되며, Dedicated 도구 Instrumentor를 통해 GET 위에 오케스트레이션 레이어로 작동합니다.

셀 정의(예를 들어 각 셀의 크기, 포함된 컴포넌트 등)는 이미 여러 셀 및 링에 대한 정의를 포함하는 cells-tissue 리포지터리에 저장될 것입니다.

서비스	실행 환경
웹 서비스	쿠버네티스
Sidekiq	쿠버네티스
지원 서비스	쿠버네티스
Gitaly	Google Compute Engine VM
PostgreSQL	CloudSQL
Redis	Memorystore
객체 리포지터리	Google Cloud Storage
셀별 관측 스택	쿠버네티스
셀 간 네트워킹	Private Service Connect
ClickHouse	ClickHouse Cloud

개별 셀과 관련 없는 데이터를 다루는 전역 컨텍스트 보조 서비스들은 셀과 완전히 독립적으로 관리됩니다. 이러한 서비스는 다음을 포함합니다:

Hashicorp Vault (CI에서 사용되는 비밀 및 관측 스택에서 사용되는 공유 인프라 비밀과 같은 비밀을 저장 및 관리하기 위함)
- 우리는 기존의 프로덕션 Vault 인스턴스를 사용할 것이며, 이는 config-mgmt를 통해 구성되고, gitlab-helmfiles에 배포됩니다.
Camoproxy (자산 프록시의 프록시화)
- 우리는 gitlab-helmfiles에 배포된 기존의 Camoproxy 인스턴스를 사용할 것입니다.

셀명의 명명 규칙

Dedicated 테넌트 모델 및 GCP 프로젝트 명명에 의해 ID 필드는 최대 30자로 제한됩니다. 이는 셀명에 포함할 수 있는 메타데이터의 종류에 제한을 두게 됩니다. 예를 들어, 지역 이름을 포함할 수 없게 됩니다.

이를 고려하여, 셀은 그 테넌트 ID로 ULID를 사용하며, 이는 18자로 축약됩니다. 예를 들어, 단일 셀의 ID는 01HW6TQSAMAVPGR3N8일 수 있습니다. ULID 사양에 따르면, ID는 다음과 같이 구성됩니다:

ttttttttttrrrrrrrr

여기서
t는 타임스탬프(10자)
r은 랜덤(8자)

인간이 읽기 쉬운 상황에서 사용하는 더 예쁜 이름은 cell-로 접두사를 붙일 것이며, 예를 들어, 셀이 01HW6TQSAMAVPGR3N8의 ID를 가진다면, 그 예쁜 이름은 cell-01HW6TQSAMAVPGR3N8이 될 것입니다.

ID의 길이는 셀과 관련된 추가 GCP 프로젝트의 이름을 지을 수 있는 7개의 추가 문자를 허용합니다(필요한 경우). 예를 들어, 셀이 Runner나 Gitaly 리소스에 대해 추가 프로젝트가 필요한 경우 이러한 방식으로 이름을 짓게 될 것입니다.

cell-01HW6TQSAMAVPGR3N8-rnr123 또는 cell-01HW6TQSAMAVPGR3N8-runner
cell-01HW6TQSAMAVPGR3N8-git594 또는 cell-01HW6TQSAMAVPGR3N8-gitaly

토론은 이 이슈에서 이루어졌습니다.

GCP 프로젝트와의 관계

각 셀은 셀 간 격리를 강화하고 관리를 간소화하기 위해 GCP에서 자체 프로젝트를 갖게 될 것입니다. 이는 기존 Dedicated 도구가 테넌트 당 하나의 GCP 프로젝트를 가정하기 때문에 이를 따릅니다.

토론은 이 이슈에서 이루어졌으며, 이 ADR를 참조하세요.

네트워킹

각 셀은 해당 영역당 하나의 가상 사설망(VPC)을 갖게 될 것이며, 각 지역당 하나의 서브넷을 갖게 될 것입니다.

셀당 하나의 VPC를 가지게 함으로써, IP 주소 공간이 중첩되는 문제를 걱정할 필요가 없어지며, 완전히 격리된 상태로 만드는 등 셀을 기본적으로 안전하게 만들 수 있게 될 것입니다.

셀은 필요한 경우 다른 셀과 통신하기 위해 Private Service Connect를 사용할 것입니다. 셀들이 어떻게 연결되는 지를 지정하는 정의는 cellctl에서 사용될 것이며, 이는 셀 정의와 함께 유지될 것입니다.

토론은 이 이슈에서 이루어졌으며, 이 ADR를 참조하세요.

GCP 조직

셀을 호스팅하기 위한 유일한 목적으로 새로운 GCP 조직(GitLab Cells이라고 임시로 명명)이 만들어질 것입니다. 기존 gitlab.com 조직과 동일한 중앙화된 요금 청구 계정을 사용할 것이지만, 새로운 조직 하의 모든 리소스 및 권한은 Terraform을 통해 권한을 가진 팀 멤버들에게만 엄격하게 제어될 것입니다. 관리자 액세스는 사고 시에만 허용되며 완전히 감사 가능합니다.

이는 기존 조직의 철저한 감사와 통합보다 선호되었습니다(많은 다양한 팀에 의존하고 있어 비즈니스에 중요한 변화를 초래할 수 있는 위험을 안게 될 뿐만 아니라, 일부만 Terraform을 통해 관리될 뿐입니다). 토론은 이 이슈에서 이루어졌습니다.

클라우드 리소스 계층

셀 툴링(cellctl)은 Gitlab Cells 조직 하에 클라우드 리소스 계층을 생성 및 유지할 책임이 있을 것입니다. 이 계층은 cells-tissue 리포지터리의 파일 시스템 계층 구조를 반영해야 합니다.

이 계층에서 각 환경은 자체 폴더를 갖게 될 것이며, 이 폴더는 Ops 폴더와 Cells 폴더를 포함할 것입니다.

각 셀은 Cells 폴더 내에, (예쁘게 정돈된) ID를 이름으로 하는 자체 폴더를 갖게 될 것입니다. 이는 미래에 Runner나 추가 Gitaly 노드와 같은 셀별 컴포넌트들을 폴더에 추가할 수 있는 옵션을 제공할 것입니다.

Ops 폴더에는 Amp 환경 GCP 프로젝트가 포함될 것입니다.

셀을 제공하는 GKE 클러스터 수

각 셀은 하나의 GKE 클러스터에서 실행됩니다. 셀 간 및 셀로의 라우팅이 간단해집니다. Helm 차트는 여러 클러스터에 응용 프로그램의 한 인스턴스를 배포하는 것을 지원하지 않지만, GET은 한 클러스터에서 여러 인스턴스를 관리하는 것을 지원하지 않습니다.

토론은 이 이슈에서 확인할 수 있으며, 이 ADR에서 확인할 수 있습니다.

셀의 시크릿 관리

셀에서는 Google Secret Manager 및 Hashicorp Vault를 모두 사용할 것입니다.

Secret Manager에는 특정 GCP 프로젝트에 대한 범위가 지정된 단일 셀에 특화된 시크릿이 저장될 것입니다.

Hashicorp Vault에는 여러 (또는 모든) 셀에서 공유되는 시크릿이 저장될 것입니다. 해당 시크릿에는 observability 스택의 자격 증명이 포함될 수 있습니다.

모든 Kubernetes 시크릿은 external-secrets을 사용하여 주입되며 직접 제공되지 않습니다.

토론은 이 이슈에서 확인할 수 있습니다.

셀 접근

아직 토론 중입니다. 셀의 기본 인프라 대부분은 GCP 인스턴스의 Dedicated에서 파생되었기 때문에 셀에 대한 액세스 절차는 두 제품 간에 공유되거나 크게 유사할 것으로 예상됩니다.

Observability

일반적으로 셀의 observability 컴포넌트 수명주기는 Scalability:Observability 팀이 소유할 것입니다.

기본적으로 각 Dedicated 테넌트는 완전히 기능하는 Prometheus/Grafana 스택으로 프로비저닝됩니다. 셀은 이 스택을 재사용하여 여러 개의 셀에서 쿼리를 실행할 수 있도록 지표를 집계할 것을 의도하고 있습니다. 자세한 정보는 여기에서 확인할 수 있습니다.

토론은 이 이슈에서 확인할 수 있습니다.

도구

셀 1.0

셀 1.0 마일스톤을 최소한의 시간으로 달성하기 위해 Foundations는 다음을 수행할 것입니다.

Instrumentor monorepo에서 Dedicated GCP 인스턴스에 필요한 Terraform 모듈 추출
- 각 모듈은 자체 리포지터리로 분리되어 Instrumentor에 외부 Terraform 모듈로 판매되며, 그 후 Dedicated 팀과 Foundations에서 이러한 모듈을 유지할 책임이 있을 것입니다.
셀 및 해당 관련 Jsonnet 파일에 대한 참조 아키텍처를 Instrumentor에 추가하여 적절한 변수를 템플릿화할 수 있도록 함
cellctl이라는 새로운 도구를 개발하여 셀을 orchestrate할 것입니다.
- 셀 1.0에서 cellctl은 자체 셀 테넌트 모델을 Dedicated에서 사용하는 테넌트 모델 스키마의 일관된 인스턴스로 변환하는 얇은 번역 래퍼일 것입니다.
- 셀 모델은 Dedicated에서 사용하는 테넌트 모델 스키마의 의견에 따른 파생형으로, cellctl의 orchestrator에서 사용할 셀별 필드를 추가할 것입니다.
셀을 프로비저닝하기 위해 특별히 GCP의 새 Amp 환경 설정

다른 도구들은 ringctl과 같이 cellctl과 상호 작용하여 하나 또는 여러 셀에 대해 작업을 수행할 수 있어야 하며, 셀이 구현되거나 조정된 구체적인 내용을 알 필요는 없어야 합니다.

셀 테넌트 모델

셀의 테넌트 모델은 2개의 코어 필드로 구성된 구조를 따를 것입니다.

셀 인스턴스를 식별하는 데 사용되는 메타데이터 구조(이름 및 라벨)와 해당 셀 정의를 렌더링할 템플릿을 결정하는 데 필요한 도구별 정보를 포함하는 메타데이터 구조
셀 인스턴스의 정의에 관한 정보를 포함하는 스펙 구조

// 모델 진입점
type Cell struct {
  metadata CellMetadata
  spec     CellSpec
}

// Cells에 특화된 필드를 포함
type CellMetadata struct {
  // 셀의 식별자
  name string
  // 선택적 템플릿 지정자
  //
  // 설정되지 않은 경우 템플릿은 외부에서 제공되어야 합니다.
  template *string `json:",omitempty"`
  // 추가 어노테이션
  //
  // 셀 템플릿에 특징을 정의하고 추가적인 컨텍스트를 전달하기 위해 사용됩니다.
  annotations map[string]string `json:",omitempty"`
  // 추가 라벨
  
  // 셀 인스턴스에 인간이 이해할 수 있는 컨텍스트를 추가합니다.
  // 셀 인스턴스 전체에서 검색을 수행할 수 있습니다.
  labels map[string]string `json:",omitempty"`
}

// Dedicated 도구를 통한 셀의 정의에 관련된 필드를 포함
type CellSpec struct {
  // 기본 GCP 프로젝트 ID
  project_id string
  // 이 셀을 프로비저닝할 지역
  region string
  // 참조 아키텍처
  reference_architecture string
  // Instrumentor 버전
  instrumentor_version *string `json:",omitempty"`
  // GitLab 버전
  gitlab_version *string `json:",omitempty"`
  // 사전 릴리스 버전
  prerelease_version *string `json:",omitempty"`
}

cellctl은 YAML 파일에서 이러한 셀 인스턴스 정의를 처리하고 jsonnet 템플릿의 매핑 레이어를 통해 Amp 및 Instrumentor를 통해 프로비저닝할 테넌트 모델을 출력합니다.

이러한 셀 정의 파일은 cellctl과 동일한 평면에서 다른 도구에 의해 처리되어 전체 셀 인스턴스에 대한 “글로벌” 뷰로 추가 인프라를 생성할 수 있습니다.

셀 1.0 이후

셀이 점차적으로 구축됨에 따라 Dedicated 테넌트 및 셀의 요구 사항이 분리될 수 있으며, 이를 Instrumentor로 통합하려는 시도는 수용할 수 없는 복잡성을 야기할 수 있습니다. 이로 인해 Foundations에서 개발 및 유지할 셀 특화 도구들을 프로비저닝하고 관리할 수 있어야 합니다.

셀에 대해 구현해야 하는 위치는 어디인가요?

단일 셀을 구성하는 컴포넌트에 대한 리소스 정의를 포함하는 네 곳이 있습니다. 각각은 다음을 기반으로 구축됩니다:

셀을 구축하면 언제나 무엇을 추가해야 하는지에 대한 질문이 생깁니다. 다음 차트가 결정을 안내하는 데 도움이 될 것입니다:

flowchart TD A[모든 셀에 무언가를 추가하려고 합니다] --> B[GitLab의 공식 배포의 일부여야 합니까?] B -->|예| C[Helm 차트/Omnibus에 추가해야 합니까?] B -->|아니요| D[GitLab 인스턴스를 자체로 관리하는 데 가장 좋은 방법으로 간주됩니까?] D -->|예| E[GET에 추가해야 합니까?] D -->|아니요| F[현재 또는 향후 Dedicated 고객들로부터 이에 대한 요구가 있습니까?] F -->|예| G[Instrumentor 공유 Terraform 모듈에 추가] F -->|아니요| H[추가 작업이 많지 않고 Dedicated 고객에게 이득이 될 수 있습니까?] H -->|예| G H -->|아니요| I[cells-tissue에 추가]

```markdown