This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @pedropombeiro @vshushlin @grzesiek 2023-01-25

CI Builds 및 Runner Fleet 메트릭스 데이터베이스 구조

CI 섹션은 관측성 및 자동화에 중점을 둔 CI Builds 및 Runner Fleet의 GitLab에 새로운 부가 가치 기능을 모색합니다. 그러나 현재의 PostgreSQL 데이터베이스 아키텍처를 사용하여 관측성, 자동화 및 AI 최적화 제품 비전을 실현하는 것은 매우 어렵습니다. 왜냐하면:

  • CI 관련 트랜잭션 테이블이 매우 크기 때문에 그들에 대한 수정은 데이터베이스의 부하를 증가시키고 결국 사고를 유발할 수 있습니다.
  • PostgreSQL은 집계 쿼리를 실행하기에 최적화되어 있지 않습니다.
  • 빌드 환경에서 더 많은 정보를 추가하고자 하며, CI 테이블을 훨씬 더 크게 만들고 싶어합니다.
  • 또한 우리는 GitLab CI 효율 기계 학습 모델을 위한 데이터 집합을 집계할 데이터 모델이 필요합니다 - Runner Fleet AI 솔루션의 기초

우리는 다음과 같은 새로운 유연한 데이터베이스 아키텍처를 만들고자 합니다. 이 아키텍처는 다음을 지지할 것입니다:

  • CI 빌드 및 Runner Fleet에 대한 알려진 보고 요구 사항을 지원할 것입니다.
  • CI 빌드 환경에서 데이터를 수집하는 데 사용될 수 있을 것입니다.

또한 우리는 이 데이터베이스 아키텍처를 통해 미래에 AI 기능을 개발하는 데 사용할 수도 있습니다.

최근에 우리가 진행한 탐색 및 기타 분야에 대한 사용성 연구는 GitLab UI가 정보와 탐색 요소로 오버로드되어 있다는 것을 시사했습니다. 이는 가능한 많은 정보를 추가하려는 시도와 가장 발견 가능한 위치에 기능을 배치하려는 노력에서 비롯됩니다. 따라서 이러한 새로운 관측성 기능을 개발하는 동안 우리는 ‘작업 완료’ 연구 및 솔루션 유효성 검사에 의존하여 이러한 기능이 가장 큰 가치를 제공하도록 보장할 것입니다.

Runner Fleet

메트릭스 - MVC

인스턴스 Runner의 대기 시간 대략은 얼마인가요?

이 질문에 대한 해결해야 할 다음 고객 문제들은 대부분의 경우 우리의 사용성 연구에서 인용된 것입니다.

UI

  • “예상되는 Runner 대기 시간을 확인할 수 있는 가시성이 없습니다.”
  • “내 특정 Runner에 병목 현상이 있는지 더 명확히 보여주는 뷰를 찾아보다 여기에 왔습니다.”

메트릭스 유형

  • “GitLab에서 메트릭스를 얻어서 Runner 가용성 및 파이프라인 대기 시간을 확인할 수 있을까요? 목표 - 데이터를 얻어 개발자 파이프라인의 대기 시간이 없도록 조정할 수 있는지 확인해야 합니다.”
  • “작업이 시작될 수 있는 전체 Runner 대기열에서 예상 시간이 얼마나 걸리나요?”

메트릭스 해석

  • “Runner 대기열 성능에 대해 어떤 메트릭스를 살펴봐야 하며, 그 메트릭스를 어떻게 해석하고 조치를 취해야 하나요?”
  • “시간이 지남에 따라 Runner 대기열 성능에 대한 데이터를 분석하여 개발자 보고서가 가용성과 관련하여 실제로 희귀한 경우인지 확인하고 싶습니다.”

그룹 Runner의 대기시간은 얼마로 예상되나요?

인스턴스 Runner의 대기열의 평균 예상 대기시간은 얼마인가요?

그룹 Runner의 대기열의 평균 예상 대기시간은 얼마인가요?

지난 1시간 동안 실패한 Runner는 누구인가요?

CI Insights

CI Insights는 파이프라인 및 작업 지속 시간과 다양한 필터, 검색 및 동적 그래프를 제공하는 페이지입니다. 자세한 내용은 관련 하위 섹션을 참조하세요.

구현

현재 구현 계획은 컨셉 증명 에 기반하고 있습니다. 최신 상태에 대해서는 epic 10682를 참조하세요.

데이터베이스 선택

FY23에서 ClickHouse는 대량의 데이터 및 삽입이 많이 필요한 기능을 위한 GitLab 표준 데이터 저장소로 선정되었습니다. 따라서 우리는 CI 분석에도 이를 선택했습니다.

데이터 범위

우리는 주 데이터베이스의 ci_builds 테이블의 비정규화된 버전에서 시작하여 다른 몇몇 테이블의 필드를 포함할 것입니다. 예를들어, ci_runnersci_runner_machines와 같은 테이블입니다.

ClickHouse에서는 변하지 않음이 핵심 제약 사항이므로 우리는 finished 빌드만 사용합니다.

특징 플래그 뒤에서 개발

개발/스테이징 환경에서 데이터 수집 및 쿼리 성능을 완전히 테스트하는 것은 어렵습니다. 이러한 이유로 우리는 실제 데이터에서 성능을 테스트하기 위해 특징 플래그 뒤에 이러한 기능을 제공할 계획입니다. 데이터 수집 및 API용 특징 플래그는 별도로 설정될 것입니다.

데이터 수집

작업이 완료될 때마다, 새로운 p_ci_finished_build_ch_sync_events 테이블에 레코드가 생성될 것입니다. 이 테이블에는 build_idprocessed 값이 포함될 것입니다. 백그라운드 워커는 미처리된 p_ci_finished_build_ch_sync_events 레코드를 순환하고 PostgreSQL에서 ClickHouse로 데이터를 동기화할 것입니다.

어느 순간에는 처리된 빌드의 수가 많기 때문에 이 워커를 병렬화해야 할 가능성이 높습니다. 이를 위해서 크론 워커는 동시에 수행할 작업자의 수를 결정하는 인수를 수용하게 되며, 해당 인수를 사용하여 ClickHouse로 동기화를 수행할 작업자의 수를 대기열에 등록할 것입니다.

우리는 가장 최근의 빌드로 시작하며, 모든 지난 데이터를 업로드하지 않을 것입니다.

“Raw data”, materialized views and queries

수집된 데이터는 ClickHouse의 “raw data” 테이블로 이동합니다. 이 테이블은 데이터 투입 메커니즘이 실수로 동일한 일괄 처리를 두 번 제출하는 경우 행을 중복 제거하기 위해 ReplacingMergeTree 엔진을 사용합니다.

Raw data는 질의를 실행하는 데 직접적으로 사용될 수 있지만, 대부분의 경우 우리는 AggregatingMergeTree 엔진을 사용하여 전문화된 materialized views를 만들 것입니다. 이를 통해 질의를 수행할 때 훨씬 더 적은 양의 데이터를 읽을 수 있게 됩니다.

Limitations and open questions

아래 주제들은 추가 조사가 필요합니다.

네임스페이스의 데이터 쿼리 효율적인 방법

관리자용으로만 사용 가능한 PoC로 시작하겠지만, 곧 그룹 수준에서 기능을 구현해야 할 것입니다.

그룹이나 프로젝트가 이동될 때 “path”가 변경될 수 있기 때문에 단일화된 “path”를 원본 테이블에 그대로 넣을 수는 없습니다.

이를 해결하는 가장 간단한 방법은 항상 project_id로 빌드를 필터링하는 것이지만, 이러한 방법은 비효율적일 수 있으며 ClickHouse는 대량의 데이터를 저장하기 때문에 모든 데이터의 큰 부분을 읽어야 할 수도 있습니다.

데이터베이스 스키마를 최신 상태로 유지하는 방법

현재 우리는 PostgreSQL에 사용하는 마이그레이션과 동등한 메커니즘을 갖고 있지 않습니다. 첫 번째 기능을 개발하는 동안 데이터베이스 스키마를 수동으로 유지하고 마이그레이션 메커니즘을 계속 개발할 것입니다.

스키마 변경 후 데이터 재업로드

데이터베이스 스키마를 수정해야 할 경우, 이전 데이터가 불완전할 수 있습니다. 이 경우에는 ClickHouse 테이블을 단순히 잘라내고 (일부) 데이터를 다시 업로드하면 될 수 있습니다.