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
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 러너가 보내는 점진적인 트레이스 업데이트 Note right of R: 러너가 빌드 트레이스를 추가함 R->>+G: PATCH 트레이스 [빌드.id, 오프셋, 데이터] G->>+D: 청크 찾기 또는 생성하기 [청크 인덱스] D-->>-G: 청크 [id, index] G->>I: 청크 데이터 추가 [청크 인덱스, 데이터] G-->>-R: 200 OK end Note right of R: 사용자가 트레이스를 검색함 U->>+G: 빌드 트레이스 가져오기 loop 각 트레이스 청크마다 G->>+D: 청크 찾기 [인덱스] D-->>-G: 청크 [id] G->>+I: 청크 데이터 읽기 [청크 인덱스] I-->>-G: 청크 데이터 [데이터, 크기] end G-->>-U: 빌드 트레이스 Note right of R: 트레이스 청크가 가득 참 R->>+G: PATCH 트레이스 [빌드.id, 오프셋, 데이터] G->>+D: 청크 찾기 또는 생성하기 [청크 인덱스] D-->>-G: 청크 [id, index] G->>I: 청크 데이터 추가 [청크 인덱스, 데이터] G->>G: 청크 가득 참 [인덱스] G-->>-R: 200 OK G->>+I: 청크 데이터 읽기 [청크 인덱스] I-->>-G: 청크 데이터 [데이터, 크기] G->>O: 청크 데이터 보내기 [데이터, 크기] G->>+D: 데이터 저장 유형 업데이트 [청크.id] G->>+I: 청크 데이터 삭제 [청크 인덱스]

NFS 결합

2017년에 우리는 NFS 인프라를 확장하는 것에 심각한 문제를 경험했습니다.
우리는 심지어 NFS를 CephFS로 대체하려고 시도했지만 실패했습니다.

그 때부터, NFS 클러스터의 운영 및 유지 관리 비용이 상당히 큰 것이 분명해졌고, 만약 우리가 Kubernetes로 이주를 결정하게 된다면 GitLab을 공유 로컬 저장소 및 NFS에서 분리해야 한다는 것이 분명해졌습니다.

  1. NFS는 싱글 포인트 오브 페일러일 수 있음
  2. NFS는 신뢰할 수 있는 방식으로 수직적으로만 확장할 수 있음
  3. Kubernetes로 이주하는 것은 마운트 포인트의 수를 지수적으로 증가시킬 필요가 있음
  4. NFS는 Kubernetes 환경에서 제공하기 어려운 극도로 안정적인 네트워크에 의존함
  5. NFS에 고객 데이터를 저장하는 것은 추가적인 보안 위험을 수반함

NFS의 분리 없이 Kubernetes로 GitLab을 이주하면 복잡성과 유지 관리 비용이 폭발적으로 증가하고 가용성에 막대한 부정적인 영향을 미칠 것입니다.

반복 작업

  1. ✓ 공유 로컬 저장소에 의존하지 않는 새로운 아키텍처 구현
  2. ✓ 성능 및 엣지 케이스 평가, 새로운 아키텍처 개선을 위한 반복
  3. ✓ 클라우드 네이티브 빌드 로그의 정확성 검증 메커니즘 설계
  4. ✓ 성능 및 정확성 주변의 관측 메커니즘 구축
  5. ✓ 프로덕션 환경으로 기능 배포

새로운 아키텍처를 프로덕션에서 사용 가능하게 만들고, GitLab.com에서 기능을 활성화하는 데 필요한 작업은 GitLab.com의 클라우드 네이티브 빌드 로그 epic에서 추적되었습니다.

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

상태

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

우리는 이 기능을 더 견고하고 관찰 가능하게 만드는 epic에 작업 중입니다.