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
ongoing	`@ayufan` `@fzimmer` `@DylanGriffith` `@lohrc` `@tkuah`	`@ayufan`	`@lohrc`	devops data stores	2022-09-07

셀

이 문서는 작업 중인 상태로 Cells 설계의 매우 초기 상태를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 향후 추가될 것으로 예상됩니다.

Cells는 우리의 소프트웨어 서비스 플랫폼을 위한 새로운 아키텍처입니다. 이 아키텍처는 수평으로 확장 가능하고, 강건하며, 더 일관된 사용자 경험을 제공합니다. 또한, 데이터 소재지 제어(지역)와 연합 기능과 같은 추가 기능을 제공할 수도 있습니다.

Cells에 대한 자세한 내용은 아래를 참조하세요:

셀 이터레이션

Cells 1.0의 목표는 새로운 엔터프라이즈 고객이 SaaS GitLab.com 제공을 사용하는 솔루션을 제공하는 것입니다.
Cells 1.5의 목표는 기존의 엔터프라이즈 고객이 SaaS GitLab.com 제공을 사용하면서 Cells 1.0 아키텍처를 기반으로 한 이주 솔루션을 제공하는 것입니다.
Cells 2.0의 목표는 셀러 형태의 아키텍처에 대한 공개 및 오픈소스 기여 모델을 지원하는 것입니다.

목표

목표, 용어 및 요구 사항 확인

작업 스트림

전체 Cells 아키텍처를 한 번에 배포할 수 없습니다. 너무 클기 때문입니다. 대신, 프로젝트에서 필요한 주요 작업 스트림을 정의하고 있습니다. 각 작업 스트림에 대해 Cell 1.0, Cell 1.5 및 Cell 2.0과 호환되도록 기능을 만들기 위한 노력을 정의해야 합니다.

일반적으로 일부 목표는 일반 공개(GA)에는 완료되지 않을 것으로 예상하지만 Cells를 운영하는 데 충분할 것으로 예상됩니다.

1. 데이터 액세스 레이어

Cells를 제품으로 운영하려면 코드 기반을 Cells 아키텍처를 수용하도록 준비해야 합니다. 이 준비 작업에는 다음이 포함됩니다:

셀 간 데이터 공유 허용
크로스-Cell 데이터 이동을 찾아내기 위한 도구 업데이트
크로스-Cell 데이터 이동에 대한 코드 관행 정의
데이터 소속을 정의하기 위한 데이터 모델 분석

이 목표에 따라 다음 단계가 예상됩니다:

클러스터 전체 데이터를 데이터 액세스 레이어로 공유 허용
Cells는 공유 데이터를 포함하는 데이터베이스에 연결할 수 있습니다. 예를 들어, 응용 프로그램 설정, 사용자 또는 라우팅 정보 등이 있습니다.
데이터베이스 수준 액세스 대 API 지향 액세스 레이어의 효율성 평가
데이터베이스 수준 데이터 액세스가 데이터 이전, 업데이트의 견고성 및 상호 연결된 시스템에 미치는 영향을 재고합니다. 데이터의 부분만 공유하는 경우 데이터베이스 수준 데이터 액세스의 결과를 다시 고려합니다.
클러스터 고유 식별자
모든 객체에는 클러스터 전체 데이터에 액세스하는 데 사용할 수 있는 고유 식별자가 있습니다. 할당된 프로젝트, 이슈 및 기타 객체에 대한 ID는 클러스터 고유입니다.
클러스터 전체 삭제
셀 2에서 삭제된 엔터티가 상호 참조되면, 해당 엔터티는 클러스터 전체에서 올바르게 삭제되거나 무효화됩니다. 우리는 아마도 기존의 루즈 외래 키를 확장하여 크로스-Cell 데이터 제거에 사용할 것으로 예상합니다.
데이터 액세스 레이어
클러스터 전체 데이터를 공유할 수 있는 안정적인 데이터 액세스(버전화됨) 레이어가 구현되었음을 보장합니다.
데이터베이스 마이그레이션
이중 Cells 간에 독립적으로 마이그레이션을 실행할 수 있도록 보장하고, 다른 Cells에 영향을 미치지 않고 공유 데이터의 마이그레이션을 안전하게 처리할 수 있도록 보장합니다.

