GitLab Cells 개발 가이드라인

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

개요 # 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 인스턴스)의 기존 조직에 특히 중요합니다. 조직