• 요약
• 목표
• 도전과제
  • 주요 키 저장용량이 부족: 완료
  • 일부 CI/CD 데이터베이스 테이블이 너무 큼: 진행 중
  • 큐 메커니즘이 큰 테이블을 사용: 완료
  • 대량의 데이터를 이동하는 것은 도전적입니다: 진행 중
• 제안
• 반복
• 상태
• 담당자

CI/CD 확장

요약

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

GitLab CI/CD는 초기 릴리스 이후 많은 발전을 거듭해왔지만, 파이프라인 빌드의 데이터 저장 설계는 2012년 이후로 거의 변하지 않았습니다. 우리는 모든 빌드를 ci_builds 테이블에 PostgreSQL에 저장하고 있으며, GitLab.com에서 하루에 5백만 건 이상의 빌드를 생성하고 있어서 개발 속도가 떨어지는 데이터베이스 제한에 도달하고 있습니다.

2021년 2월 1일, GitLab.com에서 생성된 CI/CD 빌드 수가 10억 건을 넘었습니다. 2022년 2월에는 데이터베이스에 20억 건의 CI/CD 빌드가 저장되었습니다. 빌드 수는 계속해서 급격하게 증가하고 있습니다.

아래 스크린샷은 2021년 초에 작성된 예측을 보여줍니다.

목표

미래의 성장을 지원하여 하루에 20백만 개의 빌드 처리가 가능하도록 만들기.

도전과제

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

주요 키 저장용량이 부족: 완료

ci_builds 테이블의 주요 키는 시퀀스에서 생성된 정수 값입니다. 과거에는 Rails에서 테이블의 기본 키로 정수 유형을 사용했습니다. 우리는 2012년에 ci_builds 테이블을 생성할 때 기본값을 사용했습니다. Rails의 동작이 변경된 이후로, 프레임워크는 지금은 8바이트인 ‘bigint’ 유형을 사용하고 있지만, 아직 ci_builds 테이블의 주요 키를 ‘bigint’로 마이그레이션하지 않았습니다.

2021년 초, 우리는 ci_builds 테이블에서 주요 키를 저장하는 데 사용되는 정수 유형의 용량이 2021년 12월 이전에 고갈될 것으로 추정했습니다. 심각한 문제 없이 이런 일이 발생했다면, GitLab.com은 다운될 것이었습니다. ci_builds는 초기화 시퀀스에서 사용할 수 있는 기본 키가 부족했던 많은 테이블 중 하나였습니다.

2021년 10월 이전에 우리의 데이터베이스 팀은 모든 위험한 테이블의 주요 키를 큰 정수로 마이그레이션했습니다.

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

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

ci_builds 테이블에 20억 건 이상의 행이 있습니다. 그 테이블에는 수 테라바이트의 데이터가 저장되어 있으며, 인덱스의 총 크기도 수테라바이트로 메트릭됩니다.

이 데이터 양은 우리의 CI PostgreSQL 데이터베이스에서 발생하는 많은 성능 문제에 기여합니다.

대부분의 문제는 PostgreSQL 데이터베이스가 내부적으로 작동하는 방식과 노드에서 데이터베이스를 실행하는 데 사용되는 리소스를 어떻게 활용하는지와 관련이 있습니다. 우리는 CI 기본 데이터베이스 노드의 수직적 확장 한계에 도달하고 있으며, ci_builds 테이블이 CI 데이터베이스의 전반적인 성능, 안정성, 확장 가능성 및 예측 가능성에 부정적인 영향을 미치는 경우가 빈번합니다.

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

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

우리는 또한 향후 수년간 크게 지수적으로 성장할 것으로 예상하고 있습니다.

페이스북의 Prophet을 사용하여 수행한 예측 중 하나에 따르면, 2024년 상반기에는 GitLab.com에서 하루에 2000만 건의 빌드가 생성될 것으로 예상됩니다. 현재까지 약 500만 건을 볼 수 있기 때문에 2021년에 본 수치 대비 10배의 성장이 예상됩니다.

상태: 2021년 10월에 ci_builds 테이블의 성장 속도를 줄이기 위해 빌드 옵션 및 변수를 ci_builds_metadata 테이블에 작성했습니다. 또한 시간 감소 패턴을 사용하여 가장 큰 CI/CD 데이터베이스 테이블을 분할하고 있습니다.

