개요#

Cells는 서로 다른 조직을 별개의 GitLab 물리적 인스턴스로 서비스할 수 있도록 하는 새로운 아키텍처입니다. 각 인스턴스를 cell이라고 합니다. 이 아키텍처의 목표와 동기에 대해서는 Cells 목표 페이지를 참조하세요. 더 넓은 아키텍처 개요는 설계 문서를 참조하세요.

Cells는 GitLab.com 전용으로 계획되어 있습니다. GitLab Self-Managed 및 GitLab Dedicated는 단일 cell로 실행됩니다.

Cells 개발 원칙#

모든 개발자는 기능을 구축하거나 수정할 때 다음 원칙을 따라야 합니다.

아래의 모든 원칙은 이미 자동화되어 있어야 하지만, 엣지 케이스와 레거시 케이스는 여전히 남아 있습니다.

컴퓨팅 범위를 단일 조직으로 제한#

Web/API 요청과 Sidekiq 워커는 단일 조직 범위 내에서 실행되어야 합니다. 가능하면 조직 간 컴퓨팅을 조직 범위로 전환하세요.

요청은 올바른 cell로 라우팅 가능해야 함#

cell 외부로부터 요청을 수락하는 모든 cell 로컬 서비스는 요청이 속한 조직을 기반으로 올바른 cell로 라우팅될 수 있어야 합니다. 타깃 cell의 cell 로컬 서비스가 요청을 처리합니다.

이는 Web, API, Git 및 서비스별 프로토콜(예: KAS 또는 컨테이너 레지스트리)을 포함한 모든 요청 유형과 프로토콜에 적용됩니다.

조직 데이터 소유권을 명확하게 유지#

조직 데이터는 다른 cell로 마이그레이션할 수 있어야 합니다. 이는 상태를 저장하는 모든 cell 로컬 서비스에 적용됩니다.

GitLab Rails 모놀리스 데이터베이스의 경우, 데이터 소유권은 스키마에서 명확하게 드러나야 합니다. 모든 고객 데이터 테이블은 샤딩 키를 통해 조직까지 추적 가능한 경로를 가져야 합니다.

고객 데이터를 저장하는 모든 새 모델은 각 행이 단일 조직에 귀속될 수 있도록 샤딩 키를 정의해야 합니다. 비고객 데이터(고객 조직에 속하지 않는 데이터)는 스키마 분류에서 cell 로컬로 표시해야 합니다. Cell 로컬이란 해당 행이 cell을 벗어나지 않음을 의미합니다.

새 테이블을 설계하거나 기존 테이블을 확장할 때, 각 행의 소유권이 명확한지 확인하세요. 소유권이 모호하면 향후 cell 마이그레이션이 차단됩니다.

조직 외부에 새로운 고객 소유 리소스를 추가하지 않음#

조직 외부에 존재하는 새로운 고객 소유 리소스를 도입하지 마세요. 모든 고객 데이터는 조직 내부에 속해야 합니다. 조직 외부에 존재하는 리소스는 조직이 다른 cell로 이동할 때 마이그레이션할 수 없습니다.

조직은 cell에 격리됨#

조직은 본질적으로 cell에 격리됩니다. 조직의 모든 데이터와 컴퓨팅은 단일 cell에 존재합니다. cell 간 조직 데이터 접근은 지원되지 않습니다.

조직 간 격리는 조직의 선택#

같은 cell에 있는 조직 간 격리는 조직의 선택 사항입니다. 이는 조직 간 상호작용이 이미 존재할 수 있는 레거시 cell(기존 GitLab.com 인스턴스)의 기존 조직에 특히 중요합니다.

조직 간 격리를 제공하는 컨트롤은 조직이 격리를 선택했는지 여부를 고려해야 합니다. 같은 cell에 있는 모든 조직이 서로 격리되어 있다고 가정하지 마세요.

사용 가능한 Cells / Organization 스키마#

다음은 Cells 및 Organizations와 관련된 사용 가능한 스키마입니다:

대부분의 테이블은 샤딩 키를 정의해야 합니다.

기존 테이블이 어떻게 분류되는지 이해하려면 이 대시보드를 사용할 수 있습니다.

스키마가 할당된 후, 다음 이유 중 하나 이상으로 인해 머지 리퀘스트 파이프라인이 실패할 수 있으며, 연결된 가이드라인을 따라 수정할 수 있습니다:

• 데이터베이스 간 조인

• 데이터베이스 간 트랜잭션

• 데이터베이스 간 외래 키

새 스키마 생성#

스키마는 기본적으로 샤딩 키를 요구해야 합니다. 기능은 기본적으로 Organization 범위여야 하기 때문입니다.

# db/gitlab_schemas/gitlab_ci.yaml
require_sharding_key: true
sharding_root_tables:
  - projects
  - namespaces
  - organizations

require_sharding_key를 true로 설정하면 해당 스키마에 할당된 테이블은 sharding_key가 설정되어야 합니다. 또한 이 스키마의 테이블에 대한 샤딩 키로 사용할 수 있는 허용된 sharding_root_tables 목록을 구성해야 합니다.

데이터베이스 시퀀스#

