GitLab 확장성

GitLab의 확장성 및 안정성과 관련된 현재 아키텍처 구성 요소와 전략을 설명합니다.

이 섹션에서는 확장성 및 안정성과 관련된 GitLab의 현재 아키텍처를 설명합니다. 레퍼런스 아키텍처 개요 # [ ](/19.1/development/img/reference_architecture_v12_8.png) 다이어그램 소스 - GitLab 직원 전용 위 다이어그램은 50,000명의 사용자를 위해 확장된 GitLab 레퍼런스 아키텍처를 보여줍니다. 각 구성 요소에 대해 아래에서 설명합니다. 구성 요소 # PostgreSQL # PostgreSQL 데이터베이스는 프로젝트, 이슈, 머지 리퀘스트, 사용자 등의 모든 메타데이터를 저장합니다. 스키마는 Rails 애플리케이션의 db/structure.sql 에 의해 관리됩니다. GitLab Web/API 서버와 Sidekiq 노드는 Rails 객체 관계형 모델(ORM)을 사용하여 데이터베이스에 직접 통신합니다. 대부분의 SQL 쿼리는 이 ORM을 통해 접근하지만, 성능 향상이나 고급 PostgreSQL 기능(재귀 CTE 또는 LATERAL JOIN 등)을 활용하기 위해 일부 커스텀 SQL도 작성됩니다. 애플리케이션은 데이터베이스 스키마와 긴밀하게 결합되어 있습니다. 애플리케이션이 시작될 때, Rails는 데이터베이스 스키마를 쿼리하여 요청된 데이터에 대한 테이블과 칼럼 유형을 캐싱합니다. 이 스키마 캐시로 인해, 애플리케이션이 실행 중인 동안 칼럼이나 테이블을 삭제하면 사용자에게 500 오류가 발생할 수 있습니다. 이것이 바로 칼럼 삭제 및 다운타임 없는 변경을 위한 프로세스 가 있는 이유입니다. 멀티 테넌시 # 단일 데이터베이스를 사용하여 모든 고객 데이터를 저장합니다. 각 사용자는 여러 그룹이나 프로젝트에 속할 수 있으며, 그룹 및 프로젝트에 대한 접근 수준(Guest, Developer, 또는 Maintainer 포함)에 따라 사용자가 볼 수 있는 것과 접근할 수 있는 것이 결정됩니다. 관리자 접근 권한이 있는 사용자는 모든 프로젝트에 접근하고 사용자를 가장(impersonate)할 수도 있습니다. GitLab.com에서는 Cells 아키텍처 가 각 셀이 조직의 하위 집합을 호스팅하는 물리적 멀티 테넌시를 제공합니다. GitLab Self-Managed와 GitLab Dedicated는 단일 셀로 실행됩니다. 조직은 본질적으로 하나의 셀에 격리되며, 모든 조직 데이터는 해당 조직을 호스팅하는 셀에 상주합니다. 샤딩 및 파티셔닝 # 현재 데이터베이스는 분할되지 않았으며, 모든 데이터는 여러 테이블로 구성된 하나의 데이터베이스에 저장됩니다. 이는 단순한 애플리케이션에는 잘 작동하지만, 데이터 세트가 증가함에 따라 많은 행을 가진 테이블이 있는 하나의 데이터베이스를 유지 관리하고 지원하는 것이 더 어려워집니다. 이를 처리하는 두 가지 방법이 있습니다: 파티셔닝. 테이블 데이터를 로컬에서 분할합니다. 샤딩. 여러 데이터베이스에 걸쳐 데이터를 분산합니다. 파티셔닝은 PostgreSQL의 내장 기능으로, 애플리케이션 변경이 최소화됩니다. 그러나 PostgreSQL 11이 필요합니다 . 예를