• 현재 GitLab.com 아키텍처
• 향후 아키텍처
• 요구사항
  • 공통 요구사항
  • 현재 플랫폼 요구 사항
    • 성능
  • 셀 요구 사항
    • 분해
• 개요 - 가능한 해결책
  • PostgreSQL 이외의 제공 품목
  • Cloud SQL
    • 확인해야 할 사항
  • k8s Operator
    • 확인해야 할 사항
  • 현재 자동화 리팩터링
• Cells 1.0
• Cells 1.x
• 현재 데이터베이스 플랫폼

데이터베이스 플랫폼

현재 GitLab.com 아키텍처

GitLab.com은 Terraform, Chef 및 Ansible을 이용해 GCP에서 관리되는 가상 머신에서 실행되는 4개의 PostgreSQL 클러스터를 사용합니다. Cells를 사용하면 4개 이상의 PostgreSQL 클러스터를 생성할 수 있으며, 50개의 Cells를 사용하려면 50개 이상의 PostgreSQL 클러스터가 필요합니다.

현재 4개의 다른 데이터베이스 클러스터가 있으며, 각 클러스터는 단일 프로덕션 데이터베이스를 호스팅합니다.

데이터는 organization_id로 분할되며, organization_id는 1개의 Cell에 속할 수 있습니다.

Cells를 롤아웃하는 동안 대부분의 데이터는 현재 데이터베이스 클러스터에 그대로 유지될 것이므로, 이러한 대형 모노리식 시스템의 요구사항을 고려하는 것이 중요합니다.

향후 아키텍처

다가오는 Cells 프로젝트의 요구사항은 다릅니다. 현재 업무 추정치에 따르면, 각 Cell은 현재의 대형 모놀리식에 비해 상대적으로 적은 수의 사용자를 호스트할 것으로 예상되며, 많은 수의 작은 데이터베이스 클러스터를 짧은 시일 내에 생성하는 새로운 과제가 있습니다.

정확한 요구사항은 시간이 지남에 따라 발전할 것이지만, 다음이 요청됩니다:

• Cell 프로비저닝의 일부가 될 데이터베이스 클러스터의 API를 통한 생성 및 제거.
• 50,000 사용자 API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS와 같은 참조 아키텍처 크기의 데이터베이스 클러스터.
• 최대 2,000개의 Cells 및 데이터베이스 클러스터.

현재의 자동화에는 각 클러스터에 대한 전용 Chef 역할을 생성하는 등 많은 매뉴얼 단계가 포함되어 있습니다. 새로운 클러스터를 만드는 변경 프로세스는 여러 개의 합병 요청과 동료 검토뿐만 아니라 변경 요청에 따른 실행이 가장 많은 오버헤드입니다. 이는 새로운 요구 사항과 호환되지 않습니다.

그러나 Cells는 첫 번째 Cell에 대해 반복적으로 시작하여 하나의 데이터베이스 클러스터가 필요합니다. 따라서 현재 플랫폼은 적어도 Cells 1.0에서 사용할 수 있지만, 모든 데이터가 새로운 Cell 로컬 데이터베이스 클러스터에 저장될 때까지 유지될 수 있습니다.

또한 현재 데이터를 새로운 데이터베이스 플랫폼으로 마이그레이션하는 것도 가능하며, 이 작업이 완료되기 전에는 새로운 작은 Cells에 걸쳐 전체 공유를 유지할 수 있어야 합니다.

요구사항

요구사항은 현재 GitLab.com의 대형 데이터 리포지터리 및 개별적인 Cells에 대한 우리의 추정치로 나눌 것입니다.

요구사항은 다음과 같은 범주로 나눌 수 있습니다. 이것들은 높음, 낮음, 낮음일 수 있습니다.

• 높음은 GitLab.com을 운영하는 데 필요합니다.
• 중간은 현재 운영에 필요하지만 대체될 수 있습니다.
• 낮음은 원하는 경우입니다.

공통 요구사항

현재 플랫폼 요구 사항

성능

성능은 중요한 요소입니다. 첫 번째 작업은 성능 개요를 정의하고 그에 부합하는 테스트 방법을 신뢰할 수 있는 방법으로 설정하는 것입니다.

{- TODO: 성능 요구 사항과 테스트 절차 정의 -}

다음과 같은 부하 피크를 관찰했으며 이를 지표로 활용할 수 있습니다:

• 주 서버에서 ~100k 읽기-쓰기 TPS
  • 메인 주 서버에서 ~80k TPS
  • CI 주 서버에서 ~32k TPS
• 대역 서버들 간 분산된 ~1M 읽기 전용 TPS
  • 메인 대역 서버에서 ~714k TPS
  • CI 대역 서버에서 ~150k TPS

셀 요구 사항

{- TODO: 성능 요구 사항 정의 및 다양한 이해 관계자에게 확인. @rnienaber와 논의한 대로, 우리는 가장 큰 레퍼런스 아키텍처를 기준으로 시작할 것입니다. -}

• 최대 50,000 사용자까지 우리의 가장 큰 레퍼런스 아키텍처, 최대 50,000 사용자 API: 1000 RPS, 웹: 100 RPS, Git (풀): 100 RPS, Git (푸시): 20 RPS
• 이는 나중에 증가될 수 있으며 현재 사용자를 호스팅하려면 여러 백 개의 셀이 필요할 수 있습니다

분해

또한 메인 데이터베이스를 분해하여 보안 및 관리 관련 테이블을 별도의 Postgres DB로 분해할 수 있는지 평가 중입니다.

실제 셀 크기와 데이터 양에 따라 각 데이터베이스에 대해 개별 클러스터를 유지하거나 한 셀당 여러 데이터베이스를 호스팅하기 위해 단일 클러스터를 사용해야 하는지를 확인해야 합니다. 셀의 최대 크기를 예단할 수 없게하기 위해, 각 데이터베이스에 대해 전용 클러스터를 사용할 수 있는 옵션을 구현해야 합니다.

현재 Dedicated / GET / Cells 도구는 분해를 지원하지 않습니다. GET 및 별도의 분해를 지원하는 것은 중간 복잡성의 작업으로 가능할 수 있습니다. 지정된 셀 크기에 대한 예측이 변경되지 않는다면, 셀 내에서의 분해가 필요하지 않을 수 있습니다. 따라서 첫 번째 반복에서는 셀 당 단일 데이터베이스 클러스터만 필요하며, 이외에는 지원되지 않을 것입니다.

개요 - 가능한 해결책

PostgreSQL 이외의 제공 품목

우리는 AlloyDB와 같은 PostgreSQL 호환성을 주장하는 PostgreSQL 이외의 품목을 간단히 살펴보았습니다. 비용과 리스크가 예상되는 이점에 비해 상당한 비율을 차지하지 않는다는 결론을 내렸습니다. 현재 PostgreSQL 자체에는 추가적인 조사가 정당화될만한 본질적인 결점이 없습니다.

자세한 내용은 아래에서 확인할 수 있습니다:

• Postgres DB 대체품 (Google Spanner vs AlloyDB)
• PostgreSQL 대신 포괄적인 데이터베이스로 전환

Cloud SQL

Cloud SQL은 구글의 표준 PostgreSQL 제공 품목입니다. 이는 상류 버전과 100% 호환되는 것으로 주장되는 사용자 지정 포크이며 Cloud SQL 문서에서는 단순히 PostgreSQL로 참조됩니다. GitLab은 현재 Cloud SQL을 지원되는 PostgreSQL 구현으로 인식합니다.

상기 대부분의 정보는 공식 Cloud SQL 문서에서 찾을 수 있습니다. 일부 예측은 GCP 팀에서 버버적으로 전달된 것입니다. GitLab과 함께 Cloud SQL 및 AlloyDB에 대한 논의 (내부)에서 확인할 수 있습니다.

확인해야 할 사항

• 제안된 논리 복제 기능(pglogical)을 마이그레이션에 사용할 수 있을까? - 2-4 주로 추정
• 회의에서는 GCP가 거부했지만 pitr 문서에 나타나는 WAL 및 base_backups에 액세스할 수 있을까? - 1 주 미만으로 추정
• 50k 참조 아키텍처의 주요 업그레이드에는 얼마나 걸릴까? - 4-5 주로 추정
• 현재 감시 도구에 대한 충분한 대체물인 Query Insights은 충분한가요?
• 읽기 복제본을 만드는 데 얼마나 걸리나요? 백업에서 새 클러스터를 만드는 데 얼마나 걸리나요? 10GB, 100GB, 1TB - 1 주로 추정

k8s Operator

현재 여러 사용 가능한 오퍼레이터가 있지만 상세한 평가 및 벤치마킹을 통해 요구 사항이 충족되는지 확인해야 합니다. 이후 무중단 업그레이드 기능을 제공하지 못할 수 있습니다. 현재도 우리는 이 기능에 대한 자체 자동화를 유지하고 있으며 오퍼레이터가 이 기능을 제공할 때까지 적응할 수 있습니다.

확인해야 할 사항

• 후보 비교 (4-5 주로 추정)
  • CYBERTEC PostgreSQL Operator (상업 지원이 있는 zalando)
  • CloudNativePG

현재 자동화 리팩터링

GitLab.com의 모든 PostgreSQL 클러스터를 호스트하는 현재 플랫폼은 주로 Terraform과 Chef를 사용하여 GCP 가상 머신을 관리합니다. 일부 복잡한 작업은 Ansible을 통해 조정됩니다.

현재 이 아키텍처의 주요 문제는 역사적 성장과 기술적 부채입니다. 이는 단일 또는 고정된 소수의 데이터베이스 클러스터를 호스팅하도록 설계되었습니다. 임의의 수의 클러스터를 호스팅하는 것이 이론적으로 가능하지만 매뉴얼 단계와 오버헤드가 필요합니다.

일부 예시:

• 각 데이터베이스 클러스터에 대해 여러 Chef 역할을 만들어야 합니다.
• 각 데이터베이스 클러스터에 대해 네트워크 서브넷을 매뉴얼으로 정의하고 구성 파일에 써야 합니다.
• 운영 방침에 따라 프로덕션에서 각 데이터베이스 클러스터에는 스테이징에 해당하는 클러스터가 있어야 합니다.

이러한 문제점과 병목현상은 Chef를 개선하거나 대체하여 해결할 수 있습니다.

Cells 1.0

Cells 1.0은 Cells의 첫 번째 반복으로 2024년에 GA가 되어야 합니다. 이 첫 번째 반복은 테스트 사용자와 프로젝트의 제한된 수만 호스팅하며 전체 요구 사항이 없습니다. 데이터베이스 플랫폼에 대한 학습과 반복의 기회를 제시합니다.

개발 동안 Cells의 수는 1에서 최대 10으로 증가할 것으로 예상되며, 두 번째 Cell이 생성되고 두 번째 클러스터가 필요할 때까지 여러 달이 걸릴 것으로 예상됩니다.

현재 Cloud SQL은 주요한 요구 사항을 충족시키지 않으며 해당 요구 사항이 완전히 포함된 로드맵도 없습니다. Cells 1.0 타임라인을 해제하기 위해 임시로 Cloud SQL을 사용할 것이며, 이에 따른 위험과 병목 현상에 동의합니다.

• 최종 플랫폼으로 마이그레이션할 때 다운타임이 발생할 것입니다!
• 서비스 품질은 GitLab.com과 동일하지 않을 것입니다.
  • 깊은 수준의 지원에 대한 명확한 SLO가 없습니다.
  • 합리적인 다운타임으로 주요 버전 업그레이드가 없습니다.
• 신뢰할 수 있는 이 솔루션을 50k 사용자로 성장시키지 못할 것이며, 우리는 이미 3k 사용자에 대한 연결 풀링에 문제가 있음을 알 수 있습니다.

요구 사항을 충족하는 솔루션을 찾아야 하며, Cells 1.0 이후로 이를 사용할 수 있도록 만들기를 우선시합니다.

Cells 1.x

Cells 1.0에서 강조했듯이 장기 요구 사항을 충족하기 위한 충분한 플랫폼을 구축하기 위해 임시로 Cloud SQL을 시작으로 시작합니다.

첫 번째 단계는 사용 가능한 k8s 오퍼레이터를 평가하고 가장 적합한 후보를 완전한 평가하기 위한 페이즈입니다.

현재 데이터베이스 플랫폼

현재 데이터베이스 플랫폼은 미래 성장에 제약이 있지만 현재는 포화 상태에는 도달하지 않았습니다. 데이터베이스가 병목 현상이 될 때가 명확하지 않지만, 이전 분해 이전의 경험에 따르면 크기가 200%인 데이터베이스는 운영상의 어려움을 야기합니다.

현재로서는 데이터베이스 크기가 두 배로 증가하는 데 얼마나 걸릴지 예측할 수 없지만, 다음 24개월 이내인 2026년까지는 그럴 것으로 예상됩니다.

이는 중요한 데이터를 셀로 이전하거나, 여기서 데이터베이스 플랫폼을 개선/변경할 충분한 시간을 제공합니다.