큐 메커니즘이 큰 테이블을 사용: 완료

테이블이 매우 크기 때문에 작업 대기중인 빌드를 큐로 만드는 메커니즘(두 개 이상의 대기열이 있음)이 효율적이지 않았습니다. 대기 중인 빌드는 ci_builds 테이블에 저장된 것들 중에서 작은 비율을 차지했지만, 우리는 이들을 찾아내어 원하는 순서대로 처리하기 위해서 이 방대한 데이터 세트에서 찾아야 했습니다.

이 메커니즘은 매우 비효율적이었으며, 이로 인해 운영 환경에서 문제가 빈번하게 발생했습니다. 이로 인해 CI/CD Apdex 점수가 크게 감소되었으며 때로는 운영 환경의 성능 저하를 초래하기도 했습니다.

성능과 신뢰성을 향상시키기 위해 고려했던 여러 가지 전략이 있었습니다. 우리는 Redis 대기열을 사용할지, 또는 대기열을 작성하는데 사용되는 SQL 쿼리를 가속화하는 별도의 테이블을 사용할지를 평가했습니다. 우리는 후자를 선택하기로 결정했습니다.

2021년 10월에 우리는 새로운 빌드 대기열 아키텍처를 GitLab.com에 배포했습니다. 그리고 그 새로운 아키텍처를 일반적으로 사용가능하게 만들었습니다.

대량의 데이터를 이동하는 것은 도전적입니다: 진행 중

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

신뢰할 수 있는 다른 곳으로 이동해야 하는 대량의 데이터가 있습니다. 안타깝게도 현재 우리의 배경 마이그레이션이 이러한 규모의 데이터를 신뢰할 만큼 확실히 변이시키지 못하고 있습니다. 이 데이터를 열, 테이블, 파티션 또는 데이터베이스 샤드 간에 이동하는 데 확신을 주는 메커니즘을 구축해야 합니다.

배경 마이그레이션을 개선하는 노력은 저희 데이터베이스 팀이 담당할 것입니다.

상태: 진행 중. 별도의 아키텍처 블루프린트에 설명된 추가 개선 사항을 제공할 계획입니다.

제안

아래에서는 2021년 초에 제안된 CI Scaling 노력에 대한 원본 제안을 찾을 수 있습니다.

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

먼저, 현재 긴급하게 필요한 것에 중점을 두고 싶습니다. 주요 키 오버플로우 리스크를 수정하고 데이터베이스 파티셔닝 및 샤딩에 작업 중인 다른 팀들의 막힘을 해제해야 합니다.

빌드 대기 메커니즘과 같이 알려진 병목 현상을 개선하고 다른 팀들을 막고 있는 다른 요소들을 해소해야 합니다.

CI/CD 메트릭스를 확장하는 것은 시스템 성능을 더 잘 이해하고 어떤 성장을 기대해야 하는지에 대한 더 나은 감을 얻는 데 중요합니다. 이렇게 하면 병목 현상을 식별하고 고급 용량 계획을 세우는 것이 더 쉬워집니다.

다음 단계는 CI/CD 데이터의 강력한 시간 감소 특성을 어떻게 활용할 수 있는지 더 잘 이해하는 것입니다. 이를 통해 CI/CD 데이터셋을 분할하여 CI/CD 데이터베이스 테이블의 크기를 줄일 수 있을지도 모릅니다.

반복

다음 CI/CD 스케일링 대상을 달성하기 위해 필요한 작업은 CI/CD 스케일링 에픽에서 추적됩니다.

1. ✓ GitLab.com에서 주요 키를 큰 정수로 마이그레이션합니다.
2. ✓ GitLab.com에 새로운 빌드 대기 아키텍처를 구현합니다.
3. ✓ 새로운 빌드 대기 아키텍처를 일반적으로 사용 가능하게 만듭니다.
4. 시간 감소 패턴을 사용하여 CI/CD 데이터를 분할합니다.

상태

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

Status: 진행 중.

담당자

제안:

DRI(Directly Responsible Individual):

도메인 전문가: