| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@pedropombeiro
@vshushlin
|
@grzesiek
| 2023-01-25 |
CI 빌드 및 Runner Fleet 메트릭 데이터베이스 아키텍처
CI 섹션은 관측 가능성 및 자동화에 중점을 둔 GitLab의 CI 빌드 및 Runner Fleet에 대한 새로운 부가 가치 기능을 기대하고 있습니다. 그러나 PostgreSQL의 현재 데이터베이스 아키텍처를 사용하여 이러한 기능을 구현하고 관측 가능성, 자동화 및 AI 최적화 제품 비전을 실현하는 것은 매우 어렵습니다. 왜냐하면:
- CI 관련 트랜잭션 테이블이 매우 크기 때문에 이를 수정하면 데이터베이스 부하가 증가하고 결과적으로 사건이 발생할 수 있습니다.
- PostgreSQL은 집계 쿼리 실행에 최적화되어 있지 않습니다.
- 빌드 환경에서 더 많은 정보를 추가하려고 하며, CI 테이블을 더욱 크게 만들고자 합니다.
- 또한 Runner Fleet AI 솔루션의 기초인 GitLab CI 효율성 기계 학습 모델을 위해 데이터 집합을 집계하는 데이터 모델이 필요합니다.
우리는 다음을 수행할 수 있는 새로운 유연한 데이터베이스 아키텍처를 만들고자 합니다:
- CI 빌드 및 Runner Fleet의 알려진 보고 요구 사항을 지원할 것입니다.
- CI 빌드 환경에서 데이터를 수용하는 데 사용할 수 있을 것입니다.
또한 이 데이터베이스 아키텍처를 통해 향후에 AI 기능을 개발하는 데 활용할 수도 있습니다.
최근 사용성 연구에서 내비게이션 및 기타 영역에 대한 결과는 GitLab UI가 정보로 오버로드되고 내비게이션 요소가 많다는 것을 시사합니다. 이는 가능한 많은 정보를 추가하려는 시도와 가장 발견 가능한 위치에 기능을 배치하려는 결과입니다. 따라서 이러한 새로운 관측 가능성 기능을 개발하는 동안 워크플로 연구 및 솔루션 검증을 의존하여 해당 기능이 가장 큰 가치를 제공하도록 보장하게 될 것입니다.
Runner Fleet
메트릭 - MVC
인스턴스 러너의 대기열 예상 대기 시간은 얼마입니까?
다음은 이 질문에 대답할 때 해결해야 할 고객의 문제입니다. 그 중 대부분은 사용성 연구에서 얻은 따옴표입니다.
UI
- “예상 Runner 대기 시간을 확인할 수있는 가시성이 없습니다.”
- “특정 Runner에서 병목 현상이 있는지 더 명확하게 보여주는 뷰를 찾으러 여기에 왔어요.”
메트릭 유형
- “GitLab에서 메트릭을 가져와서 Runner의 가용성 및 파이프라인 대기 시간을 확인할 수 있을까요? 목표는 데이터를 얻어 개발자의 파이프라인에 대기 시간이 없는지 확인하기 위해 데이터를 평가하는 것입니다.”
- “작업이 시작되기 전에 Runner 대기열에서 대기 시간이 얼마나 예상되나요?”
메트릭 해석
- “Runner 대기열 성능을 평가할 때 어떤 메트릭을 살펴봐야 하고 이러한 메트릭을 어떻게 해석하고 조치를 취해야 하나요?”
- “시간이 지남에 따른 Runner 대기열 성능에 대한 데이터를 분석하여, 개발자들의 보고서가 가용성과 관련된 드문 경우에 관한 것 인지 확인하고 싶습니다.”
그룹 러너의 대기열 예상 대기 시간은 얼마입니까?
모든 인스턴스 러너의 평균 예상 대기 시간은 얼마입니까?
모든 그룹 러너의 평균 예상 대기 시간은 얼마입니까?
지난 1시간 동안 어떤 러너가 실패했나요?
CI 인사이트
CI 인사이트는 파이프라인 및 작업 기간을 중심으로 데이터를 노출하는 페이지로, 다양한 필터, 검색 및 동적 그래프가 있습니다. 이에 대한 자세한 내용은 관련 하위 섹션을 참조하세요.
구현
현재의 구현 계획은 컨셉 증명에 기반하고 있습니다. 최신 상태는 epic 10682를 참조하세요.
데이터베이스 선택
FY23에서 ClickHouse는 큰 데이터와 삽입 중심 요구사항을 가지는 기능을 위한 GitLab 표준 데이터 리포지터리로 선택되었습니다. 따라서 CI 분석을 위해 이를 선택했습니다.
데이터 범위
우리는 주요 데이터베이스의 ci_builds 테이블의 비정규화된 버전에서 시작하게 되며, 이는 다른 몇 가지 테이블의 필드를 포함할 것입니다. 예를 들어, ci_runners 및 ci_runner_machines가 있습니다.
ClickHouse에서 불변성은 PostgreSQL에서 사용하는 마이그레이션과 유사한 메커니즘이 현재 없습니다. 첫 번째 기능을 개발하는 중에는 데이터베이스 스키마를 매뉴얼으로 유지하고 마이그레이션 메커니즘을 계속 개발할 것입니다.
스키마 변경 후 데이터 다시 업로드
스키마를 수정해야 하는 경우, 이전 데이터가 불완전 할 수 있습니다. 이 경우 ClickHouse 테이블을 단순히 잘라내고(일부) 데이터를 다시 업로드할 수 있습니다.
위와 같은 주제들은 추가 조사가 필요합니다.