• 요약
• 목표
• 도전과제
  • 주 키 저장용량 소진: 완료
  • 일부 CI/CD 데이터베이스 테이블이 너무 큼: 진행 중
  • 큰 양의 데이터 이동이 어려움: 진행 중
• 제안
• 반복
• 상태
• 담당자

CI/CD Scaling

요약

GitLab CI/CD는 GitLab의 가장 데이터 밀도가 높고 컴퓨팅 집약적인 컴포넌트 중 하나입니다. 2012년 최초 릴리스 이후, CI/CD 서브시스템은 크게 발전했습니다. 2015년 9월에 GitLab에 통합되었으며, 가장 사랑받는 CI/CD 솔루션 중 하나가 되었습니다.

GitLab CI/CD는 초기 릴리스 이후 많은 발전을 거쳤지만, 파이프라인 빌드의 데이터 리포지터리 설계는 2012년 이후 거의 동일한 상태입니다. 우리는 모든 빌드를 ci_builds 테이블의 PostgreSQL에 저장하고 있으며, GitLab.com에서 하루에 500만 건 이상의 빌드를 생성하고 있어 개발 속도를 떨어뜨리는 데이터베이스 한계에 도달했습니다.

2021년 2월 1일, GitLab.com은 10억 건의 CI/CD 빌드 생성을 돌파했습니다. 2022년 2월에는 데이터베이스에 20억 건의 CI/CD 빌드를 달성했습니다. 빌드 수는 계속해서 기하급수적으로 증가하고 있습니다.

아래 스크린샷은 2021년 초에 만든 예측을 보여주는데, 이 예측이 상당히 정확했습니다.

목표

미래 성장을 가능하게 하기 위해 1일 2000만 빌드 처리를 가능하게 하기.

도전과제

미래 성장을 유지하려면 현재 CI/CD 제품 아키텍처 상태를 업데이트해야 합니다.

주 키 저장용량 소진: 완료

ci_builds 테이블의 기본 키는 시퀀스로 생성된 정수 값입니다. 과거에 Rails는 테이블의 기본 키를 생성할 때 정수 타입을 사용했습니다. 2012년에 ci_builds 테이블을 생성할 때 기본값을 사용했습니다. Rails의 동작이 변경되었으며, 프레임워크는 현재 8바이트 길이인 bigint 타입을 사용하고 있지만, 아직 ci_builds 테이블의 기본 키를 bigint로 마이그레이션하지 않았습니다.

2021년 초에 우리는 ci_builds 테이블에서 기본 키 저장용량이 2021년 12월 이전에 고갈될 것으로 추정했습니다. 심각한 상황 또는 긴급 계획 없이 이러한 상황이 발생했다면 GitLab.com이 다운될 수 있었습니다. ci_builds 테이블은 int4 시퀀스에서 사용 가능한 주 키를 모두 소진하고 있는 테이블 중 하나일 뿐입니다.

2021년 10월 이전에, 우리 데이터베이스 팀은 위험한 테이블의 기본 키를 모두 큰 정수로 마이그레이션하는 데 성공했습니다.

자세한 내용은 관련 Epic을 참조하세요.

일부 CI/CD 데이터베이스 테이블이 너무 큼: 진행 중

ci_builds 테이블에 20억 건 이상의 행이 있습니다. 해당 테이블에는 많은 테라바이트의 데이터를 저장하고 있으며, 총 인덱스 크기도 테라바이트 단위로 메트릭됩니다.

이 데이터 양은 CI PostgreSQL 데이터베이스에서 경험하는 중요한 성능 문제에 기여합니다.

대부분의 문제는 PostgreSQL 데이터베이스의 내부 작동 방식과 데이터베이스 노드의 리소스 활용과 관련이 있습니다. 우리는 CI 주 데이터베이스 노드의 수직 스케일링 한계에 도달했으며, ci_builds 테이블이 CI 데이터베이스의 전반적인 성능, 안정성, 확장 가능성 및 예측 가능성에 미치는 부정적인 영향을 빈번히 겪고 있습니다.

테이블의 크기는 개발 속도를 저하시키며, 개발 환경에서는 문제가 없어 보이던 쿼리가 GitLab.com에서는 작동하지 않을 수 있습니다. 환경 간 데이터 집합 크기의 차이로 인해 가장 간단한 쿼리의 성능을 예측하기가 어려워집니다.

팀 구성원과 커뮤니티 구성원들은 ci_builds를 더 확장할 수 있는 가능성을 제한했기 때문에 Verify 영역에 어려움을 겪고 있습니다. 우리의 정적 분석 도구는 이 테이블에 더 많은 열을 추가하는 것을 방지합니다. 데이터 집합의 크기와 해당 테이블을 사용하여 실행되는 쿼리의 양 때문에 새로운 쿼리를 추가하는 것은 예측하기 어렵습니다. 이는 개발 속도를 크게 저해시키고 프로덕션 환경에서의 사건에 기여합니다.

또한, 우리는 향후 몇 년 동안 크게 기하급수적인 성장을 기대하고 있습니다.

Facebook의 Prophet를 사용하여 수행한 예측 중 하나에 따르면, 2024년 상반기에는 GitLab.com에서 하루에 2000만 건의 빌드가 생성될 것으로 예상됩니다. 현재 500만 건 정도가 생성되고 있는 것과 비교하면 10배 성장한 수준입니다.

상태: 2021년 10월 기준으로, 빌드 옵션과 변수를 ci_builds_metadata 테이블에 기록함으로써 ci_builds 테이블의 성장률을 줄였습니다. 또한 시간 감소 패턴을 사용하여 가장 큰 CI/CD 데이터베이스 테이블을 파티셔닝 중입니다.

큰 양의 데이터 이동이 어려움: 진행 중

우리는 ci_builds 테이블에 상당한 양의 데이터를 저장하고 있습니다. 이 테이블의 일부 열에는 직렬화된 사용자 제공 데이터가 저장되어 있습니다. ci_builds.options 열에는 600기가바이트 이상의 데이터가 저장되어 있으며, ci_builds.yaml_variables에는 2021년 2월 기준으로 300기가바이트 이상의 데이터가 저장되어 있습니다.

이는 신뢰할 수 있는 백그라운드 마이그레이션이 현재 우리의 데이터 규모에서 이러한 데이터를 이동하는 데 신뢰할 만한 메커니즘을 제공하지 않습니다. 이 데이터를 열 또는 테이블, 파티션 또는 데이터베이스 샤드 간에 안전하게 이동시킬 수 있는 메커니즘을 구축해야 합니다.

백그라운드 마이그레이션을 개선하기 위한 노력은 우리 데이터베이스 팀이 진행할 것입니다.

상태: 진행 중. 별도의 아키텍처 청사진에서 설명할 추가적인 개선사항을 ship할 계획입니다.

제안

아래에서 우리의 CI Scaling 노력을 전개하는 방법에 대한 초기 2021년 제안 원본을 찾을 수 있습니다:

GitLab CI/CD 제품을 예상되는 향후 규모에 맞게 준비하는 것은 여러 단계의 노력입니다.

먼저, 지금 긴급히 필요한 사항에 집중하고 싶습니다. 기본 키 오버플로 위험을 해결하고 데이터베이스 파티셔닝 및 샤딩 작업을 진행 중인 다른 팀을 언블록해야 합니다.

대기 중인 빌드 큐 메커니즘과 같은 알려진 병목 현상을 개선하고, 다른 팀의 발전을 방해하는 다른 사항을 해결해야 합니다.

CI/CD 메트릭스 확장은 시스템의 성능과 예상 성장에 대한 더 나은 감각을 얻는 데 중요합니다. 이를 통해 병목 현상을 식별하고 더 고급화된 용량 계획을 수행할 수 있습니다.

다음 단계는 CI/CD 데이터의 강력한 시간 감소 특성을 어떻게 활용할 수 있는지에 대한 방법을 더 잘 이해하는 것입니다. 이것은 CI/CD 데이터 집합을 파티셔닝하여 CI/CD 데이터베이스 테이블의 크기를 줄이는 데 도움이 될 수 있습니다.

반복

다음 CI/CD 확장 목표를 달성하기 위한 작업은 CI/CD Scaling epic에서 추적됩니다.

1. ✓ GitLab.com에서 기본 키를 큰 정수로 이전합니다.
2. ✓ GitLab.com에서 빌드 대기열의 새로운 아키텍처를 구현합니다.
3. ✓ 새로운 빌드 대기열 아키텍처를 일반 사용 가능하게 만듭니다.
4. 시간 경과 패턴을 사용하여 CI/CD 데이터를 분할.

상태

2021년 1월 21일에 생성되었으며, 2021년 4월 26일에 승인되었습니다.

Status: 진행 중.

담당자

제안:

DRI(Directly Responsible Individual):

도메인 전문가: