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 -

Cells 1.0

이 문서는 Cells 1.0에 대한 기술 제안을 설명합니다.

Cells 1.0은 세포 구조의 첫 번째 반복입니다. Cells 1.0의 목표는 SaaS GitLab.com 제공을 사용하는 새로운 기업 고객을 위한 솔루션을 제공하는 것입니다.

Cells 1.0은 GitLab.com SaaS에 배포될 수 있는 완전한 기능입니다.

Cells 1.5에 대해 자세히 알아보세요. 이는 기존 고객을 이주할 수 있는 매커니즘을 제공하기 위해 Cells 1.0 아키텍처를 기반으로 만들어졌습니다.

Cells 2.0에 대해 자세히 알아보세요. 이는 세포 구조에서 공개 및 오픈 소스 기여 모델을 지원하기 위한 것입니다.

서문

Cells 1.0은 다음과 같은 기대 사항을 가진 기업 고객을 대상으로 합니다:

  1. 우리의 다중 테넌트 SaaS 솔루션(GitLab.com)을 사용하여 자신의 조직을 서비스하려고 합니다.
  2. GitLab이 보안 릴리스를 진행할 때, 배포 팀은 모든 셀이 보안 릴리스 버전을 실행한 후 릴리스를 공개하기 전에 프로덕션이 된다는 것을 받아들입니다. 이는 보안 릴리스 이외의 경우에 모든 셀이 GitLab의 동일한 버전을 실행한다는 의미는 아닙니다. 자세한 내용은 이 비공개 토론을 참조하세요.
  3. 시스템의 나머지 부분과 분리된 환경을 사용하기를 원합니다.
  4. 자신의 조직에 기여하는 모든 사용자를 제어하기를 원합니다.
  5. 그룹 및 프로젝트가 비공개여야 하며 공개되어서는 안 됩니다.
  6. 사용자는 다른 조직과 상호 작용할 필요가 없어야 합니다.
  7. 사용자는 자신의 계정으로 다른 기관에 전환할 수 없어도 괜찮습니다.

개발 및 인프라 관점에서 다음 목표를 달성하려고 합니다:

  1. 모든 Cells는 단일 도메인에서 접근 가능해야 합니다.
  2. Cells는 대부분 독립적이며 최소한의 데이터 공유가 필요합니다. 모든 상태 데이터가 분리되어 있으며 초기에는 최소한의 데이터 공유가 필요합니다. 이는 모든 데이터베이스 및 클라우드 리포지터리 버킷을 포함합니다.
  3. Cells는 다른 버전으로 독립적으로 실행할 수 있어야 합니다.
  4. 궁극적으로 클러스터 전체 데이터 공유를 허용하는 아키텍처가 필요합니다.
  5. 견고하지만 간단한 라우팅 솔루션이 필요합니다.
  6. 모든 식별자(기본 키, 사용자, 그룹 및 프로젝트 이름)는 클러스터 전체에서 고유해야 하므로 나중에 논리적 재분배를 수행할 수 있습니다. 이는 gitlab_internal, 또는 gitlab_shared 스키마를 사용하지 않는 모든 데이터베이스 테이블을 포함합니다.
  7. 모든 사용자 및 그룹이 클러스터 전체에서 고유하기 때문에 동일한 사용자가 Cells 2.0에서 GitLab.com의 다른 기관 및 그룹에 액세스할 수 있어야 합니다.
  8. Cells를 관리하고 업그레이드하는 데 비용이 최소화되어야 하며 이는 GitLab Dedicate 인스턴스를 관리하는 것과 유사해야 합니다. Secondary Cells는 운영 부담이 선형적으로 증가해서는 안 됩니다.
  9. Cell은 GitLab Dedicated를 관리하는 것과 동일한 도구를 사용하여 배포되어야 합니다.

이 제안은 가능한 한 많은 범위를 충족하도록 설계되었지만 다음 장기적인 목표를 불가능하게 해서는 안 됩니다:

  1. 사용자가 여러 기관과 상호 작용할 수 있어야 합니다.
  2. Cells는 조직을 셀 간 이동하여 재균형할 수 있어야 합니다.
  3. 라우팅 솔루션이 동적으로 고객을 라우팅할 수 있어야 합니다.

제안서

다음 문장들은 Cells 1.0을 달성하기 위한 고수준 제안을 설명합니다:

  1. 사용된 용어:

    1. Primary Cell: 현재의 GitLab.com 배포. 이 아키텍처에서 클러스터 전체 서비스를 제공하는 특수 목적의 셀입니다.
    2. Secondary Cells: 클러스터 전체 고유성을 보장하기 위해 Primary Cell에 연결되는 셀입니다.

  2. 기관 속성:

    1. 우리는 고객이 Secondary Cell에서 새로운 조직을 만들 수 있도록 허용합니다. 선택된 Cell은 GitLab 관리자에 의해 제어됩니다.
    2. 조직은 비공개이며 공개될 수 없습니다.
    3. 그룹 및 프로젝트는 비공개가 될 수 있지만 공개가 될 수 없습니다.

  3. 사용자 속성:

    1. 사용자는 조직을 포함하는 Cell에 생성됩니다.
    2. 사용자는 조직 내비게이션을 제공받지만 단일 조직의 일부가 될 수 있습니다.
    3. 사용자는 다른 조직에 가입하거나 상호 작용할 수 없습니다.
    4. 사용자 계정은 셀 간에 마이그레이션될 수 없습니다.
    5. 사용자의 개인 네임스페이스는 해당 조직에 생성됩니다.

다음 문장들은 위의 목표를 달성하기 위한 저수준 개발 제안을 설명합니다:

  1. 응용 프로그램 속성:

    1. 응용 프로그램에 의해 생성된 각 비밀 토큰(개인 액세스 토큰, 빌드 토큰, 러너 토큰 등)은 Cell을 나타내는 고유 식별자를 포함합니다. 예를 들어 us0입니다. 이 식별자는 Cell에 대한 정보를 가리키도록 안전하게 만들어져야 합니다.
    2. 클라이언트로 전송된 세션 쿠키는 Cell을 나타내는 고유 식별자로 시작해야 합니다. 예를 들어 us0입니다.
    3. 응용 프로그램 구성에는 Cell 비밀 프리픽스 및 Primary Cell에 대한 정보가 포함됩니다.
    4. 사용자는 항상 사용자가 생성된 셀에 로그인합니다.

  2. 데이터베이스 속성:

    1. 데이터베이스의 각 기본 키는 클러스터 전체에서 고유해야 합니다. 우리는 Primary Cell에서 할당된 데이터베이스 시퀀스를 사용합니다.
    2. 각 테이블이 클러스터 전체 또는 Cell 내에서 로컬인지를 분류해야 합니다.
    3. 우리는 최종 일관성 모델을 따라야 합니다:
      1. 모든 클러스터 전체 테이블은 셀 내부 데이터베이스에 저장됩니다.
        1. 클러스터 전체 테이블은 전체 클러스터에서 고유 제약 사항을 유지합니다.
      2. 지역적으로 저장된 클러스터 전체 테이블은 해당 Cell에서만 필요한 정보를 포함합니다. 단, Primary Cell인 경우를 제외합니다.
      3. 클러스터 전체 테이블은 해당 레코드의 권한 소유 Cell에 의해서만 수정할 수 있습니다:
        1. 사용자 레코드는 이 레코드의 권한 소유 Cell인 경우에만 특정 Cell에 의해 수정될 수 있습니다.
        2. Cells 1.0에서는 클러스터 간 데이터를 복제하지 않는 경우가 많으므로 권한 소유 Cell이 레코드를 포함하는 Cell인 경우에만 수정됩니다.
    4. Primary Cell은 고유 제약 조건(ID 또는 사용자, 그룹, 프로젝트 고유성)에 대한 진실로부터 지속적으로 단일 정보 원천 역할을 합니다.
      1. Secondary Cells는 사용자 이름, 그룹 또는 프로젝트를 요청하는 API를 사용합니다.
      2. Primary Cell에는 모든 사용자 이름, 그룹 및 프로젝트에 대한 정보와 레코드 보유 Cell에 대한 정보가 포함됩니다.
      3. Primary Cell은 실제 사용자 또는 프로젝트 레코드가 아닌 해당 정보가 저장된 Cell을 나타내는 참조만 보유합니다.

  3. 라우팅 속성:

    1. 우리는 접두사에 기반한 비밀 라우팅을 수행하는 정적 라우팅 서비스를 구현합니다.
    2. 라우팅 서비스는 Cloudflare Worker로 구현되며 에지에서 실행됩니다. 라우팅 서비스는 정적 셀 디렉터리과 각 셀을 설명하는 프록시 URL 및 접두사로 실행됩니다.
    3. Cells는 공개 인터넷에 노출되지만 Zero Trust로 보호될 수 있습니다.

아키텍처 개요

API 개요

문제

다음 기술적 문제들을 해결해야 합니다:

  1. 모든 비밀은 간단한 라우팅 레이어에서 비밀 기반 라우팅을 수행하기 위해 접두어가 붙습니다.
  2. 모든 사용자 이름, 조직, 최상위 그룹(결과적으로 그룹 및 프로젝트)은 클러스터 전체에서 고유해야 합니다.
  3. 모든 기본 키 식별자는 클러스터 전체에서 고유해야 합니다.

GitLab 구성

gitlab.yml의 GitLab 구성은 다음 매개변수로 확장됩니다. 

production:
  gitlab:
    primary_cell:
      url: https://cell1.gitlab.com
      token: abcdef
    secrets_prefix: kPptz
  1. primary_cell:는 Secondary Cells에서 구성되며, 기본 셀 API에 액세스하기 위한 URL 엔드포인트를 나타냅니다.
  2. secrets_prefix:는 모든 셀에서 사용할 수 있으며, 각 비밀 및 세션 쿠키가이 식별자로 접두어가 있는지를 나타냅니다.

기본 셀

기본 셀은 클러스터의 고유성을 보장하기 위한 특별한 목적을 제공합니다. 기본 셀은 보조 셀에서 사용할 API 인터페이스 세트를 노출합니다. 이 API는 내부용으로 간주되며, 보조 셀과 공유되는 비밀로 보호됩니다.

  1. POST /api/v4/internal/cells/database/claim

    1. 요청:
      • table: 할당된 시퀀스의 테이블 이름, 예: projects
      • count: 고유하게 보장된 ID의 수, 예: 100_000
    2. 응답:
      • start: 시작 시퀀스 값
      • limit: 허용된 최대 시퀀스 값

  2. POST /api/v4/internal/cells/routes

    1. 요청:
      • path: 자원의 전체 경로, 예: my-company/my-project
      • source_type: 자원을 보유한 컨테이너의 클래스 이름, 예: project
      • source_id: 자원을 보유한 컨테이너의 소스 ID, 예: 1000
      • namespace_id: 자원과 관련된 기본 네임스페이스, 예: 32
      • name: 자원의 표시 이름
      • cell_id: 자원을 보유한 셀의 식별자
    2. 응답:
      • 201: 생성됨: 자원이 생성되었습니다.
        • id:: 기본 셀에 저장된 리소스의 ID입니다.
      • 409: 충돌: 리소스가 이미 있습니다.
    3. 동작:
      1. 엔드포인트는 id를 반환합니다. 동일한 ID를 호출하는 셀의 routes 테이블에 레코드를 삽입하는 데 사용해야 합니다.

  3. GET /api/v4/internal/cells/routes/:id

    1. 요청:
      • id: 리소스 식별자
    2. 응답:
      • 200: OK: 리소스가 찾았습니다. 응답 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하세요.
      • 404: 찾을 수 없음: 리소스가 존재하지 않습니다.

  4. PUT /api/v4/internal/cells/routes/:id

    1. 요청: 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하세요.
    2. 응답:
      • 200: OK: 리소스가 업데이트되었습니다.
      • 403: 금지됨: cell_id가 다른 곳에 속해 있기 때문에 리소스를 수정할 수 없습니다.
      • 404: 찾을 수 없음: 리소스가 존재하지 않습니다.
      • 409: 충돌: path에 대한 고유성 제약 조건이 실패했습니다.
    3. 동작:
      1. 엔드포인트는 지정된 cell_id와 일치하는 리소스를 수정합니다.

  5. DELETE /api/v4/internal/cells/routes/:id

    1. 요청: 매개변수는 POST /api/v4/internal/cells/routes 요청 매개변수를 참조하세요.
    2. 응답:
      • 200: OK: 지정된 매개변수를 가진 리소스가 성공적으로 삭제되었습니다.
      • 404: 찾을 수 없음: 지정된 리소스를 찾을 수 없습니다.
      • 400: 잘못된 요청: 리소스가 삭제되지 못했습니다.
  6. POST /api/v4/internal/cells/redirect_routes
  7. GET /api/v4/internal/cells/redirect_routes/:id
  8. PUT /api/v4/internal/cells/redirect_routes/:id
  9. DELETE /api/v4/internal/cells/redirect_routes/:id

보조 셀

현재 보조 셀은 특정 API를 노출하지 않습니다. 보조 셀은 주 데이터베이스 키의 고유성을 보장하는 솔루션을 구현합니다.

  1. ReplenishDatabaseSequencesWorker: 이 워커는 주기적으로 모든 시퀀스를 확인하고 보충합니다.

데이터베이스 시퀀스의 간단한 고유성

데이터베이스 시퀀스의 간단한 고유성은 테이블에 대해 클러스터 전체에서 고유한 범위의 ID를 요구, 사용 및 보충하는 방식을 참조합니다.

저희의 DDL 스키마는 다음 형식의 ID 생성을 사용합니다: id bigint DEFAULT nextval('product_analytics_events_experimental_id_seq'::regclass) NOT NULL.

/api/v4/internal/cells/database/claim는 아래 논리를 실행하여 ID 범위를 원자적으로 요청합니다. 

def claim_table_seq(table, count)
  sql = <<-SQL
    BEGIN;
      -- `ALTER SEQUENCE`는 실제로 `some_seq`를 쓰기 및 읽기 위해 잠그게 합니다.
      ALTER SEQUENCE seq_name INCREMENT BY 1000;
      SELECT nextval(seq_name); -- 이 결과는 1001일 것입니다.
      ALTER SEQUENCE seq_name INCREMENT BY 1; -- "INCREMENT BY 1000"을 DESCREASE합니다.
      
      INSERT INTO cells_sequence_claims (cell_id, table_name, start_id, end_id)
        VALUES (cell_id, table_name, 2, 1001);
    COMMIT;
  SQL
  
  seq_name = "#{table}_id_seq"
  last_id = select_one(sql, seq_name, limit, seq_name, seq_name).first
  { start: last_id - count, limit: count }
end

사용 가능한 ID의 보충

ReplenishDatabaseSequencesWorker는 시퀀스에 남은 공간을 확인하고 값이 임계값 아래로 내려가면 새로운 범위를 요청합니다. 

def replenish_table_seq(table, lower_limit, count)
  seq_name = "#{table}_id_seq"
  # maxval은 존재하지 않으므로 다른 방식으로 구현해야 하지만, 이것은 쇼케이스 목적입니다.
  last_id, max_id = select_one("SELECT currval(?), maxval(?)", seq_name, seq_name)
  return if max_id - last_id > lower_limit
  
  new_start, new_limit = post("/api/v4/internal/cells/database/claim", { table: table, count: count })
  execute("ALTER SEQUENCE RESTART ? MAXVALUE ?", new_start, new_limit)
end

이로 인해 일련의 ID 공간이 중단되어 ID 간격이 발생합니다. 그러나 이 모델에서는 시퀀스를 고의적으로 보충해야 하며 그렇지 않으면 새 레코드 삽입시에 치명적인 오류가 발생합니다.

위에서 언급한 요청 및 보충 방법은 각 테이블에서 요청된 ID 공간을 너무 많이 낭비할 수 있습니다.

예를 들어, 특정 테이블이 101부터 200까지의 범위를 요청한 후, 처음 80개 ID(101부터 180)를 사용한 후에 나머지 20개 ID가 낭비될 수 있습니다.

요청된 모든 ID를 효과적으로 활용하기 위해 모든 테이블에서 두 가지 번갈아가며 시퀀스를 유지하고 nextval 및 유사한 기능을 위해 사용자 지정 구현을 사용하는 강력한 고유성 개념을 도입합니다.

테이블 시퀀스의 강력한 고유성

