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에 대한 자세한 정보는 다음을 참조하세요:

Cells 반복

  • Cells 1.0의 목표는 SaaS GitLab.com 제공을 사용하는 내부 고객을 위한 솔루션을 제공하고 Cells의 기초 작업을 하는 것입니다.
  • 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 아키텍처를 수용할 수 있도록 준비해야 합니다. 이 준비에는 다음이 포함됩니다.

  • Cells 간 데이터 공유 허용
  • Cross-Cell 데이터 이동을 위한 도구 업데이트
  • Cross-Cell 데이터 이동을 위한 코드 관행 정의
  • 데이터 모델 분석 및 데이터 친화성 정의

이 목적 아래에서는 다음 단계가 예상됩니다.

  1. 데이터베이스 수준의 데이터 접근 레이어로 클러스터 전체 데이터 공유 허용

    Cells는 공유 데이터가 포함된 데이터베이스에 연결할 수 있습니다. 예: 애플리케이션 설정, 사용자 또는 라우팅 정보.

  2. 데이터베이스 수준 액세스 대 API 중심 액세스 레이어의 효율성 평가

    데이터베이스 수준 데이터 액세스의 결과를 재고하여 데이터 마이그레이션, 업데이트의 탄력성 및 기타 시스템 상호 연결성에 대해 다음과 같이 데이터의 일부만 공유할 때의 결과를 다시 검토합니다.

  3. 클러스터 고유 식별자

    모든 객체에는 클러스터 전체 데이터에 액세스하는 데 사용할 수 있는 고유 식별자가 있습니다. 할당된 프로젝트, 이슈 및 기타 객체의 ID는 클러스터에 고유합니다.

  4. 클러스터 전체 삭제

    Cell 2에서 삭제된 엔터티가 교참 참조되어 있으면, 해당 엔티티는 클러스터 전체에서 적절하게 삭제 또는 무효화됩니다. 우리는 아마도 기존의 [연결 느슨한 외부 키]를 재사용하여 cross-Cells 데이터 제거를 확장시킬 것입니다.

  5. 데이터 액세스 레이어

    클러스터 전체 데이터를 공유할 수 있는 안정적인 데이터 액세스(버전별) 레이어가 구현되었는지 확인하세요.

  6. 데이터베이스 마이그레이션

    Cells 간에 마이그레이션을 독립적으로 실행할 수 있도록 하고, 다른 Cells에 영향을 주지 않고 공유 데이터의 마이그레이션을 안전하게 처리할 수 있도록 합니다.

2. 워크플로우

Cells를 실용적으로 만들기 위해서는 Cells의 베타 품질로 인정하기 전에 중요한 워크플로우를 정의하고 지원해야 합니다. 워크플로우는 제품을 대부분 사용 가능하게하는 기능을 커버할 목적으로 합니다.

현재 접근 방식은 상위에서 하위로 워크플로우를 정의하는 것입니다. 순서는 항목의 우선 순위를 가정한 것입니다. 이 디렉터리은 기본적으로 제공되는 항목들을 수정한 초기 단계 이후에 다른 팀이 도움을 요청할 것으로 예상하므로 이 디렉터리은 전체적으로 완전하지 않습니다.

프로젝트를 베타 단계로 준비하는 것은 아래에 정의된 모든 기능이 Cells에서 지원되는 것으로 예상됩니다. 아래 디렉터리에서 케이스가 언급된 경우, 워크플로우는 특정 기능에 적절하게 할당되는 일련의 테이블을 정의합니다. 일부 경우에는 애매한 사용법을 가진 테이블을 분해해야 합니다. 예: uploads는 사용자 아바타와 댓글에 첨부된 업로드를 저장하는 데 사용됩니다. uploads가 uploads (그룹/프로젝트 수준 첨부 파일 설명) 및 global_uploads (예: 사용자 아바타)로 분리되어야 합니다.

