| 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 메타데이터를 다른 리포지터리로 이동하거나 메타데이터 성장률을 다르게 줄이더라도, 파이프라인, 빌드 및 artifact를 설명하는 수십억 개의 행이 있는 문제는 여전히 남아 있습니다. 우리는 여전히 객체 리포지터리에 저장할 수 있는 메타데이터에 대한 참조를 유지해야 할 수 있으며, 이 정보를 신뢰할 수 있도록 대량으로 검색할 수 있어야 합니다.
즉, 데이터를 객체 리포지터리로 이동하여 데이터 크기를 줄일 수 있지만, 이 데이터를 설명하는 항목의 수를 줄일 수는 없을 것입니다. 이러한 제한으로 인해 여전히 CI/CD 데이터를 파티션으로 나눌 필요가 있습니다 (색인 크기, auto-vacuum 시간 및 빈도 등 데이터베이스 영향을 줄이기 위해).
우리의 목적은 이 데이터를 주 데이터베이스에서 다른 곳으로 옮기는 것이 아닙니다. 주 데이터베이스에 저장된 CI/CD 데이터를 나타내는 매우 큰 데이터베이스 테이블을 여러 개의 더 작은 테이블로 분할하려고 합니다. PostgreSQL 파티션 기능을 사용하여 분할하는 여러 가지 접근 방법을 취할 수 있습니다. 가능성이 있는 접근 방법 중 하나는 파티션 번호가 파이프라인에 할당되어 해당 파이프라인과 관련된 모든 리소스로 전달되는 디렉터리 기반 파티셔닝을 사용하는 것입니다. 균일한 논리 파티션 ID 사용하여 파티션 번호를 할당할 수 있으므로 이 파티셔닝 전략을 필요에 따라 유연하게 확장할 수 있습니다. 예를 들어 이 전략을 사용하면 시간 감쇠 기반 파티셔닝과 응용 프로그램 수준에서 테넌트 기반 파티셔닝을 결합하여 임의의 파티션 번호를 할당할 수 있습니다. 하지만 파티셔닝이 거의 액세스되지 않는 데이터는 빌드 아카이브에 정의된 정책에 따라 일관되고 신뢰할 수 있도록 해야 합니다.
에픽: CI/CD 파이프라인 데이터베이스 테이블 파티션.
이 주제에 대한 더 많은 기술적 세부 정보는 파이프라인 데이터 파티셔닝 설계를 참조하십시오.
CI/CD 빌드 대기열 데이터베이스 테이블 파티션
CI/CD Scale 청사진을 작업하는 동안, 실행을 위해 새로운 빌드 대기 엔진 아키텍처를 도입했습니다.
이로써 성능을 크게 향상시킬 수 있었습니다. 우리는 여전히 새로운 솔루션이 시작되기 전에 필요한 중간 기구로 여기며, 빌드 대기열 아키텍처를 더 개선해야 할 다음 반복을 고려했습니다(이는 PostgreSQL을 완전히 또는 부분적으로 이탈할 수 있음).
한편, 우리는 더 유연하고 신뢰할 수 있는 솔루션으로의 중간 단계로 다른 반복을 발송하고자 합니다. 우리는 새로운 대기열 테이블을 파티션하고 데이터베이스에 미칠 영향을 줄이고 신뢰성을 향상시키기 위해 준비 중입니다.
CI/CD 대기열 테이블을 파티션화하는 것은 빌드 아카이브에 정의된 정책을 따라 강제로 제거해야 하는 빌드가 만들어낼 필요가 없습니다. 이 비즈니스 규칙은 GitLab CI 출시 초기부터 제품에 존재합니다.
에픽: CI/CD 빌드 대기열 데이터베이스 테이블 파티션.
이 주제에 대한 더 많은 기술적 세부 정보는 파이프라인 데이터 파티셔닝 설계를 참조하십시오.
원칙
CI/CD 시간 감소 패턴을 구현하기 위해 사용할 세 가지 트랙은 모두 일부 문제와 관련이 있습니다. 우리가 구현을 진행함에 따라 많은 문제를 해결하고, 이를 성공적으로 만들기 위해 많은 구현 세부 사항을 고안해야 할 것입니다.
아래에서 이 구조적 청사진에 기술된 비전을 모두가 이해하기 쉽도록 만들기 위해 몇 가지 기본적인 원칙을 문서화했습니다.
파이프라인 데이터 제거
과거 데이터나 보관된 데이터를 데이터베이스에서 제거하는 것이 유혹적일 수 있지만, 이는 피해야 합니다. 사용자의 동의가 없는 한 사용자 데이터를 영구적으로 제거하는 것은 일반적으로 원치 않는 것입니다. 그러나 데이터를 객체 리포지터리와 같은 다른 데이터 리포지터리로 이동하는 것은 가능합니다.
보관된 데이터는 때때로 필요할 수 있습니다(예: 규정 준수 또는 감사를 위해). 사용자로부터 영구적으로 제거 요청이나 사용자의 승인을 받지 않은 한 필요 시 이러한 데이터를 검색할 수 있기를 원합니다.
UI에서 파이프라인 데이터에 액세스
파티션을 통한 CI/CD 데이터 시간 감소를 구현하는 것은 여러 파티션에 저장된 데이터에 여전히 액세스할 수 있도록 하려면 어려울 수 있습니다.
UI에서 파이프라인 데이터에 액세스하는 간단함을 유지하고자 합니다. 다른 리소스에서 파이프라인 데이터를 참조하는 방식에 대한 몇 가지 뒷단 변경이 필요할 것이지만, 사용자가 UI에서 자신의 파이프라인을 찾기 어렵게 만들고 싶지는 않습니다.
파이프라인 상태나 머지 요청 또는 배포와 관련된 빌드를 보고자 할 때 추가적인 단계나 클릭을 피할 수 있어야 합니다.
또한 파이프라인/빌드 디렉터리 페이지의 “보관됨” 탭에 대한 검색을 비활성화해야 할 수도 있습니다.
API를 통한 파이프라인 데이터에 액세스
API를 통한 파이프라인 데이터에 액세스할 필요가 있다는 가능성을 받아 들입니다.
새 API에서는 사용자가 파이프라인/빌드를 검색할 때 데이터가 생성된 시간 범위를 제공해야 할 수 있습니다. 이를 효율적으로 만들기 위해 한 번에 두 개 이상의 파티션에 걸쳐 있는 데이터에 대한 액세스를 제한해야 할 수도 있을 것입니다. 이를 지원하기 위해 빌드 보관 정책과 같은 기간을 갖는 시간 범위를 지원할 수 있습니다.
또한 사용자가 이전 API를 사용하여 보관된 파이프라인 데이터에 액세스할 수 있도록 할 수는 있으나 사용자가 파티션 식별자를 제공해야 할 수 있습니다.
반복
세 가지 트랙은 병행하여 작업할 수 있습니다.
상태
진행 중.
타임라인
- 2021-01-21: CI Scaling 부모 청사진 Merge Request 생성됨.
- 2021-04-26: CI 스케일링 청사진 승인 및 Merge됨.
- 2021-09-10: CI/CD 데이터 시간 감소 청사진 논의 시작.
- 2022-01-07: CI/CD 데이터 시간 감소 청사진 Merge.
- 2022-02-01: 새로운 내용과 epic 링크로 청사진 업데이트.
- 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가 파티션화됨.