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. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
implemented	`@grzesiek`	`@ayufan` `@grzesiek`	`@thaoyeager` `@darbyfrey`	devops release	2020-08-26

클라우드 네이티브 빌드 로그

GitLab에서는 클라우드 네이티브 및 Kubernetes 채택이 프로젝트를 뒷받침하여 더 빠른 성장을 이루는 데 큰 역할을 하는 두 가지 큰 변화 중 하나로 인식하고 있습니다.

이 노력에 대한 자세한 내용은 인프라 팀 핸드북에서 설명되어 있습니다.

전통적인 빌드 로그

전통적인 작업 로그는 로컬 공유 리포지터리의 가용성에 많이 의존합니다.

매번 GitLab 러너가 새로운 부분적인 빌드 출력을 보낼 때마다, 이 출력을 디스크에 파일로 기록합니다. 이 방법은 간단하지만 이 메커니즘은 공유 로컬 리포지터리에 의존합니다 - 모든 GitLab 웹 노드 머신에서 동일한 파일이 사용 가능해야 합니다. 왜냐하면 GitLab 러너가 API 요청을 수행할 때마다 다른 머신에 연결될 수 있기 때문입니다. Sidekiq도 파일에 액세스해야 합니다. 왜냐하면 작업이 완료되면 추적 파일 내용이 객체 리포지터리로 전송되어야 하기 때문입니다.

새로운 아키텍처

새로운 아키텍처는 빌드 로그를 파일에 쓰는 대신 Redis에 데이터를 기록합니다.

이를 성능이 우수하고 견고하게 만들기 위해 우리는 청크된 I/O 메커니즘을 구현했습니다. 우리는 데이터를 Redis에 청크 단위로 저장하고, 원하는 청크 크기에 도달하면 객체 리포지터리로 마이그레이션합니다.

간단화된 순서도가 아래에 제공되어 있습니다.

sequenceDiagram autonumber participant U as User participant R as Runner participant G as GitLab (rails) participant I as Redis participant D as Database participant O as Object store loop incremental trace update sent by a runner Note right of R: Runner appends a build trace R->>+G: PATCH trace [build.id, offset, data] G->>+D: find or create chunk [chunk.index] D-->>-G: chunk [id, index] G->>I: append chunk data [chunk.index, data] G-->>-R: 200 OK end Note right of R: User retrieves a trace U->>+G: GET build trace loop every trace chunk G->>+D: find chunk [index] D-->>-G: chunk [id] G->>+I: read chunk data [chunk.index] I-->>-G: chunk data [data, size] end G-->>-U: build trace Note right of R: Trace chunk is full R->>+G: PATCH trace [build.id, offset, data] G->>+D: find or create chunk [chunk.index] D-->>-G: chunk [id, index] G->>I: append chunk data [chunk.index, data] G->>G: chunk full [index] G-->>-R: 200 OK G->>+I: read chunk data [chunk.index] I-->>-G: chunk data [data, size] G->>O: send chunk data [data, size] G->>+D: update data store type [chunk.id] G->>+I: delete chunk data [chunk.index]

NFS 결합

2017년에는 NFS 인프라의 확장 문제에 직면했습니다. 심지어 우리는 NFS를 CephFS로 대체하려고 시도했지만 성공하지 못했습니다.

그 이후로 NFS 클러스터의 운영 및 유지보수 비용이 상당히 높고, 만약 우리가 Kubernetes로 이주하기로 결정한다면, GitLab을 공유 로컬 리포지터리 및 NFS로부터 분리해야 한다는 것이 명백해졌습니다..

NFS는 단일 장애 지점일 수 있습니다.
NFS는 신뢰할 수 있는 수직적인 확장만이 가능합니다.
Kubernetes로 이동하는 것은 마운트 포인트 수를 10배 증가시킬 필요가 있습니다.
NFS는 Kubernetes 환경에서 제공하기 어려운 극도로 신뢰할 수 있는 네트워크에 의존합니다.
NFS에 고객 데이터를 저장하는 것은 추가적인 보안 위험을 야기합니다.

NFS를 분리하지 않고 GitLab을 Kubernetes로 이주하는 것은 복잡성과 유지보수 비용이 폭발적으로 증가하고 가용성에 엄청난 부정적인 영향을 미칠 것입니다.

반복 작업

✓ 공유 로컬 리포지터리에 의존하지 않는 새로운 아키텍처 구현
✓ 성능 및 예외 상황을 평가하고, 새로운 아키텍처를 향상시키기 위해 반복
✓ 클라우드 네이티브 빌드 로그의 정확성 검증 매커니즘 설계
✓ 성능 및 정확성에 대한 관측 매커니즘 구축
✓ 새로운 기능을 제품 환경으로 점진적으로 배포

새로운 아키텍처를 제품 환경에서 사용할 수 있도록 만드는 데 필요한 작업은 GitLab.com의 클라우드 네이티브 빌드 로그 epic에서 추적되었습니다.

GitLab.com에서 이 기능을 활성화하는 것은 새로운 아키텍처를 모두에게 일반적으로 사용 가능하게 만드는 하위 작업입니다.

상태

이 변경 사항은 GitLab.com에 구현되어 활성화되었습니다.

우리는 이 기능을 보다 견고하고 관측 가능하게 만들기 위한 epic에 작업 중입니다.