| 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년에 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억 건 이상의 레코드가 있습니다. 이 데이터는 PostgreSQL 데이터베이스에 저장된 전체 데이터의 상당 부분을 나타냅니다.
이 양은 중요한 성능 문제, 개발의 어려움에 기여하며 종종 프로덕션 인시던트와 관련이 있습니다.
또한, GitLab.com에서 실행되는 빌드 수의 중요한 증가가 예상됩니다.
기회
CI/CD 데이터는 보통 몇 달이 지난 파이프라인은 더 이상 빈번하게 액세스되지 않거나 더는 관련이 없습니다. 몇 달 이전의 파이프라인을 처리하는 액세스를 제한함으로써 이 데이터를 주 데이터베이스에서 더 효율적이고 경제적인 다른 저장소로 옮길 수 있습니다.
이미 보관된 빌드를 처리하지 못하도록 하는 것이 가능합니다. 빌드가 보관되면 다시 시도할 수 없지만 여전히 데이터베이스에 있는 모든 처리 메타데이터를 유지하고 있으며, 주 데이터베이스에서 부족한 리소스를 사용합니다.
성능을 향상시키고 CI/CD 데이터 저장을 더 쉽게 확장하기 위해 아래에 설명된 세 가지 방법을 따를 수 있습니다.
- CI/CD 빌드 대기열 데이터베이스 테이블 파티션화
- CI/CD 파이프라인 데이터베이스 테이블 파티션화
- 빌드 메타데이터 테이블 성장률 감소
빌드 메타데이터 테이블 성장률 감소
빌드 (또는 파이프라인)가 보관되면 해당 파이프라인에서 파이프라인 처리를 다시 시작할 수 없습니다. 이는 PostgreSQL에 저장하는 모든 메타데이터가 해당 파이프라인을 효율적으로 신뢰성 있게 처리할 수 있도록 필요한 것이 안전하게 다른 데이터 저장소로 이동될 수 있음을 의미합니다.
파이프라인 처리 데이터 저장은 CI/CD 테이블에 저장된 데이터 중 상당한 부분을 차지하므로 데이터 이동은 비용이 많이 듭니다. 보관된 빌드에 대한 처리 액세스를 제한하면 이러한 메타데이터를 다른 위치(가능하다면 객체 저장소)로 옮기고 필요할 경우에만 실제로 액세스할 수 있도록 만들 수 있습니다 (예: 규정 준수 또는 감사 목적).
데이터를 이동하는 것이 가장 최적의 솔루션인지 평가해야 합니다. 작은 저장소를 사용하여 공간을 절약하면서도 이 데이터 세트에 대한 쿼리 가능성을 유지할 수 있도록 메타데이터 항목을 중복 처리 및 정규화 전략을 사용할 수 있을 것입니다. 여기에 최상의 솔루션을 찾기 위해 기술적 평가가 필요할 것입니다.
대대: 빌드 메타데이터 테이블 성장률 감소.
CI/CD 파이프라인 데이터베이스 테이블 파티션화
CI/CD 메타데이터를 다른 저장소로 이동하거나 메타데이터 성장 속도를 다른 방식으로 줄이더라도 파이프라인, 빌드 및 아티팩트를 설명하는 수십억 건의 레코드를 여전히 보유하고 있습니다. 우리는 객체 저장소에 저장되는 메타데이터에 대한 참조를 유지해야 할 수도 있으며, 대량으로 이 정보를 신뢰성 있게 검색할 수 있어야 합니다.
이는 데이터를 객체 저장소로 이동하여 데이터 크기를 줄일 수 있지만 이 데이터를 설명하는 항목의 양을 줄일 수는 없다는 문제점을 나타냅니다. 데이터를 객체 저장소로 이동하면 데이터 크기를 줄일 수 있지만 데이터를 설명하는 항목의 양을 줄일 수는 없다는 문제점을 나타냅니다. 따라서 데이터베이스에 액세스하는 방식을 변경하여 데이터 속성을 일부분 유지하거나 찾아내야 하는 경우에 실제적인 검색을 수행할 수 있는 기능을 유지해야 합니다.
이는 데이터를 객체 저장소로 이동하여 데이터 크기를 줄일 수 있지만 이 데이터를 설명하는 항목의 양을 줄일 수는 없다는 문제점을 나타냅니다. 따라서 데이터베이스에 액세스하는 방식을 변경하여 데이터 속성을 일부분 유지하거나 찾아내야 하는 경우에 실제적인 검색을 수행할 수 있는 기능을 유지해야 합니다.
이는 데이터를 객체 저장소로 이동하여 데이터 크기를 줄일 수 있지만 이 데이터를 설명하는 항목의 양을 줄일 수는 없다는 문제점을 나타냅니다. 따라서 데이터베이스에 액세스하는 방식을 변경하여 데이터 속성을 일부분 유지하거나 찾아내야 하는 경우에 실제적인 검색을 수행할 수 있는 기능을 유지해야 합니다.
우리의 의도는 매우 큰 데이터베이스 테이블을(primary database) 다른 데이터베이스로 이동하는 것이 아닙니다. 우리는 주 데이터베이스에 저장된 CI/CD 데이터를 나누어 더 작은 여러 개의 테이블로 구분하고자 합니다.(PostgreSQL 포틴션 기능 사용)
CI/CD 데이터를 파티션화하는 몇 가지 방법을 취할 수 있습니다. 유망한 방법 중 하나는 파티션 번호를 할당하고 이 파티션 번호를 해당 파이프라인에 연관된 모든 리소스에 전파하는 list-based partitioning을 사용하는 것입니다. uniform logical partition ID를 사용하여 파티션 번호를 지정할 수 있기 때문에 매우 유연합니다. 이 전략을 원하는 대로 확장할 수 있습니다. 예를 들어, 시간 감쇠 기반 파티셔닝과 테넌트 기반 파티셔닝을 같이 사용하여 응용 프로그램 수준에서 파티셔닝 키를 사용하고 싶을 때 이 전략을 사용할 수 있습니다.
들어가는 데이터를 파티션화하는 것은 접근이 드물게 하는 데이터를 보관하는 정책을 따라야 하므로 일관성 있고 신뢰성 있게 할 수 있습니다.
대대: CI/CD 파이프라인 데이터베이스 테이블 파티션화.
이 주제에 대한 더 많은 기술적 세부정보는 파이프라인 데이터 파티셔닝 설계를 참조하세요.
CI/CD 빌드 대기 데이터베이스 테이블 분할
CI/CD Scale 설계도를 작업 중에 새 아키텍처를 도입하여 CI/CD 빌드를 대기시키는 것을 소개했습니다.
이를 통해 성능을 크게 향상시킬 수 있었습니다. 여전히 이 새로운 솔루션은 다음 반복 작업을 시작하기 전 필요한 중간 메커니즘으로 간주하고 있습니다. 아키텍처를 더 개선해야 하는 다음 단계를 고민 중에 있습니다. (PostgreSQL에서 완전히 또는 일부적으로 이동해야 할 수도 있음).
한편으로 우리는 더 유연하고 신뢰할 수 있는 솔루션으로 나아가기 위한 중간 단계로 또 다른 반복 작업을 배포하고 싶어합니다. 우리는 새로운 대기 테이블을 분할하여 데이터베이스에 미치는 영향을 줄이고 신뢰성 및 데이터베이스 헬스를 향상시키고자 합니다.
CI/CD 대기 테이블의 분할은 빌드 보관 정책을 따르지 않아도 됩니다. 대신, 24시간 이전에 작성된 빌드를 대기열에서 제거해야 한다는 오랜 기간 동안의 정책을 활용해야 합니다. 이 비즈니스 규칙은 GitLab CI 설립 이후 제품에 존재합니다.
에픽: CI/CD 빌드 대기 데이터베이스 테이블 분할.
이 주제에 대한 더 많은 기술적인 세부 정보는 파이프라인 데이터 분할 디자인을 참조하십시오.
원칙
CI/CD 시간 감소 패턴을 구현하기 위해 사용할 세 가지 트랙은 모두 일부 도전과 관련이 있습니다. 구현을 진행함에 따라 이를 성공시키기 위해 많은 문제를 해결하고 많은 구현 세부사항을 고안해야 할 것입니다.
아래에서는 이 아키텍처 설계에서 설명된 비전을 모두에게 이해하기 쉽도록하기 위한 몇 가지 기본적인 원칙을 문서화했습니다.
파이프라인 데이터 제거
과거나 보관된 데이터를 데이터베이스에서 제거하는 일은 유혹이 될지 모르지만 피해야 합니다. 사용자의 동의가 없는 한 사용자 데이터를 영구적으로 삭제하는 것은 보통 원치 않는 일입니다. 그러나 개체 저장소와 같은 다른 데이터 저장소로 데이터를 이동할 수는 있습니다.
보관된 데이터는 때때로 필요할 수 있습니다(예를 들어 규정 준수 또는 감사 목적). 사용자의 요청이나 승인을 받기 전에 영구적으로 삭제되지 않았다면 이 데이터를 필요에 따라 검색할 수 있기를 바랍니다.
UI에서 파이프라인 데이터 접근
파티션을 통해 CI/CD 데이터 시간 감소를 구현하는 것은 여전히 사용자가 여러 파티션에 저장된 데이터에 액세스할 수 있도록 만들고 싶은 경우 도전적일 수 있습니다.
UI에서 파이프라인 데이터에 간편하게 액세스할 수 있도록 유지하고 싶습니다. 다른 리소스에서 파이프라인 데이터를 참조하는 방식에 대한 백스테이지 변경이 필요할 수 있겠지만 UI에서 자신의 파이프라인을 찾기 어렵게 만들고 싶지는 않습니다.
파이프라인 / 빌드 목록 페이지에서 “보관됨” 탭을 추가해야 할 수도 있지만 누군가가 파이프라인 상태를 보거나 병합 요청 또는 배포와 관련된 빌드 실행을 보고 싶을 때 추가 단계/클릭을 피할 수 있어야 합니다.
또한 파이프라인 / 빌드 목록 페이지의 “보관됨” 탭에서 검색 기능을 비활성화해야 할 수도 있습니다.
API를 통한 파이프라인 데이터 접근
파이프라인 데이터에 대한 액세스를 위해 별도의 API 엔드포인트를 작성해야 할 필요가 있다는 가능성을 수용합니다.
새 API에서 사용자는 파이프라인 / 빌드의 데이터를 검색하기 위해 데이터가 작성된 시간 범위를 제공해야 할 수 있습니다. 효율적으로 하기 위해 두 개 이상의 파티션에 있는 데이터를 쿼리하는 것을 제한해야 할 필요가 있을 수 있습니다. 이를 위해 빌드 보관 정책과 동일한 기간을 다루는 시간 범위를 지원함으로써 이를 할 수 있습니다.
이전 API를 사용하여 보관된 파이프라인 데이터에 액세스할 수 있도록 허용할 수 있지만, 사용자가 파티션 식별자를 제공해야 할 수 있습니다.
반복 작업
세 가지 트랙은 병행하여 작업할 수 있습니다:
상태
진행 중
타임라인
- 2021-01-21: 부모 CI Scaling 설계도 병합 요청가 생성되었습니다.
- 2021-04-26: CI Scaling 설계도가 승인되었고 병합되었습니다.
- 2021-09-10: CI/CD 데이터 시간 감소 설계도 토의가 시작되었습니다.
- 2022-01-07: CI/CD 데이터 시간 감소 설계도가 병합되었습니다.
- 2022-02-01: 설계도가 새로운 내용 및 에픽에 대한 링크로 업데이트되었습니다.
- 2022-02-08: 파이프라인 분할 PoC 병합 요청가 시작되었습니다.
- 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: 파이프라인 분할 디자인 문서 병합 요청이 병합되었습니다.
- 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가 파티션으로 분할되었습니다.