| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| ongoing |
@grzesiek
|
@ayufan
@grzesiek
|
@jporter
@cheryl.li
| devops verify | 2021-09-10 |
CI/CD 데이터 시간 감소
개요
GitLab CI/CD는 GitLab의 가장 데이터 집약적이고 계산 집약적인 컴포넌트 중 하나입니다. 2012년 초기 릴리스 이후 CI/CD 서브시스템은 크게 발전했습니다. 2015년 9월 GitLab에 통합되었으며 가장 사랑받는 CI/CD 솔루션 중 하나가 되었습니다.
2021년 2월 1일, GitLab.com은 10억 개의 CI/CD 빌드를 돌파했으며, 빌드 수는 지수 함수적으로 계속 증가하고 있습니다.
GitLab CI/CD는 초기 릴리스 이후 많은 발전을 거쳤지만, 파이프라인 빌드를 위한 데이터 리포지터리 디자인은 2012년 이후 거의 같은 상태를 유지하고 있습니다. 2021년에는 데이터베이스 분해 및 CI/CD 데이터를 별도의 데이터베이스로 추출하는 작업을 시작했습니다. 이제 GitLab CI/CD 제품의 아키텍처를 개선하여 추가적인 확장이 가능하도록 하려고 합니다.
목표
스케일링을 가능케 하는 CI/CD 데이터 리포지터리의 새로운 아키텍처 구현.
도전과제
GitLab.com의 데이터베이스에는 CI/CD 빌드를 설명하는 20억 개 이상의 행이 있습니다. 이 데이터는 GitLab.com에서 실행되는 PostgreSQL 데이터베이스에 저장된 전체 데이터의 상당한 부분을 나타냅니다.
이 볼륨은 중요한 성능 문제, 개발 도전과제에 기여하며 종종 운영 사건과 관련이 있습니다.
또한 GitLab.com에서 실행되는 빌드 수의 중요한 증가가 예상됩니다.
기회
CI/CD 데이터는 일반적으로 시간 감소의 대상입니다. 보통 몇 달이 지난 파이프라인은 더 이상 자주 액세스되지 않거나 관련이 없을 수 있습니다. 몇 달 전에 생성된 파이프라인을 처리하는 액세스를 제한하면 이러한 데이터를 주 데이터베이스에서 더 효율적이고 비용 효율적인 다른 리포지터리로 이동시킬 수 있을 것입니다.
이미 보관된 빌드를 처리하는 것을 방지하는 것은 가능합니다. 빌드가 보관될 경우 다시 시도할 수 없지만, 여전히 데이터베이스에 모든 처리 메타데이터가 유지되어 있으며 주 데이터베이스에는 부족한 리소스를 차지합니다.
성능을 향상시키고 CI/CD 데이터 리포지터리의 확장을 쉽게 하기 위해 아래에 설명된 세 가지 전략을 따르는 것이 좋습니다.
- CI/CD 빌드 대기열 데이터베이스 테이블을 파티션화합니다.
- CI/CD 파이프라인 데이터베이스 테이블을 파티션화합니다.
- 빌드 메타데이터 테이블 성장 속도를 감소합니다.
빌드 메타데이터 테이블 성장 속도를 감소합니다
빌드(또는 파이프라인)가 아카이브되면 해당 파이프라인에서는 더 이상 파이프라인 처리를 재개할 수 없습니다. 즉, 효율적이고 신뢰할 수 있는 빌드 처리에 필요한 PostgreSQL에 저장하는 모든 메타데이터는 안전하게 다른 데이터 리포지터리로 이동할 수 있습니다.
파이프라인 처리 데이터를 저장하는 것은 CI/CD 테이블에 저장된 데이터의 상당한 부분을 나타내므로 비용이 많이 듭니다. 보관된 파이프라인 처리에 대한 액세스를 제한하면 이러한 메타데이터를 다른 위치(가능한 경우 객체 리포지터리)로 이동하고 필요할 때에만(예: 준수 또는 감사 목적) 실제로 필요할 때에만 액세스할 수 있도록 할 수 있습니다.
데이터를 이동하는 것이 가장 최적의 솔루션인지를 평가해야 합니다. 이 데이터 세트를 쿼리할 수 있는 능력을 유지하면서 저장 공간을 사용하도록 메타데이터 항목을 중복 저장 및 다른 정규화 전략을 사용할 수도 있습니다. 최적의 솔루션을 찾기 위해 기술적 평가가 필요할 것입니다.
CI/CD 파이프라인 데이터베이스 테이블을 파티션화하기
CI/CD 메타데이터를 다른 리포지터리로 이동하거나 메타데이터 성장률을 다른 방식으로 줄인다 하더라도, 파이프라인, 빌드 및 아티팩트를 설명하는 수십억 개의 행 문제는 여전히 남아 있습니다. 우리는 여전히 객체 리포지터리에 저장할 메타데이터에 대한 참조를 유지해야 하며, 이에 대해 신뢰할 수 있는 방대한 정보를 검색할 수 있어야 합니다.
데이터를 객체 리포지터리로 이동하면 데이터 크기를 줄이는 데 도움이 될 것입니다. 그러나 데이터를 설명하는 항목 수를 줄일 수는 없을 것입니다. 이러한 제한으로 인해 CI/CD 테이블의 행 수를 줄일 수 없지만, 데이터 크기를 줄이는 데 도움이 될 것입니다. 따라서 데이터베이스에 미치는 영향(인덱스 크기, 자동 진공 시간 및 빈도)을 줄이기 위해 CI/CD 데이터를 파티션화하고 싶습니다.
우리의 의도는 이 데이터를 주 데이터베이스에서 다른 곳으로 이동시키는 것이 아닌 CI/CD 데이터를 저장하는 매우 큰 데이터베이스 테이블을 PostgreSQL의 파티셔닝 기능을 사용하여 여러 개의 더 작은 테이블로 나누려는 것입니다.
CI/CD 데이터를 파티션화하는 데 사용할 수 있는 몇 가지 방법이 있습니다. 그 중 하나는 파이프라인에 파티션 번호를 지정하고 이 파티션이 관련 있는 모든 리소스로 전파되는 리스트 기반 파티셔닝입니다. 필요에 따라 이러한 파티셔닝 전략을 자유롭게 확장할 수 있으므로 응용 프로그램 수준에서 시간 감소 기반 파티셔닝을 테넌트 기반 파티셔닝과 결합하여 임의의 파티션 번호를 할당할 수 있습니다.
액세스가 드물게 있는 데이터를 파티션화할 때 빌드 아카이브에 정의된 정책을 따라 일관되고 신뢰할 수 있게 만들어야 합니다.
에픽: CI/CD 파이프라인 데이터베이스 테이블을 파티션화.
이 주제에 대한 더 자세한 기술 정보는 파이프라인 데이터 파티셔닝 디자인을 참조하세요.
CI/CD 빌드 큐 데이터베이스 테이블을 파티션화하기
CI/CD Scale 청사진을 작업하는 동안, 실행을 준비하면서도 CI/CD 빌드를 대기열에 넣는 새로운 아키텍처를 소개했습니다. 이를 통해 성능을 크게 개선했습니다. 여전히 이 새로운 솔루션을 다음 반복 작업을 시작하기 전에 필요한 중간 메커니즘으로 여기고 있습니다. 빌드 대기열 아키텍처를 더 개선하는 다음 반복 작업은 PostgreSQL에서 완전히 또는 부분적으로 이동해야 할 수도 있겠습니다.
그 동안, 더 유연하고 안정적인 솔루션을 위한 중간 단계로 다른 반복을 출시하고자 합니다. 새로운 대기열 테이블을 파티션화하여 데이터베이스에 미치는 영향을 줄이고 신뢰성 및 데이터베이스 건강을 향상하고자 합니다.
CI/CD 대기열 테이블의 파티션화는 빌드 아카이브에 정의된 정책을 따를 필요는 없습니다. 대신에 24시간 이상 전에 생성된 빌드가 대기열에서 제거되어야 한다는 고정된 정책을 활용해야 합니다. GitLab CI의 시작부터 존재하는 비즈니스 규칙입니다.
에픽: CI/CD 빌드 큐 데이터베이스 테이블 파티션화.
이 주제에 대한 더 자세한 기술 정보는 파이프라인 데이터 파티셔닝 디자인을 참조하세요.
원칙
CI/CD 시간 감소 패턴을 구현하는 데 사용할 세 가지 전략은 일부 도전과제와 관련이 있습니다. 우리가 진행하면서 많은 문제를 해결하고 이를 성공적으로 만들기 위해 많은 구현 세부 정보를 고안해야 할 것입니다.
아래에서는 이 아키텍처 청사진에서 설명한 비전을 모두가 쉽게 이해할 수 있도록 몇 가지 기본 원칙을 문서화했습니다.
파이프라인 데이터 제거
과거 또는 보관된 데이터를 데이터베이스에서 제거하는 것이 유혹적일 수 있지만, 피하는 것이 좋습니다. 일반적으로 사용자의 동의가 없는 경우 사용자 데이터를 영구적으로 제거하는 것은 원치 않는 경우가 많습니다. 그러나 객체 리포지터리와 같은 다른 데이터 리포지터리로 데이터를 이동할 수는 있습니다.
보관된 데이터는 때로 필요할 수 있습니다(예: 규정 준수 또는 감사). 사용자가 영구적인 삭제를 요청하거나 승인하지 않은 한 필요에 따라 데이터를 검색할 수 있어야 합니다.
UI에서 파이프라인 데이터에 접근
CI/CD 데이터의 시간 감소를 파티션화를 통해 구현하는 것은 여러 파티션에 저장된 데이터에 여전히 접근할 수 있도록 하고자 할 때 도전적일 수 있습니다.
UI에서 파이프라인 데이터에 액세스하는 간단함을 유지하고자 합니다. 다른 리소스에서 파이프라인 데이터를 참조하는 방법에 대한 조금의 백스테이지 변경이 필요할 것이지만, UI에서 사용자가 자신의 파이프라인을 찾는 것을 더 어렵게 만들고 싶지는 않습니다.
파이프라인/빌드 디렉터리 페이지에 “보관됨” 탭을 추가해야 할 수도 있지만, 누군가가 파이프라인 상태를 보거나 Merge Request 또는 배포와 관련된 빌드를 보고 싶어할 때 추가 단계/클릭을 피할 수 있어야 합니다.
파이프라인/빌드 디렉터리 페이지의 “보관됨” 탭에서 검색을 비활성화해야 할 수도 있습니다.
API를 통한 파이프라인 데이터에 액세스
파이프라인 데이터에 액세스하기 위해 별도의 API 엔드포인트/엔드포인트를 구축해야 할 필요성을 인정합니다.
새 API에서 사용자는 생성된 데이터의 시간 범위를 제공하여 파이프라인/빌드를 검색해야 할 수 있습니다. 효율적으로 하기 위해서 두 개 이상의 파티션에 거주하는 데이터에 대한 쿼리 액세스를 제한하는 것이 필요할 수 있습니다. 빌드 보관 정책과 동일한 기간을 가진 시간 범위를 지원함으로써 이를 수행할 수 있습니다.
구형 API를 사용하여 보관된 파이프라인 데이터에 액세스할 수 있도록 허용하는 것도 가능하지만, 사용자 제공 파티션 식별자가 필요할 수 있습니다.
반복
모든 세 가지 트랙은 동시에 작업할 수 있습니다:
상태
진행 중.
일정
- 2021-01-21: 부모 CI 확장 설계도 Merge Request 생성.
- 2021-04-26: CI 확장 설계도가 승인되어 Merge됨.
- 2021-09-10: CI/CD 데이터 시간 감소 설계도 토의 시작.
- 2022-01-07: CI/CD 데이터 시간 감소 설계도 Merge.
- 2022-02-01: 설계도가 새 콘텐츠 및 에픽에 대한 링크로 업데이트됨.
- 2022-02-08: 파이프라인 파티션화 PoC Merge Request 시작.
- 2022-02-23: 파이프라인 파티션화 PoC가 성공적으로 완료됨.
- 2022-03-07: 기존 테이블을 파티션으로 첨부할 수 있는 방법 발견 및 증명.
- 2022-03-23: 파이프라인 파티션화 설계 Google 문서(GitLab 내부)가 시작됨:
https://docs.google.com/document/d/1ARdoTZDy4qLGf6Z1GIHh83-stG_ZLpqsibjKr_OXMgc. - 2022-03-29: 파이프라인 파티션화 PoC가 종결.
- 2022-04-15: 파티션된 파이프라인 데이터 연결 PoC가 배포됨.
- 2022-04-30: 추가 벤치마킹이 시작되어 영향을 평가함.
- 2022-06-31: 파이프라인 파티션화 설계 문서 Merge Request가 Merge됨.
- 2022-09-01: 파티션화를 구현하기 위한 엔지니어링 노력이 시작됨.
- 2022-11-01: 가장 빠르게 성장하는 CI 테이블 파티션화됨:
ci_builds_metadata. - 2023-06-30: 두 번째로 큰 테이블이 파티션화됨:
ci_builds. - 2023-12-12:
ci_builds및ci_builds_metadata성장이 새 파티션에 데이터를 쓰는 것으로 중단됨. - 2024-02-05:
ci_pipeline_variables가 파티션화됨. - 2024-03-26:
ci_job_artifacts가 파티션화됨. - 2024-04-26:
ci_stages가 파티션화됨.