2. 워크플로우

Cells를 실용적으로 사용하려면 Cells가 베타 품질로 간주되기 전에 핵심 워크플로우를 정의하고 지원해야 합니다. 워크플로우는 제품 대부분을 사용 가능하게 만드는 필수 기능을 대상으로 합니다.

현재 접근 방식은 상위에서 하위로 워크플로우를 정의하는 것입니다. 순서가 항목의 우선순위를 가정하는 것입니다. 이 디렉터리은 기본적인 것들을 수정하는 초기 단계 뒤에 다른 팀이 도와주고 자신들의 워크플로우를 수정하도록 기대하고 있으므로 완전하지 않습니다.

프로젝트를 베타 단계용으로 준비하려면 아래에 정의된 모든 기능이 Cells에서 지원된다고 기대됩니다. 아래 디렉터리에서 워크플로우는 기능에 적절하게 속해 있는 테이블의 집합을 정의합니다. 때로는 모호하게 사용되는 테이블을 분할해야 합니다. 예를 들어 uploads는 사용자 아바타와 댓글에 첨부된 업로드를 저장하기 위해 사용됩니다. uploads가 uploads (그룹/프로젝트 수준 첨부)과 global_uploads (예를 들어 사용자 아바타)로 분할되는 것이 예상됩니다.

그룹::테넌트 스케일이 다른 팀이 Cells와 함께 작동하도록 도울 것으로 예상됩니다. 일반적인 데이터를 어떻게 나눌 것인지 정의하고 필요한 도구 및 개발 지침을 빌드하는 데 2-3분기가 필요합니다.

인스턴스 전체 설정이 클러스터 전체에서 공유됩니다.
대부분의 경우에 대한 관리 영역 섹션이 클러스터 전체에서 공유됩니다.
사용자 계정이 클러스터 전체에서 공유됩니다. ✓
목적은 사용자를 클러스터 전체로 만드는 것입니다.
사용자는 조직을 생성할 수 있습니다.
목적은 서로 격리된 조직을 만드는 것입니다.
사용자는 그룹을 생성할 수 있습니다. ✓ (데모)
목적은 사용자와 네임스페이스를 명확히 분해하여, 네임스페이스가 Cell 내부에 저장되도록 하는 것입니다.
사용자는 프로젝트를 생성할 수 있습니다. ✓ (데모)
목적은 사용자가 프로젝트를 만들 수 있도록 하는 것입니다.
사용자는 README 파일이 포함된 프로젝트를 만들 수 있습니다.
목적은 사용자가 프로젝트에서 README 파일을 생성할 수 있도록 하는 것입니다.
사용자는 클러스터 전체에서 공유되는 프로필 아바타를 변경할 수 있습니다.
목적은 클러스터 전체에서 공유되는 글로벌 업로드를 수정하는 것입니다.
사용자는 Git 리포지터리에 푸시할 수 있습니다.
중요한 조인이 프로젝트 테이블에서 Cell-local로 적절히 속성화되도록 보장합니다. 그 결과로 Git 워크플로우가 지원됩니다.
사용자는 CI 파이프라인을 실행할 수 있습니다.
ci_pipelines (예: ci_stages, ci_builds, ci_job_artifacts) 및 이웃 테이블이 Cell-local로 적절히 속성화되도록 보장합니다.
사용자는 이슈를 만들 수 있습니다.
이슈가 Cell-local로 적절히 속성화되도록 보장합니다.
사용자는 Merge Request을 만들고 초록색으로 Merge할 수 있습니다.
Merge Request이 Cell-local로 적절히 속성화되도록 보장합니다.
사용자는 그룹 및 프로젝트 멤버를 관리할 수 있습니다.
멤버 테이블이 Cell-local이나 클러스터 전체로 적절히 속성화되도록 보장합니다.
사용자는 인스턴스 전체 러너를 관리할 수 있습니다.
모든 CI 러너를 Cell-local로 범위를 지정합니다. 사실상 인스턴스 전체 러너는 Cell-local 러너가 됩니다. 기대치는 클러스터 전체가 아닌 Cell 당 사용자 인터페이스 뷰를 제공하여 모든 러너를 관리하는 것입니다.
사용자는 조직의 일부이며 해당 조직의 정보만 볼 수 있습니다.
각 Cell에 많은 조직이 있지만 한 Cell을 넘어가는 단일 조직은 절대 존재하지 않아야 합니다. 조직 내에서 보이는 정보가 격리되고 다른 Cells에서 정보를 가져오지 않도록 보장해야 합니다.

위의 내용은 팀의 결정에 따라 지원해야 할 수도 있는 다음의 워크플로우입니다. 이 디렉터리은 수행해야 하는 작업을 전부 나열한 것은 아닙니다.

사용자는 그룹 수준 기능을 모두 사용할 수 있습니다.
사용자는 프로젝트 수준 기능을 모두 사용할 수 있습니다.
사용자는 조직에 다른 조직을 공유할 수 있습니다.
사용자는 시스템 웹훅을 생성할 수 있습니다.
사용자는 패키지를 업로드하고 관리할 수 있습니다.
사용자는 보안 탐지 기능을 관리할 수 있습니다.
사용자는 Kubernetes 통합을 관리할 수 있습니다.
미정

Dependencies

다음과 같은 워크플로우 간 의존성을 식별했습니다.

flowchart TD A[조직 생성] --> B[그룹 생성] B --> C[프로젝트 생성] L --> D[이슈 생성] E --> F[Git 리포지터리에 푸시] E --> G[Merge Request 생성] E --> H[CI 파이프라인 생성] G --> J[파이프라인 성공 시 Merge] H --> J J --> K[MR 설명에서 참조로 인한 이슈 닫힘] D --> K A --> L[멤버 관리] B --> L C --> L L --> E[리포지터리에 파일 생성]

3. 라우팅 레이어

Cells: Routing Service를 참조하세요.

4. 인프라

Cell: Infrastructure를 참조하세요.

5. 마이그레이션

프로덕션에 도달하여 새로운 셀에 새로운 조직을 저장할 수 있는 경우, 큰 셀을 여러 개의 작은 셀로 나눌 수 있어야 합니다.

GitLab Geo를 사용하여 셀 복제
GitLab Geo를 사용하여 셀을 복제하는 것이 목적입니다.
셀을 복제하여 셀 분할
한 번 셀이 복제되면 조직을 위한 라우팅 정보를 변경합니다. 조직은 cell_id를 인코딩할 것입니다. cell_id를 업데이트하면 주어진 셀이 해당 조직의 트래픽을 처리하기 위해 권한이 있는 셀이 될 것입니다.
이전 셀에서 중복 데이터 삭제
이제 조직이 여러 셀에 저장되므로 cell_id를 변경하면 organization_id에 기반하여 모든 다른 셀에서 데이터를 삭제해야 할 것으로 예상됩니다.

기능 가용성

Support for Experiment, Beta, and Generally Available features를 따르고 있습니다.

1. 실험

기대:

별도의 도메인(예: cell2.staging.gitlab.com)을 사용하여 스테이징이나 다른 테스트 환경에 셀을 배포할 수 있습니다. 인프라 도구를 사용합니다.
사용자는 조직, 그룹 및 프로젝트를 생성하고 작업흐름 중 일부를 실행할 수 있습니다.
단일 도메인에서 모든 요청을 처리하는 라우터를 실행할 수 있는 것을 기대하지는 않습니다.
추가 셀에 저장된 데이터의 손실이 예상됩니다.
도구를 검증하기 위해 많은 새로운 셀을 생성하는 것이 예상됩니다.

2. 베타

기대:

단일 도메인(예: staging.gitlab.com)에서 많은 셀을 실행할 수 있습니다.
작업흐름에 정의된 모든 기능이 지원됩니다.
라우팅 레이어의 모든 측면이 최종화되지는 않을 것입니다.
추가 셀이 최소한의 데이터 손실과 함께 안정적일 것으로 예상됩니다.

3. 일반 사용 가능

기대:

단일 도메인(예: staging.gitlab.com)에서 많은 셀을 실행할 수 있습니다.
라우팅 레이어의 모든 기능이 지원됩니다.
마이그레이션의 어떤 측면도 지원할 것으로 기대되지는 않습니다.

4. 일반 사용 후

기대:

기존 조직을 새로운 셀로 마이그레이션할 수 있습니다.

반복 계획

전달된 반복은 주어진 주요 작업 스트림의 특정 단계를 해결하는 데 중점을 둘 것입니다. 초기 반복은 데이터 분할을 위해 코드베이스를 준비하는 데 상당히 많은 변경이 필요하기 때문에 초기적으로 진행이 더디게 될 것으로 예상됩니다.

1차 반복 (FY24Q1)

데이터 액세스 레이어: 초기 관리자 영역 설정은 클러스터 전반에 걸쳐 공유됩니다.
작업흐름: 데이터 액세스 레이어를 통해 클러스터 전반에 대해 데이터를 공유할 수 있도록 허용합니다.

2차 반복 (FY24Q2-FY24Q3)

작업흐름: 사용자 계정은 클러스터 전반에 공유됩니다.
작업흐름: 사용자가 그룹을 생성할 수 있습니다.

3차 반복 (FY24Q4-FY25Q1)

작업흐름: 사용자가 프로젝트를 생성할 수 있습니다.
라우팅: 기술.
라우팅: 셀 발견.

4차 반복 (FY25Q1-FY25Q2)

작업흐름: 사용자가 두 번째 셀에서 조직을 생성할 수 있습니다.

5차 반복 이후 - FY25Q3 시작

데이터 액세스 레이어: 클러스터 고유 식별자.
데이터 액세스 레이어: 데이터베이스 수준 데이터 액세스 대 API 지향적 액세스 레이어의 효율성 평가.
데이터 액세스 레이어: 데이터 액세스 레이어.
라우팅: 단일 도메인을 사용하여 많은 셀과 상호작용할 수 있는 사용자.
셀 배포: GCP를 지원하기 위해 GitLab Dedicated 확장.
작업흐름: README 파일이 있는 프로젝트를 생성할 수 있는 사용자.
작업흐름: Git 리포지터리에 푸시할 수 있는 사용자.
작업흐름: CI 파이프라인을 실행할 수 있는 사용자.
작업흐름: 클러스터 전반에 걸쳐 공유되는 인스턴스 설정.
작업흐름: 클러스터 전반에 공유되는 프로필 아바타를 변경할 수 있는 사용자.
작업흐름: 이슈를 생성할 수 있는 사용자.
작업흐름: Merge Request을 생성하고 녹색이 되면 Merge할 수 있는 사용자.
작업흐름: 그룹 및 프로젝트 멤버를 관리할 수 있는 사용자.
작업흐름: 클러스터 전반에 걸쳐 공유되는 인스턴스 러너를 관리할 수 있는 사용자.
작업흐름: 조직의 일부이며 조직에서만 정보를 볼 수 있는 사용자.
라우팅: 라우터 엔드포인트 분류.
라우팅: GraphQL 및 다른 모호한 엔드포인트.
데이터 액세스 레이어: 클러스터 전반에 걸쳐 데이터를 공유할 수 있도록 허용합니다.
데이터 액세스 레이어: 클러스터 전반에 걸쳐 삭제.
데이터 액세스 레이어: 데이터베이스 마이그레이션.