그룹::테넌트 규모는 다른 팀이 Cells와 작동하도록 기능 세트를 수정하는 데 도움이 될 것으로 예상됩니다. 일반적인 데이터의 분할을 정의하고 필요한 도구 및 개발 지침을 구축하는 데 2-3분기가 필요합니다.

  1. 인스턴스 전역 설정이 클러스터 전체로 공유됩니다.

    다수의 관리자 영역은 클러스터 전체로 공유됩니다.

  2. 사용자 계정이 클러스터 전체로 공유됩니다. ✓

    목적은 사용자를 클러스터 전체로 만드는 것입니다.

  3. 사용자는 조직을 만들 수 있습니다.

    목적은 서로 격리된 조직을 만드는 것입니다.

  4. 사용자는 그룹을 만들 수 있습니다. ✓ (데모)

    목적은 사용자와 네임스페이스를 명시적으로 분해하는 것으로, 네임스페이스가 Cell 내에서 로컬로 저장될 것으로 예상됩니다.

  5. 사용자는 프로젝트를 만들 수 있습니다. ✓ (데모)

    목적은 사용자가 프로젝트를 만드는 것으로, 프로젝트가 Cell 내에서 로컬로 저장될 것으로 예상됩니다.

… (이하 생략)

의존성

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

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. 라우팅 레이어

HTTP 라우팅에 대해 셀: 라우팅 서비스를 참조하십시오.

SSH 라우팅에 대해 셀: SSH 라우팅 서비스를 참조하십시오.

4. 인프라

셀: 인프라를 참조하십시오.

5. 마이그레이션

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

  1. GitLab Geo를 사용하여 셀을 복제합니다.

    목적은 GitLab Geo를 사용하여 셀을 복제하는 것입니다.

  2. 셀을 복제하여 셀을 분할합니다.

    한 셀이 복제되면 조직을 위한 라우팅 정보를 변경합니다. 조직은 cell_id를 인코딩할 것입니다. cell_id를 업데이트하면 주어진 셀이 해당 조직의 트래픽을 처리하기 위해 자동적으로 권한이 부여될 것입니다.

  3. 이전 셀로부터 중복 데이터를 삭제합니다.

    이제 조직이 여러 셀에 저장되기 때문에, cell_id를 업데이트하면 organization_id에 기반하여 다른 모든 셀에서 데이터를 제거해야 할 것으로 예상됩니다.

기능의 가용성

실험, 베타 및 일반적으로 사용 가능한 기능 지원을 준수하고 있습니다.

1. 실험

기대 사항:

  • 별도의 도메인(예: cell2.staging.gitlab.com)을 사용하여 스테이징이나 다른 테스트 환경에 셀을 배포할 수 있습니다(인프라 도구를 사용).
  • 사용자는 워크플로우를 실행하여 조직, 그룹 및 프로젝트를 생성할 수 있습니다.
  • 모든 요청을 단일 도메인 아래로 제공하는 라우터를 실행할 수 없을 것으로 예상됩니다.
  • 추가 셀에 저장된 데이터의 손실이 예상됩니다.
  • 검증 도구를 검증하기 위해 많은 새로운 셀을 철거하고 생성할 것으로 예상됩니다.

2. 베타

기대 사항:

  • 단일 도메인(예: staging.gitlab.com) 아래에서 여러 셀을 실행할 수 있을 것으로 예상됩니다.
  • 워크플로우에 정의된 모든 기능이 지원될 것으로 예상됩니다.
  • 라우팅 레이어의 모든 측면이 최종화되지 않을 것으로 예상됩니다.
  • 추가적인 셀들이 데이터 손실을 최소화하며 안정적일 것으로 예상됩니다.

3. 일반 사용 가능

기대 사항:

  • 단일 도메인(예: staging.gitlab.com) 아래에서 여러 셀을 실행할 수 있을 것으로 예상됩니다.
  • 라우팅 레이어의 모든 기능이 지원될 것으로 예상됩니다.
  • 마이그레이션 부분 중 어떤 부분도 지원할 것으로 기대되지 않을 것입니다.

4. 일반 사용 가능 이후

