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 @ogolowinski @dcroft @vshushlin devops release 2019-05-16

GitLab Pages 새 아키텍처

GitLab Pages는 GitLab 제품의 중요한 컴포넌트입니다. 정적 콘텐츠를 제공하는 데 주로 사용되며 명확히 정의된 책임을 가지고 있습니다. 그러나 안타깝게도 GitLab.com 쿠버네티스 이주를 방해하는 요인이 되고 있습니다.

클라우드 네이티브 및 Kubernetes의 채택은 GitLab이 프로젝트 뒤의 회사로서 더 빨리 성장하는 데 도움이 되는 두 가지 가장 큰 풍력으로 인정받았습니다.

이 노력에 대해 자세한 내용은 인프라 팀 핸드북 페이지에서 확인할 수 있습니다.

GitLab Pages는 NFS와 꽤 밀접한 관련이 있으며 쿠버네티스 이주를 방해하는 요인이 되었습니다. 이로 인해 GitLab Pages 아키텍처에 상당한 변경이 필요합니다. 이 일은 우리가 1년 전 이상 전에 시작한 진행 중인 작업입니다. 본 청사진은 왜 이것이 중요한지와 로드맵이 무엇인지 이해하는 데 도움이 될 수 있습니다.

GitLab Pages 작업 방식

GitLab Pages는 정적 콘텐츠를 제공하도록 설계된 데몬으로, Go로 작성되었습니다.

초기에 GitLab Pages는 로컬 공유 블록 스토리지(NFS)에 정적 콘텐츠를 저장하도록 설계되었습니다. 이 구조는 계층적인 그룹 > 프로젝트 디렉터리 구조에서 각 디렉터리가 프로젝트를 나타내며 구성 파일과 GitLab Pages 데몬이 읽고 제공할 정적 콘텐츠를 포함해야 했습니다.

graph LR A(GitLab Rails) -- 새 페이지 배포 작성 --> B[(NFS)] C(GitLab Pages) -. 정적 콘텐츠 읽음 .-> B

이 초기 설계는 NFS 결합을 하나의 이유로 오래되어 오래되었습니다. 우리는 이를 “결합이 덜 된 서비스”와 같은 아키텍처로 대체하기로 결정했습니다. 우리가 작업 중인 새로운 아키텍처는 이 청사진에서 설명하고 있습니다.

NFS 결합

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

그 이후로 NFS 클러스터의 운영 및 유지 관리 비용이 상당히 높아졌으며, 만일 우리가 쿠버네티스로 이주하기로 결정하게 된다면 GitLab을 로컬 공유 스토리지와 NFS에서 분리해야 할 필요가 있다는 것이 명백해졌습니다.

  1. NFS는 단일 장애 지점일 수 있음
  2. NFS는 신뢰할 수 있는 세로 확장만 가능함
  3. 쿠버네티스로 이주하기 위해 마운트 지점의 수를 10배 증가해야 함
  4. NFS는 쿠버네티스 환경에서 제공하기 어려운 극도로 신뢰할 수 있는 네트워크에 의존함
  5. NFS에 고객 데이터를 저장하는 것은 추가적인 보안 리스크를 수반함

NFS를 분리하지 않고 GitLab을 쿠버네티스로 이주할 경우 복잡성과 유지보수 비용이 급증하고 가용성에 엄청난 부정적인 영향을 미칠 것입니다.

새로운 GitLab Pages 아키텍처

  • GitLab Pages는 도메인 구성을 GitLab 내부 API에서 가져오고 로컬 공유 스토리지의 config.json 파일을 읽는 것 대신 정적 콘텐츠를 제공합니다.
  • GitLab Pages는 정적 콘텐츠를 객체 스토리지에서 제공합니다.
graph TD A(사용자) -- 페이지 배포 푸시 --> B{GitLab} C((GitLab Pages)) -. API에서 구성 읽음 .-> B C -. 정적 콘텐츠 읽음 .-> D[(객체 스토리지)] C -- 정적 콘텐츠 제공 --> E(방문자)

이 새로운 아키텍처는 블로그 게시물에서 간략히 설명되어 있습니다.

반복 작업

  1. ✓ GitLab Pages 구성 소스를 GitLab API 사용하여 재설계
  2. ✓ 성능을 평가하고 신뢰할 수 있는 캐싱 메커니즘 구축
  3. ✓ 새로운 소스를 GitLab.com에 점진적으로 롤아웃
  4. ✓ GitLab Pages API 도메인 구성 소스를 기본적으로 활성화
  5. 피처 플래그를 통한 다양한 서빙 실험 활성화
  6. 의미 있는 실험을 통해 객체 스토리지 서빙 설계 3각 실행
  7. 점진적으로 작동하는 페이지 마이그레이션 메커니즘 설계
  8. GitLab.com에서 객체 스토리지 서빙으로 점진적으로 이동

상세한 로드맵이 있는 GitLab Pages 아키텍처 에픽도 확인할 수 있습니다.