기술 제안

셀 아키텍처는 데이터 처리, 위치, 확장성 및 GitLab 아키텍처에 장기적인 영향을 미칩니다. 이 섹션에서는 평가 중인 모든 다양한 기술 제안에 대한 링크를 제공합니다.

영향을 받는 기능

셀 아키텍처는 많은 기능에 영향을 미칠 것으로 예상되며, 그 중 일부는 다시 쓰이거나 중요한 변경이 필요할 것입니다. 아래는 알려진 영향을 받는 기능과 초기 제안된 솔루션을 포함한 디렉터리입니다.

영향을 받는 기능: 플레이스홀더

다음은 아직 셀(Cell)의 영향을 추정하고 솔루션 제안을 개발해야 하는 플레이스홀더만을 나타낸 디렉터리입니다.

자주 묻는 질문

Cells 아키텍처와 GitLab Dedicated의 차이점은 무엇인가요?

Cells와 Dedicated 간 개별적인 생각과 차이점을 여기에서 확인하실 수 있습니다.

신규 Cells 아키텍처는 GitLab.com을 확장하기 위한 것입니다. 이를 위해 조직을 Cells로 이동함으로써 이를 달성할 수 있지만, 다른 조직은 애플리케이션이 다른 조직에서 격리되도록 제공하지만 여전히 서버 리소스를 공유할 수 있습니다. 그러나 모든 이러한 이들은 여전히 기존의 GitLab SaaS 도메인 이름 gitlab.com 하에서 작동합니다. 또한, Cells는 여전히 사용자 및 그룹 및 프로젝트의 라우팅 정보와 같은 일부 공통 데이터를 공유합니다. 예를 들어, 다른 Cells에 존재하는 서로 다른 조직에 속해 있는 사용자도 동일한 사용자 이름을 가질 수 없습니다.

상기 차이로 인해, GitLab Dedicated는 여전히 Cells에서 사용되는 공유 리소스에 비해 높은 비용으로 제공됩니다. 이로써 GitLab Dedicated는 대형 고객에 보다 적합하고, GitLab Cells는 GitLab.com에서 시작하는 중소 규모의 회사들에 보다 적합합니다.

다른 한편으로, GitLab Dedicated는 어떠한 조직에 대해 완전히 격리된 GitLab 인스턴스를 제공하는 것을 목표로 합니다. 이 인스턴스는 자체 사용자 정의 도메인 이름에서 실행되며, GitLab SaaS를 포함한 다른 GitLab 인스턴스와 완전히 격리됩니다. 예를 들어, GitLab Dedicated의 사용자는 GitLab.com에서 이미 사용 중인 고유한 사용자 이름을 가져야 할 필요가 없습니다.

서로 다른 Cells끼리 어떻게 통신하나요?

반복 3까지, Cells는 공통 데이터를 포함하는 공유 데이터베이스를 통해서만 서로 통신합니다. 반복 4에서는 더 많은 격리와 신뢰성을 제공하기 위해 Cells가 API를 통해 서로 호출하는 옵션을 평가할 예정입니다.

Cells는 어떻게 공급되나요?

GitLab.com의 Cells 클러스터는 GitLab Dedicated 인스턴스를 사용할 것입니다. 한번 GitLab Dedicated 인스턴스가 공급되면 GitLab.com 클러스터에 가입하여 Cell이 될 수 있습니다. 요구 사항 중 하나는 GitLab Dedicated 인스턴스가 이전 데이터를 포함하지 않아야 함입니다.

공유 리소스에 접근하기 위해 Cells는 Private Service Connect를 사용할 것입니다.

또한, 디자인 논의도 참조하세요.

Cells 토폴로지란 무엇인가요?

디자인 논의도 참조하세요.

::EndTabs::