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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality 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에 대한 자세한 정보는 아래를 참조하세요:

셀 단계

  • 셀 1.0의 목표는 SaaS GitLab.com 오퍼링을 사용하는 신규 엔터프라이즈 고객을 위한 솔루션을 제공하는 것입니다.
  • 셀 1.5의 목표는 기존의 엔터프라이즈 고객을 위한 마이그레이션 솔루션을 제공하는 것입니다. 이는 Cells 1.0 아키텍처를 기반으로 구축됩니다.
  • 셀 2.0의 목표는 셀러 아키텍처에서 공개 및 오픈 소스 기여 모델을 지원하는 것입니다.

목표

목표, 용어 및 요구 사항 참조

작업 스트림

전체 Cells 아키텍처를 한 번에 출시할 수는 없습니다. 그것은 너무 큽니다. 대신, 프로젝트에 필요한 주요 작업 스트림을 정의하고 있습니다. 각 작업 스트림마다 기능을 Cell 1.0, Cell 1.5 및 Cell 2.0과 대응시키기 위한 노력을 정의해야 합니다.

일반 가용성(GA)에는 몇 가지 목표가 완료되지 않을 것으로 예상되지만, Cells를 본격적으로 운영할 수 있을 것입니다.

1. 데이터 액세스 레이어

Cells를 본격적으로 운영하려면 코드베이스를 Cells 아키텍처를 수용할 수 있도록 준비해야 합니다. 이 준비 작업에는 다음이 포함됩니다:

  • Cells 간 데이터 공유 허용
  • 크로스-Cell 데이터 이동을 발견하기 위한 도구 업데이트
  • 크로스-Cell 데이터 이동을 위한 코드 관행 정의
  • 데이터 모델 분석을 통한 데이터 친화성 정의

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

  1. 데이터베이스 수준 데이터 액세스 레이어를 사용하여 클러스터 전반에 데이터 공유를 허용합니다.

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

  2. 데이터베이스 수준 액세스 대 API-지향 액세스 레이어의 효율성을 평가합니다.

    데이터베이스 수준 데이터 액세스의 결과를 재고하며, 데이터 이주, 업데이트의 탄력성 및 교차 시스템을 고려합니다. 우리가 데이터 일부분만 공유할 때 데이터베이스 수준 액세스의 결과를 다시 고려합니다.

  3. 클러스터 고유 식별자

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

  4. 클러스터 전반의 삭제

    셀 2에서 삭제된 엔터티가 상호 참조되면, 클러스터 전반에서 제대로 삭제되거나 무효화됩니다. 우리는 아마도 기존의 느슨한 외부 키를 공유 데이터의 교차-Cells 데이터 제거로 확장하기 위해 재사용할 것입니다.

  5. 데이터 액세스 레이어

    클러스터 전반 데이터를 공유할 수 있는 안정적인 데이터 액세스(버전화) 레이어가 구현되었는지 확인합니다.

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

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

2. 워크플로우

Cells를 유효하게 만들기 위해, Cells가 베타 품질로 간주되기 전에 기본적인 워크플로우를 정의하고 지원해야 합니다. 워크플로우는 대부분의 응용 프로그램 기능을 포괄하여 제품을 대부분 사용 가능하게 만들지만, 일부 주의 사항이 있습니다.

현재 접근 방식은 상위에서 하위로 워크플로우를 정의하는 것입니다. 순서는 항목의 우선 순위를 예상하는 데 사용됩니다. 이 목록은 초기 단계 후에 다른 팀이 도움을 받고 기본 워크플로우를 수정하는 것으로 예상되므로 모든 기능이 가정된 후 베타 단계용 프로젝트를 고려할 때 지원되어야 합니다.

잠재적으로 필요한 일부 워크플로우는 그룹의 결정에 따라 지원되어야 합니다. 이 목록은 해야 할 일의 범주적인 목록이며, 모든 워크플로우를 수행하기 위한 예상 시간은 2-3분입니다.

-…

Dependencies

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

flowchart TD A[조직 생성] --> B[그룹 생성] B --> C[프로젝트 생성] L --> D[이슈 생성] E --> F[Git 저장소로 푸시] E --> G[병합 요청 생성] E --> H[CI 파이프라인 생성] G --> J[파이프라인 성공 시 병합] H --> J J --> K[MR 설명에 언급된 참조에 따라 이슈가 닫힘] D --> K A --> L[멤버 관리] B --> L C --> L L --> E[저장소에 파일 생성]

3. 라우팅 레이어

셀: 라우팅 서비스를 참조하세요.

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. GA

기대:

  • 하나의 도메인 아래에서 여러 셀을 실행할 수 있습니다(예: staging.gitlab.com)..
  • 라우팅 레이어의 모든 기능을 지원할 수 있습니다.
  • 마이그레이션의 어떠한 측면도 지원할 것으로 기대되지 않습니다.

4. GA 이후

기대:

반복 계획

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

반복 1 (FY24Q1)

  • 데이터 액세스 레이어: 초기 관리 영역 설정을 클러스터 전체에서 공유합니다.
  • 워크플로: 데이터베이스 수준 데이터 액세스 레이어로 클러스터 전체 데이터 공유를 허용합니다.

반복 2 (FY24Q2-FY24Q3)

  • 워크플로: 사용자 계정을 클러스터 전체에서 공유합니다.
  • 워크플로: 사용자가 그룹을 만들 수 있습니다.

반복 3 (FY24Q4-FY25Q1)

  • 워크플로: 사용자가 프로젝트를 만들 수 있습니다.
  • 라우팅: 기술.
  • 라우팅: 셀 검색.

