GitLab Cells 개발 가이드라인

GitLab Cells 아키텍처에서 기능을 구축하거나 수정할 때 개발자가 따라야 할 원칙과 스키마, 데이터베이스 설계 규칙을 설명합니다.

개요 # Cells는 서로 다른 조직을 물리적으로 분리된 GitLab 인스턴스가 담당하도록 하는 새 아키텍처입니다. 각 인스턴스를 cell 이라고 부릅니다. 이 아키텍처의 목표와 배경은 Cells 목표 페이지 를 참고합니다. 아키텍처 전반의 개요는 설계 문서 를 참고합니다. Cells는 GitLab.com 에만 적용할 계획입니다. GitLab Self-Managed와 GitLab Dedicated는 단일 cell로 동작합니다. Cells 개발 원칙 # 기능을 만들거나 수정하는 모든 개발자는 다음 원칙을 따라야 합니다. 아래 원칙은 모두 이미 자동화되어 있지만, 예외 사례와 레거시 사례는 남아 있습니다. 컴퓨팅 범위를 단일 조직으로 제한 # 웹·API 요청과 Sidekiq 워커는 단일 조직 아래에서 실행되어야 합니다. 조직 간에 걸친 컴퓨팅은 가능한 한 조직 범위로 전환합니다. 조직 간에 걸친 Sidekiq job은 해당 job 이 반복 실행되는 cron job 이면서 멱등할 때만 허용됩니다. 자세한 내용은 Sidekiq의 Cells 호환성 을 참고합니다. 요청은 올바른 cell로 라우팅 가능해야 함 # cell 외부에서 오는 요청을 받는 모든 cell 로컬 서비스는 요청이 속한 조직을 기준으로 올바른 cell로 라우팅될 수 있어야 합니다. 그다음 대상 cell의 cell 로컬 서비스가 해당 요청을 처리합니다. 이는 웹, API, Git은 물론 서비스별 프로토콜(예: KAS 나 컨테이너 레지스트리)을 포함한 모든 요청 유형과 프로토콜에 적용됩니다. 조직 데이터 소유권을 명확하게 유지 # 조직 데이터는 다른 cell로 이전할 수 있어야 합니다. 이는 상태를 가지는 모든 cell 로컬 서비스에 적용됩니다. GitLab Rails 모놀리스 데이터베이스에서는 스키마만 봐도 데이터 소유권이 분명해야 합니다. 모든 고객 데이터 테이블은 샤딩 키 를 통해 조직까지 추적할 수 있는 경로를 가져야 합니다. 고객 데이터를 저장하는 모든 새 모델은 각 행이 단일 조직에 귀속되도록 샤딩 키를 정의해야 합니다. 고객 데이터가 아닌 데이터(고객 조직에 속하지 않는 데이터)는 스키마 분류 에서 cell 로컬로 표시해야 합니다. cell 로컬이라는 것은 해당 행이 cell을 벗어나지 않는다는 뜻입니다. 새 테이블을 설계하거나 기존 테이블을 확장할 때는 각 행의 소유권이 모호하지 않은지 확인합니다. 소유권이 모호하면 이후 cell 이전이 막힙니다. 조직 외부에 새 고객 소유 리소스를 추가하지 않음 # 조직 외부에 존재하는 새 고객 소유 리소스를 도입하지 않습니다. 모든 고객 데이터는 조직 안에 속해야 합니다. 조직 외부에 존재하는 리소스는 조직이 다른 cell로 이동할 때 이전할 수 없습니다. 조직은 cell에 격리됨 # 조직은 본질적으로 하나의 cell에 격리됩니다. 한 조직의 모든 데이터와 컴퓨팅은 단일 cell에 존재합니다. 조직 데이터에 대한 cell 간 접근은 지원하지 않습니다. 조직 간 격리는 조직의 선택 # 같은 cell에 있는 조직 사이의 격리는 조직이