모든 cell에 걸쳐 데이터베이스 시퀀스의 고유성을 보장합니다. 이는 대부분의 테이블의 id 칼럼이 고유하다는 것을 의미합니다.

기술적 구현 및 아키텍처 결정 사항은 다음을 참조하세요:

• Cells: 클러스터 전체 고유 데이터베이스 시퀀스

• Topology Service: 시퀀스 서비스

고유 제약 조건#

데이터를 고유하게 유지해야 하는 경우, Organization, Group, Project 또는 User 단위로 고유하도록 범위를 지정해야 합니다. 각각 독립적인 데이터베이스를 가진 여러 cell이 존재하므로, 더 이상 UNIQUE 제약 조건에 의존할 수 없습니다.

두 가지 옵션이 있습니다:

• 인덱스에 sharding_key를 포함시켜 인덱스 범위를 지정합니다.

• 속성이 모든 조직에 걸쳐 전역적으로 고유해야 하는 드문 경우에는, Claim 서비스를 사용하세요.

Claim 서비스#

Rails에서 claim 서비스를 사용하려면: cell에 대한 속성 청구

정적 데이터#

문제: 데이터베이스 테이블이 정적 데이터를 저장하는 데 사용됩니다. 그러나 자동 증가 시퀀스를 사용하기 때문에 기본 키가 정적이지 않습니다. 이는 기본 키가 전역적으로 일관성이 없다는 것을 의미합니다.

이 일관성 없는 기본 키에 대한 참조는 cell/조직 간에 참조가 충돌하기 때문에 문제를 일으킵니다.

예시: 특정 Cell의 plans 테이블에 다음 데이터가 있습니다:

 id |             name             |              title
----+------------------------------+----------------------------------
  1 | default                      | Default
  2 | bronze                       | Bronze
  3 | silver                       | Silver
  5 | gold                         | Gold
  7 | ultimate_trial               | Ultimate Trial
  8 | premium_trial                | Premium Trial
  9 | opensource                   | Opensource
  4 | premium                      | Premium
  6 | ultimate                     | Ultimate
 10 | ultimate_trial_paid_customer | Ultimate Trial for Paid Customer
(10 rows)

다른 cell에서는 plans 테이블의 동일한 name에 대해 id가 다릅니다:

 id |             name             |            title
----+------------------------------+------------------------------
  1 | default                      | Default
  2 | bronze                       | Bronze
  3 | silver                       | Silver
  4 | premium                      | Premium
  5 | gold                         | Gold
  6 | ultimate                     | Ultimate
  7 | ultimate_trial               | Ultimate Trial
  8 | ultimate_trial_paid_customer | Ultimate Trial Paid Customer
  9 | premium_trial                | Premium Trial
 10 | opensource                   | Opensource

이 plans.id 칼럼은 gitlab_subscriptions 테이블의 hosted_plan_id 칼럼에서 참조로 사용됩니다.

해결책: 데이터베이스 시퀀스가 아닌 전역적으로 고유한 참조를 사용하세요. 가능하면 데이터베이스 대신 애플리케이션 코드에 정적 데이터를 하드코딩하세요.

이 경우, plans 테이블을 삭제하고 고정 모델로 대체할 수 있습니다 (자세한 내용은 구성 가능한 상태 설계 문서에서 확인할 수 있습니다):

class Plan
  include ActiveRecord::FixedItemsModel::Model

  ITEMS = [
    {:id=>1, :name=>"default", :title=>"Default"},
    {:id=>2, :name=>"bronze", :title=>"Bronze"},
    {:id=>3, :name=>"silver", :title=>"Silver"},
    {:id=>4, :name=>"premium", :title=>"Premium"},
    {:id=>5, :name=>"gold", :title=>"Gold"},
    {:id=>6, :name=>"ultimate", :title=>"Ultimate"},
    {:id=>7, :name=>"ultimate_trial", :title=>"Ultimate Trial"},
    {:id=>8, :name=>"ultimate_trial_paid_customer", :title=>"Ultimate Trial Paid Customer"},
    {:id=>9, :name=>"premium_trial", :title=>"Premium Trial"},
    {:id=>10, :name=>"opensource", :title=>"Opensource"}
  ]

  attribute :name, :string
  attribute :title, :string
end

모델 유효성 검사를 사용하고 all, where, find_by, find와 같은 ActiveRecord 유사 메서드를 사용할 수 있습니다:

Plan.find(4)
Plan.find_by(name: 'premium')
Plan.where(name: 'gold').first

hosted_plan_id 칼럼도 고정 모델의 id 값을 참조하도록 업데이트됩니다.

다른 모델과의 연관 관계도 저장할 수 있습니다. 예를 들어:

class CurrentStatus < ApplicationRecord
  belongs_to_fixed_items :system_defined_status, fixed_items_class: WorkItems::Statuses::SystemDefined::Status
end

고정 항목 모델 구현에 대한 완전한 가이드는 고정 항목 모델을 참조하세요.

정적 데이터를 하드코딩하는 예시는 다음과 같습니다:

• VisibilityLevel

• 작업 항목 상태의 정적 기본값

• Ai::Catalog::BuiltInTool

기타 주제#

라우팅에 대해서는 HTTP Router를 참조하세요. 클러스터 전체 서비스에 대해서는 Topology Service를 참조하세요.