기대 사항:

  • 기존 조직을 새로운 셀로 마이그레이션할 수 있을 것으로 예상됩니다.

기술 제안

셀 아키텍처는 데이터 처리, 위치, 확장성 및 GitLab 아키텍처에 장기적인 영향을 미칩니다. 이 섹션은 현재 평가 중인 다양한 기술 제안을 모두 연결합니다.

영향을 받는 기능

셀 아키텍처는 많은 기능에 영향을 미치며 이 중 일부는 재작성하여 변경해야 합니다. 다음은 사전 제안된 솔루션과 함께 알려진 영향을 받는 기능의 디렉터리입니다.

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

다음은 작업을 추정하고 셀에 대한 영향을 평가하기 위해 작업이 필요한 플레이스홀더 디렉터리입니다.

셀의 토폴로지란 무엇인가요?

디자인 토론을 참조하세요.

조직 사용자는 올바른 셀로 라우팅되나요?

미정

사용자는 어떻게 셀과 조직을 통해 인증을 받나요?

디자인 토론을 참조하세요.

셀은 어떻게 리밸런스되나요?

미정

셀은 재해 복구 기능을 어떻게 구현할 수 있나요?

미정

기능을 클러스터, 셀 또는 조직 수준으로 이동해야 할지 어떻게 결정하나요?

기본적으로 기능은 조직 수준으로 범위가 지정되어야 합니다. 그 규칙에서의 어떠한 이탈도 테넌트 스케일(Tenant Scale)에서 검증되고 승인되어야 합니다.

셀 아키텍처의 디자인 목표에 따르면 모든 셀이 단일한 gitlab.com 도메인 아래에 있으며, 그러므로 셀은 사용자에게는 보이지 않아야 합니다:

  • 셀 내부 기능은 셀을 관리하는 데 관련된 것으로 제한되어야 하지만, 결코 셀 의미가 고객에게 노출되는 기능으로서는 안 됩니다.
  • 셀 아키텍처는 데이터가 이동될 때 사용자에게 영향을 미치지 않는 상태로 조직 및 고객 데이터를 셀 간 자유롭게 제어하고자 합니다.

클러스터 전체 기능은 강력히 권장되지 않습니다. 왜냐하면:

  • 해당 기능은 클러스터 전체에 상당량의 데이터를 저장해야 하므로 확장 가능성 여유 공간이 감소합니다.
  • 해당 기능은 비트단위 데이터 집계를 요구할 수 있으며, 이는 단일 노드 장애에 대한 내구성을 감소시킵니다.
  • 기능을 빌드하는 데 더 어려울 수 있습니다. 클러스터 전체 기능은 혼합 배포를 실행할 수 있어야 한다는 요구 때문에 고려해야 합니다.
  • 이는 GitLab.com에서 온프레미스와 유사한 경험을 제공하는 능력에 영향을 줄 수 있습니다.
  • 클러스터 전체로 예상되는 기능 중 일부는 사용자 ID를 사용하여 신뢰할 수 있는 클러스터 내 통신을 이용한 집계 기술을 사용하여 더 잘 구현될 수 있습니다. 예를 들어, 사용자 프로필은 클러스터 전체에서 공유됩니다.
  • 셀 아키텍처는 어떤 서비스가 클러스터 전체로 간주될 수 있는지 제한합니다. 초기에 클러스터 전체로 간주되는 서비스도 미래에 완전한 서비스 격리를 달성하기 위해 분할되어야 할 것으로 예상됩니다. 이러한 서비스에 의존해야 하는 기능을 구축해서는 안 됩니다(예: Elasticsearch).

셀에서는 최대 1000 RPS 또는 50,000 사용자를 위한 참조 아키텍처를 사용할까요?

인프라팀은 부하에 따라 셀의 적절한 크기를 결정할 것입니다. 테넌트 스케일(Tenant Scale) 팀은 셀 배포의 기본으로 GitLab Dedicated를 활용하고자 합니다.

결정 로그

링크