반복 4 (FY25Q1-FY25Q2)

  • 워크플로: 사용자가 두 번째 셀에 조직을 만들 수 있습니다.

반복 5..N - FY25Q3 시작

  • 데이터 액세스 레이어: 클러스터 고유 식별자.
  • 데이터 액세스 레이어: 데이터베이스 수준 액세스 대 API 지향 액세스 레이어의 효율성을 평가합니다.
  • 데이터 액세스 레이어: 데이터 액세스 레이어.
  • 라우팅: 사용자가 많은 셀과 상호 작용하는 데 단일 도메인을 사용할 수 있습니다.
  • 셀 배포: GCP를 지원하는 GitLab Dedicated를 확장합니다.
  • 워크플로: 사용자가 README 파일이 있는 프로젝트를 만들 수 있습니다.
  • 워크플로: 사용자가 Git 저장소에 푸시할 수 있습니다.
  • 워크플로: 사용자가 CI 파이프라인을 실행할 수 있습니다.
  • 워크플로: 클러스터 전체에서 설정을 공유할 수 있습니다.
  • 워크플로: 클러스터 내 실행중인 러너를 관리할 수 있습니다.
  • 워크플로: 사용자는 조직의 구성원이며 조직에서만 정보를 볼 수 있습니다.
  • 라우팅: 라우터 엔드포인트 분류.
  • 라우팅: GraphQL 및 다른 모호한 엔드포인트.
  • 데이터 액세스 레이어: 클러스터 전체 데이터베이스 삭제를 허용합니다.
  • 데이터 액세스 레이어: 데이터베이스 마이그레이션.

기술 제안서

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

영향을 받는 기능

Cells 아키텍처는 다수의 기능에 영향을 미칠 것으로 예상되며, 그 중 일부는 다시 작성하거나 중요한 변경이 필요할 것입니다. 아래는 알려진 영향을 받는 기능 목록 및 예비 제안된 해결책입니다.

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

다음은 아직 Cells의 영향과 해결책을 추정하기 위해 작업이 필요한 영향을 받는 기능 목록입니다.

자주 묻는 질문

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는 어떻게 프로비저닝되나요?

GitLab.com의 Cells 클러스터는 GitLab Dedicated 인스턴스를 사용할 것입니다. 한 번 GitLab Dedicated 인스턴스가 프로비저닝되면 GitLab.com 클러스터에 참여하여 Cell이 될 수 있습니다. 요구 사항 중 하나는 GitLab Dedicated 인스턴스에 이전 데이터가 없어야 합니다.

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

또한 디자인 토론도 참조하세요.

셀(커널) 토폴로지란 무엇인가요?

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

조직의 사용자가 올바른 셀로 라우팅되는 방법은 무엇인가요?

TBD

사용자는 어떻게 셀과 조직에 인증하나요?

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

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

TBD

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

TBD

기능을 클러스터, 셀 또는 조직 수준으로 이동할지 결정하는 방법은 무엇인가요?

기본적으로, 기능은 조직 수준에 범위가 지정되어야 합니다. 해당 규칙에서의 어떠한 편차는 Tenant Scale에 의해 확인되고 승인되어야 합니다.

셀 아키텍처의 디자인 목표는 모든 셀이 단일 gitlab.com 도메인 아래에 있는 것으로 설명되며, 따라서 셀은 사용자에게는 보이지 않습니다:

  • 셀 지역 기능은 셀을 관리하는데 관련된 것으로 제한되어야 하며, 이 과정에서 고객에게 셀 의미가 노출되어서는 안 됩니다.
  • 셀 아키텍처는 데이터가 마이그레이션될 때 사용자에게 영향을 미치지 않는다는 점에서 조직 및 고객 데이터의 분산을 자유롭게 제어하려고 합니다.

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

  • 이는 확장 가능성 여유 공간을 제공하게 하는 핵심적인 양의 데이터를 클러스터 전체로 저장할 수 있음을 요구할 수 있습니다.
  • 단일 노드 장애에 대한 고객 경험에 대한 관성을 감소시키는 비단순한 데이터 집계의 구현을 요구할 수 있습니다.
  • 혼합 배포 실행이 가능해야 한다는 요구 때문에 구축하기가 더 어려울 수 있습니다. 클러스터 전체 기능은 이를 고려해야 합니다.
  • 이는 GitLab.com에서 온프레미스와 유사한 경험을 제공하는 능력에 영향을 미칠 수 있습니다.
  • 클러스터 전체로 예상되는 일부 기능은 실제로 동일한 사용자 ID를 사용하여 신뢰된 클러스터 내 통신을 사용하는 피더레이션 기술을 사용하여 더 나은 방식으로 구현하는 것이 더 나을 수 있습니다. 사용자 프로필은 클러스터 전체에서 공유됩니다.
  • 셀 아키텍처는 어떠한 서비스가 클러스터 전체로 간주될 수 있는지를 제한합니다. 초기에 클러스터 전체로 예상되는 서비스는 미래에 완전한 서비스 격리를 달성하기 위해 여전히 분할되어야 한다는 점을 고려해야 합니다. 어떠한 기능도 그러한 서비스(예: Elasticsearch)에 의존하여 구축해서는 안 됩니다.

셀은 50000명의 사용자에 대한 참조 아키텍처를 사용할 것인가요?

인프라 팀은 부하에 따라 셀을 적절하게 크기 조정할 것입니다. Tenant Scale 팀은 Cells 배포의 기본으로 GitLab Dedicated를 사용할 가능성을 엿봅니다.

결정 기록

링크