이는 기본적인 고유성과 매우 유사하며 다음과 같은 추가 기능이 있습니다:

  • 테이블당 번갈아가며 두 시퀀스를 사용하여 할당된 시퀀스를 완전히 활용합니다.
  • DEFAULT를 두 인수를 받아들이도록 변경하여 nextval2(table_id_seq_a::regclass, table_id_seq_b::regclass) 함수를 사용합니다.
  • 시퀀스가 무료 ID를 모두 사용하면 즉시 시퀀스를 보충합니다.
  • 시퀀스 간격을 생성하지 않습니다. 
CREATE FUNCTION nextval2(seq_a oid, seq_b oid) RETURNS bigint
    LANGUAGE plpgsql
    AS $$
BEGIN
    -- 숫자가 단조롭게 증가하도록 유지하려면 더 낮은 숫자의 시퀀스를 선택합니다.
    -- 할당이 실패할 경우(시퀀스가 고갈되었을 때) 다른 시퀀스로 전환합니다.
    SELECT last_value INTO seq_a_last_value FROM seq_a;
    SELECT last_value INTO seq_b_last_value FROM seq_b;
    IF seq_a_last_value < seq_b_last_value
        BEGIN TRY
              RETURN nextval(seq_a);
        END TRY
        BEGIN CATCH
              RETURN nextval(seq_b);
        END CATCH;
    ELSE
        BEGIN TRY
              RETURN nextval(seq_b);
        END TRY
        BEGIN CATCH
              RETURN nextval(seq_a);
        END CATCH;
    END
END
$$;

장점

  • 제안이 간결합니다:
    • 각 셀은 클러스터가 작동하는 데 필요한 데이터의 일부만 보유합니다.
    • 로컬에 저장된 main_clusterwide로 표시된 테이블은 메시 아키텍처를 따라 셀 간에 선택적으로 복제될 수 있습니다.
      • 셀이 공유 데이터(사용자와 같은)의 일부만 필요로 한다는 가정에 따라 보조 셀은 전체 클러스터에 걸쳐 작은 비율의 레코드를 필요로 할 것으로 예상됩니다.
  • 주 셀은 다음과 같은 한정적인 기능 세트에 대해서만 단일 장애 지점입니다:
    • 고유성은 주 셀에서 강제됩니다.
    • 주 셀의 일시적 신뢰성은 보조 셀에 제한적인 영향을 미칩니다.
    • 보조 셀은 고유 제약 조건을 강제할 수 없습니다: 그룹, 프로젝트, 또는 사용자 생성.
    • 보조 셀의 다른 기능은 현재 상태 그대로 계속 작동합니다: 푸시, CI 실행.
  • 라우팅 레이어는 접두사를 사용하고 기밀 기반인 것으로 매우 간단합니다.
    • 서비스의 신뢰성이 셀 가용성에 의존하지 않으므로 현재 단계에서는 동적 분류가 필요하지 않습니다.
    • 라우팅 레이어는 나중에 정기적인 분류를 수행하도록 발전할 것으로 예상됩니다.
  • 설계에 따라 혼합 배포 호환됩니다.
    • 데이터베이스 연결을 공유하지 않습니다. 클러스터 전역 데이터와 상호 작용하기 위한 API를 노출합니다.
    • 응용 프로그램은 첫 날부터 다양한 버전의 응용 프로그램을 쉽게 지원할 수 있도록 API 호환성을 지원합니다.
  • 데이터베이스 마이그레이션.
    • 셀에 독립적으로 작동하며 기본 main_clusterwide 테이블에 완전한 소유권을 갖습니다.
    • 클러스터 전역 테이블과 셀 지역 테이블 간의 모든 교차 조인을 수정하는 것은 많은 작업이 들어가는 일입니다. main_clusterwide 테이블을 각 셀에 로컬로 저장함으로써 첫 번째 반복에 시간을 절약할 수 있습니다.

단점

  • main_clusterwide로 표시된 테이블의 데이터를 의도적으로 모든 클러스터 셀에 분할합니다.
    • 이러한 테이블은 (아마도) 응용 프로그램 외부에서 선택적으로 복제될 것입니다. 보조 셀이 데이터를 공유할 수 있도록 추가 코드 양을 허용하는 중요한 추가 작업입니다.
    • 데이터가 복제되면 클러스터 전체에서 데이터 일관성을 보장하기 위해 모든 테이블을 분류해야 합니다.
    • 강제된 레코드 복제시 클러스터 전체에서 데이터 일관성을 보장합니다.

Cells에서 지원되지 않는 GitLab.com의 기능

Cells 1.0의 초기 배포를 위해 일부 기능의 범위를 축소하여 배포하는 중입니다. 이는 Cells 1.0이 향후에 이러한 기능을 지원하지 않는다는 것을 의미하는 것은 아니지만, 우리의 애플리케이션/인프라는 아직 이를 지원하지 않습니다.

아래 표는 기존의 GitLab.com 기능과 Self-managed/전용 기능 간의 비교입니다.

초기 지원되지 않음 이유
GitLab Pages 복잡성.
CI 카탈로그 CI 카탈로그는 공개 프로젝트에 의존하며, Cells 1.0의 조직은 공개 프로젝트를 볼 수 없습니다.
조직 전환 사용자는 단일 조직에 속합니다.
Cells 간의 공유 사용자 계정 사용자는 현재 각 Cell마다 새 사용자 계정이 필요합니다.
GitLab Duo Pro 라이선스가 인스턴스의 모든 프로젝트에서 작동 GitLab Duo Pro 라이선스가 부여되면, 인스턴스의 모든 프로젝트에서 GitLab Duo Pro를 사용할 수 있어야 함. Cells 1.0에서는 이 기능이 자신의 셀 내에서만 작동합니다.
Cells 간의 공유 사용자 계정 사용자는 현재 각 Cell마다 새 사용자 계정이 필요합니다.
사용자 삭제 사용자는 단일 조직의 일부만 될 수 있습니다. 해당 경우 삭제는 삭제와 동일하며, 따라서 셀 1.0 내의 조직에서는 사용자 삭제만 제공될 것입니다. 제거되면 사용자는 다른 조직을 찾을 방법이 없으며, 셀 1.0용으로는 비공개이므로 가입할 다른 조직을 발견할 수 없을 것입니다.

질문

  1. 보조 Cell에 사용자와 함께 새로운 조직을 만드는 방법은 무엇인가요?

    정의되어야 합니다.

  2. 보조 Cell의 기존 조직에 새로운 사용자를 등록하는 방법은 무엇인가요?

    조직이 이미 생성된 경우 사용자를 초대할 수 있습니다. 그런 다음 보조 Cell에서 등록 흐름을 제공할 수 있습니다.

  3. 사용자는 어떻게 로그인하나요?

    • UI: 조직에 대한 로그인은 조직에만 적용됩니다: https://<GITLAB_DOMAIN>/users/sign_in?organization=gitlab-inc.
    • SAML: https://<GITLAB_DOMAIN>/users/auth/saml/callback은 ?organization=gitlab-inc을 받아서 올바른 Cell로 라우팅됩니다.
    • 이를 위해서는 고가용성 솔루션을 통한 조직 디렉터리을 사용하여 동적 라우팅 방법을 사용해야 합니다.

  4. 보조 Cell에 초기 배포된 경우 새로운 테이블을 어떻게 추가하나요?

    기본 Cell은 일련번호의 고유성을 보장하고 있으므로 시퀀스를 가져야 합니다.

  5. 컨테이너 레지스트리는 클러스터 전역이며 셀 로컬인가요?

    컨테이너 레지스트리는 셀 로컬에서 실행될 수 있으며, 시크릿 기반 라우팅을 따르면 동일한 방식으로 필터링될 수 있습니다. GitLab이 서명한 JWT 토큰이 라우팅 레이어에 의해 정적으로 라우팅될 수 있는 형식으로 되어야 합니다.

  6. GitLab Pages는 클러스터 전역인가요 셀 로컬인가요?

    Cells 1.0에 대해 GitLab Pages는 필수가 아니기 때문에 Cells 1.0에서는 이를 지원하지 않을 것입니다. 이에 대한 토론은 여기에서 찾을 수 있습니다.

    만약 GitLab Pages가 .gitlab.io 도메인을 지원하는 경우:

    • GitLab Pages는 셀로 실행되지만 별도의 도메인을 제공해야 합니다.
    • 사용자 정의 도메인은 별도의 도메인을 사용해야 합니다.

    또는:

    • 공통 도메인에 대한 도메인 관리 문제가 생깁니다.
    • 셀을 사용자에게 노출시키기 때문에 문제가 발생합니다.

  7. 내부 엔드포인트에 대해 정적 시크릿을 사용해야 할까요 아니면 JWT를 사용해야 할까요?

    정의되어야 합니다. 제시된 솔루션의 간편함을 위해 정적 시크릿이 사용됩니다.

  8. SSH 클론을 어떻게 처리하나요?

    본 제안에서 의도적으로 해결되지 않은 라우팅과는 별도의 문제입니다.

  9. 다른 클러스터 전체 고유 제약 사항은 무엇인가요?

    • 인증키
    • GPG 키
    • 사용자 지정 이메일
    • 페이지 도메인
    • 미정

  10. 방송 메시지 또는 애플리케이션 설정과 같은 클러스터 전체 테이블을 어떻게 동기화하나요?

    매우 가능성이 높은 접근 방식은 다음과 같습니다: 해당 정보를 API를 통해 노출하고 주기적으로 동기화합니다. 동기화가 실시될 가능성이 높은 테이블은 다음과 같습니다:

    • 애플리케이션 설정
    • 방송 메시지
    • 미정

  11. 이 작업을 어떻게 내부 테스트하나요?

    정의되어야 합니다.

  12. 관리자 계정을 어떻게 관리하나요?

    아직 군을 통해 동기화하지 못하기 때문에 관리자 계정은 각 Cell마다 제공되어야 합니다. 이미 GitLab Dedicated로 해결된 문제일 수 있습니다?

  13. Primary Cell 또는 클러스터 전체 서비스는 무엇인가요?

    사실상 Primary Cell은 클러스터 전체 서비스입니다. 의도에 따라 다음과 같이 명명될 수 있습니다:

    • Primary Cell: 현재 Primary Cell에 특별한 목적이 있지만 나중에 이름을 변경할 수 있습니다.
    • 클러스터 전체 데이터 제공자
    • 글로벌 서비스: Primary Cell이 현재 글로벌 서비스를 구현한다는 것을 나타내는 대체 이름입니다.

  14. 비밀은 어떻게 생성하나요?

    셀 접두사는 접두사를 인코딩하는 방식으로 비밀을 생성하는 데 사용됩니다. 생성된 접두사에 접두사를 추가합니다. 예시:

    • GitLab Runner 토큰은 다음과 같은 형식으로 생성됩니다: glrt-2CR8_eVxiioB1QmzPZwa
    • Cell 접두사: secrets_prefix: kPptz
    • GitLab Runner 토큰은 다음과 같은 형식으로 생성됩니다: glrt-kPptz_2CR8_eVxiioB1QmzPZwa

  15. 기존 경로 기반 라우팅 대신 시크릿 기반 라우팅을 사용하는 이유는 무엇인가요?

    Cells 1.0은 빠르게 다중 테넌트 및 다중 Cell 솔루션을 배포할 수 있는 아키텍처의 초안을 제공하기 위한 것입니다. 경로 기반 라우팅을 해결하는 것은 상당한 노력을 필요로 합니다:

    • 기존 경로의 모든 경로를 /org/<org-name>/-/로 접두어를 붙이는 것은 /api/v4/jobs/request와 같은 애매한 또는 Cell 로컬 또는 클러스터 전체 경로를 처리하는 명시적 선택이 필요합니다. 경로를 변경하면 마이그레이션해야하는 모든 사용자에게 중단 변경이 발생합니다.
    • 모든 기존 경로를 라우팅 가능하게 만드는 것은 /-/autocomplete/users와 같은 경로를 수정하는 것만으로도 상당한 노력이 필요하며, 이는 몇 년의 노력이 필요할 것으로 예상됩니다. 이미 분류 된 경로에 대한 일부 예비 분석은 이 댓글에서 확인할 수 있습니다.
    • 각 경우에 라우팅 서비스는 지정된 기준에 따라 기존 경로를 동적으로 분류할 수 있어야 하며, 이는 상당한 개발 노력을 필요로하기 때문에 Primary Cell이나 클러스터 전체 서비스에 대한 의존성을 높이게 됩니다.

    시크릿 기반 라우팅을 따르면 초기 복잡도를 줄일 수 있기 때문에 나중에 최선의 결정을 내릴 수 있습니다:

    • 주입된 접두사는 정적 라우팅 메커니즘을 일시적으로 활성화하는 조치입니다.
    • 나중에 동적 분류를 반드시 구현해야 합니다.
    • Cells 1.0 이후 경로 기반 라우팅을 접근하는 최선의 방법을 찾을 수 있습니다.

  16. 셀 간의 데이터 마이그레이션은 어떻게 진행되나요?

    Cells 1.0은 새로운 고객을 대상으로 합니다. 기존 고객을 마이그레이션하는 것은 그 자체로 큰 사업입니다.

    • 마이그레이션할 고객은 먼저 조직 모델을 선택해야 합니다.
    • 우리는 대부분의 격리 기능이 작동할 것으로 예상합니다.
    • 초기에는 셀 분할 모델을 따를 것입니다. 해당 레코드가 있는 위치를 표시하고 셀을 복제합니다.

    기존 고객은 여전히 Cells 1.0으로 마이그레이션될 수 있지만, GitLab.com에서 Dedicated로 고객을 마이그레이션하는 방식과 유사한 가져오기/내보내기 기능을 사용해야 합니다. 따라서 모든 정보가 마이그레이션되는 것은 아닙니다. 예를 들어, 현재 프로젝트 가져오기/내보내기는 CI 트레이스나 작업 아티팩트를 마이그레이션하지 않습니다.

  17. 시크릿 기반 라우팅은 문제가 될까요?

    정의되어야 합니다.

  18. 셀 간에 사용자를 어떻게 동기화하나요?

    main_clusterwide로 표시된 테이블의 외부 동기화를 빌드합니다. 이에 대한 결정은 레일과 일부 서커흘를 통한 API로 하던가, Dedicated 서비스를 통해 하던가를 아직 정의하고 있습니다. 그러나 레일을 사용하면 응용 프로그램이 예상 데이터 구조를 알기 때문에 가장 간단하고 믿을 수 있는 해결책일 가능성이 높습니다.

    위의 제안을 따르면 다른 Cell이 사용자 엔트리를 동기화하는 API를 사용하여 가능한 모든 인접 테이블을 노출합니다: /api/v4/internal/cells/users/:id. API는 users 테이블을 protobuf 데이터 모델로 직렬화합니다.

  19. 셀이 사용자나 프로젝트를 찾을 방법은 무엇인가요?

    정의되어야 합니다. 그러나 Primary Cell/클러스터 전체 데이터 제공자가 모든 정보의 매핑을 포함하는 routes 테이블에 액세스하여 상응하는 정보를 찾아야 합니다.

  20. 기업 고객을 위해 생성된 사용자 프로필은 공개됩니까?

    아닙니다. 특정 조직의 다른 Cell에서 생성된 사용자는 해당 조직에만 제한됩니다. 사용자 프로필은 로그인 상태인 한에만 사용할 수 있습니다.

  21. Primary Cell에서 클러스터 전체 API를 노출하는 경우의 실용성은 무엇인가요?

    API는 User, Groups, Projects, Organizations, SSH 키, Pages 도메인, 이메일의 고유성을 보장해야 합니다. API가 또한 라우팅 서비스에 대한 샤딩 키를 분류해야 합니다. Primary Cell의 클러스터 전체 API가 고도로 가용성이 있도록 보장해야 합니다. 여기에 대한 해결책은 다음과 같을 수 있습니다:

    1. Primary Cell API를 중진 노드로 실행하고 별도의 데이터베이스 레플리카를 가지고 주요 Cell이 다운될 때 작동할 수 있도록 합니다.
    2. 다른 레일과 다른 기술로 고도로 가용성이 있는 데이터베이스를 위에 구현합니다. API 쓰기 호출을 리포지터리로 전달하지만 읽기 API 호출을 사용합니다.

  22. 새로운 Cells에서 인스턴스 전체 CI 러너를 어떻게 구성할 수 있나요?

    정의되어야 합니다.

  23. 왜 FQDN(mycorp.gitlab.com 또는 mygitlab.mycorp.com)을 사용하지 않나요?

    gitlab.com이 많은 조직과의 상호 작용 방식과는 상관없이 한 응용 프로그램으로 느껴지길 원합니다. 따라서 우리는 사용자 및 나중에는 일부 데이터를 조직 간에 공유하려고 합니다. 이는