| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| ongoing |
@grzesiek
|
@grzesiek
|
@cheryl.li
@jreporter
| devops verify | 2021-01-21 |
CI/CD 확장
요약
GitLab CI/CD는 GitLab의 가장 데이터 밀도가 높고 계산 집약적인 구성 요소 중 하나입니다. 2012년 최초 릴리스 이후 CI/CD 하위 시스템은 크게 발전했습니다. 또한 2015년 9월에 GitLab에 통합되었으며 가장 사랑받는 CI/CD 솔루션 중 하나가 되었습니다.
GitLab CI/CD는 최초 릴리스 이후 많은 변화를 겪었지만, 파이프라인 빌드의 데이터 저장소 설계는 2012년 이후 거의 변화가 없습니다. 우리는 모든 빌드를 PostgreSQL의 ci_builds 테이블에 저장하고 있으며, GitLab.com에서 하루에 500만 건 이상의 빌드를 생성하고 있기 때문에 개발 속도를 저해하는 데이터베이스 제한에 도달하고 있습니다.
2021년 2월 1일, GitLab.com에서 생성된 CI/CD 빌드가 10억 건을 돌파했습니다. 2022년 2월에는 데이터베이스에 저장된 CI/CD 빌드 수가 20억 건을 돌파했습니다. 빌드 수는 계속해서 지수적으로 증가하고 있습니다.
아래 스크린샷은 2021년 초에 작성된 예측을 보여주는데, 이는 매우 정확했습니다.
목표
하루에 2천만 번의 빌드 처리가 가능하도록 미래 성장을 지원합니다.
도전과제
미래 성장을 지탱하기 위해 현재의 CI/CD 제품 아키텍처 상태를 업데이트해야 합니다.
기본 키 저장 용량이 부족한 상태: 완료
ci_builds 테이블의 기본 키는 시퀀스에서 생성된 정수값입니다. 과거에는 Rails가 테이블의 기본 키로 정수 유형을 사용했었습니다. 2012년에 ci_builds 테이블을 생성할 때 기본 값을 사용했었고 Rails의 동작은 Rails 5 릴리스 이후로 변경되었습니다. 이 프레임워크는 이제 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’s Prophet를 사용하여 수행한 예측 중 하나에 따르면, 2024년 상반기에는 GitLab.com에서 하루에 2000만 번의 빌드가 생성될 것으로 예상됩니다. 현재의 500만 개에서 약 10배 증가할 것으로 예상됩니다.
현황: 2021년 10월 기준으로, ci_builds 테이블의 성장 속도를 줄이기 위해 빌드 옵션 및 변수를 ci_builds_metadata 테이블에 기록했습니다. 또한 시간 감쇠 패턴을 사용하여 가장 큰 CI/CD 데이터베이스 테이블을 파티셔닝 작업 중입니다.
대규모 테이블 사용 중인 대기 메커니즘: 완료
테이블의 크기 때문에 사용된 대기 빌드의 대기열을 구축하는 메커니즘이 (대기열이 하나 이상 있음) 효율적이지 못했습니다. 보류 중인 빌드는 ci_builds 테이블에 저장된 내용의 작은 부분을 나타내지만, 이러한 빌드를 처리하기 위해 순서를 결정하기 위해 이 방대한 데이터 세트에서 찾아야 했습니다.
이 메커니즘은 매우 비효율적이었으며, 종종 프로덕션 환경에서 문제를 일으켰습니다. 이로 인해 일반적으로 CI/CD Apdex 점수가 상당히 떨어지고 때로는 프로덕션 환경에서 성능 저하가 발생하기도 했습니다.
성능 및 신뢰성을 개선하기 위해 여러 가지 전략을 검토했습니다. Redis 대기열을 사용하거나 대기열을 구축하는 데 사용된 SQL 쿼리를 가속화할 수 있는 별도의 테이블을 사용하는 것을 평가했습니다(https://gitlab.com/gitlab-org/gitlab/-/issues/322766). 후자를 선택하기로 결정했습니다.
2021년 10월에 대기열 새 아키텍처의 배포를 마쳤습니다. GitLab.com. 그런 다음 새 아키텍처를 일반 사용 가능하게 만들었습니다.
대규모 데이터 이동은 도전적임: 진행중
ci_builds 테이블에 상당한 양의 데이터를 저장합니다. 이 테이블의 일부 열은 직렬화된 사용자 제공 데이터를 저장합니다. ci_builds.options 열은 600GB 이상의 데이터를 저장하고, ci_builds.yaml_variables는 2021년 2월 기준으로 300GB 이상의 데이터를 저장합니다.
신뢰할 수 있는 방법으로 많은 양의 데이터를 다른 위치로 이동해야 합니다. 아쉽게도, 현재 백그라운드 마이그레이션이 이러한 규모의 데이터를 대규모로 이동하는 데 충분히 신뢰할 수 있는 상태가 아닙니다. 데이터를 열, 테이블, 파티션 또는 데이터베이스 샤드 간에 이동하기에 필요한 메커니즘을 구축해야 합니다.
백그라운드 마이그레이션을 개선하기 위한 노력은 데이터베이스 팀에 의해 이뤄질 것입니다.
상태: 진행중. 별도의 아키텍처 청사진에 설명된 추가적인 개선을 배포할 계획입니다.
제안
아래에서는 2021년 초에 제안된 원래의 CI 확장 노력에 대한 내용을 찾을 수 있습니다.
예상되는 미래 규모에 맞게 GitLab CI/CD 제품을 준비하는 것은 다단계 노력입니다.
먼저, 지금 긴급하게 필요한 것에 초점을 맞추려고 합니다. 기본 키 오버플로우 위험을 수정하고 데이터베이스 분할 및 샤딩 작업을 진행 중인 다른 팀들을 막지 않는 것이 필요합니다.
빌드 대기열 메커니즘과 같은 알려진 병목 현상을 개선하고 다른 팀들을 막고 있는 것 등을 해결하려고 합니다.
CI/CD 지표를 확장하는 것은 시스템의 성능과 예상되는 성장에 대한 더 나은 감을 얻는 데 중요합니다. 이를 통해 병목 현상을 식별하고 더 고급 용량 계획을 수행하는 것이 더 쉬워집니다.
다음 단계는 CI/CD 데이터의 강력한 시간 감소 특성을 어떻게 활용할지에 대한 이해를 더욱 개선하는 것입니다. 이는 CI/CD 데이터 집합을 분할하여 CI/CD 데이터베이스 테이블의 크기를 줄이는 데 도움이 될 수 있습니다.
반복
다음 CI/CD 확장 목표를 달성하기 위해 필요한 작업은 CI/CD 확장 에픽에서 추적됩니다.
- ✓ GitLab.com에서 기본 키를 큰 정수로 마이그레이션
- ✓ GitLab.com에서 새로운 빌드 대기열 아키텍처 구현
- ✓ 새로운 빌드 대기열 아키텍처를 일반 사용 가능하게 만든다.
- 시간 감소 패턴을 사용하여 CI/CD 데이터 분할.
상태
2021년 1월 21일에 생성, 2021년 4월 26일에 승인됨.
상태: 진행중.
담당자
제안:
| 역할 | 담당자 |
|---|---|
| 저자 | Grzegorz Bizon |
| 아키텍처 진화 코치 | Kamil Trzciński |
| 공학 리더 | Cheryl Li |
| 제품 매니저 | Jackie Porter |
| 도메인 전문가 / Verify | Fabio Pitino |
| 도메인 전문가 / 데이터베이스 | Jose Finotto |
| 도메인 전문가 / PostgreSQL | Nikolay Samokhvalov |
주요 책임자:
| 역할 | 담당자 |
|---|---|
| 리더십 | Cheryl Li |
| 제품 | Jackie Porter |
| 공학 | Grzegorz Bizon |
도메인 전문가:
| 영역 | 담당자 |
|---|---|
| 도메인 전문가 / Verify | Fabio Pitino |
| 도메인 전문가 / Verify | Marius Bobin |
| 도메인 전문가 / 데이터베이스 | Jose Finotto |
| 도메인 전문가 / PostgreSQL | Nikolay Samokhvalov |