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
proposed @sxuereb @andrewn -

셀: 인프라

사전 준비

  1. 셀 이터레이션, 특히 Cells 1.0
  2. GitLab Dedicated
  3. GitLab Dedicated 아키텍처

철학

  • 기본적으로 셀 지역화: 모든 서비스는 문서화되어 있지 않은 이유가 없는 한 셀 지역에서만 사용되어야 합니다. 모든 것을 셀 내부로 유지하면, 셀과 서비스 간의 통신은 내부적으로 유지되며, 서비스는 작은 규모로 실행해야 하며, 잠재적인 영향 범위는 훨씬 작아집니다. 예를 들어, Gitaly와 GitLab 레지스트리는 셀 내부에 있습니다.
  • 동질적인 환경: 현재까지는 모든 GitLab 셀이 동일해야 합니다. 부트스트래핑과 프로비저닝은 자동화되어야 합니다. 첫 번째 이터레이션에서 모든 셀의 크기가 같지만, 크기가 다른 셀을 실행하는 것에 이점이 있지만, 이는 복잡성과 범위를 증가시킵니다.
  • 새로 시작하지만 그렇게 많이는 아님: 새로운 GitLab 인스턴스가 생성되므로, 모든 것을 다시 만들고자 하는 유혹이 있습니다. 기존 인프라, 전용 도구 및 시간을 균형있게 유지해야 합니다.
  • 모든 작업이 동일한 방식으로 롤아웃됨: 구성 변경, 피처 플래그, 배포 및 운영 작업은 이상적으로 변경을 롤아웃하는 동일한 프로세스를 거쳐야 합니다. 한 가지 방법으로 작업하는 것은 효율성을 가져다 주며 자동화에 대해 단일 소스의 진실성을 제공합니다.
  • 도구 중앙화: GitLab.com을 관리하기 위한 많은 도구가 있고, GitLab Dedicated에는 별도의 도구가 있습니다. 이는 각각을 실로, 노력의 중복 및 이동성이 줄어드는 현상을 만들어 냅니다. GitLab.com의 여러 셀에 대해 여러 셀을 프로비저닝해야 합니다. 새로운 도구를 필요로 하며, GitLab Dedicated에서는 목적 때문에 도구를 새로 만들었습니다. 가능한 한 이 도구를 사용해야 하며, 동의하지 않는 부분이 있다면 다른 방법을 찾아, 동의하고, 반대하기 위해 노력해야 합니다. 일부 단점이 있는 도구로 시작하는 것은 괜찮으며, 반복적인 접근 방식은 두 개가 아닌 성숙한 제품을 이끕니다.

용어/범용언어

  • 프로비저닝: 새로운 셀을 생성할 때. 예: 우리는 새로운 셀 5를 프로비저닝했습니다. 이는 새로운 셀입니다.
  • 배포: 기존 셀 내에서 실행 중인 코드를 변경할 때. 예: 우리는 GitLab.com에 새로운 자동 배포 버전을 배포했습니다.
  • 구성 변경: 응용 프로그램이나 인프라에서 구성을 변경할 때. 예: VM에 추가된 레이블에 대해 구성 변경을 했습니다.
  • 셀: 단일 단위이자 GitLab의 인스턴스입니다. 여기서는 “테넌트”라고 불리는 Dedicated를 가리키는 데 사용되지 않습니다.
  • 링: 하나의 배포 단계 대상으로 그룹화된 셀의 모음입니다. 예: 링 2에 있는 셀은 링 1에 있는 셀 이후에 변경 사항을 배포합니다.
  • 클러스터: 셀의 모음 및 기존 GitLab.com 인프라입니다. 예: 클러스터에서 레지스트리 버전을 변경해야 합니다.
  • 플리트: 단일 테넌트 및 멀티 테넌트인 모든 SaaS 환경으로 우리의 제품 환경을 구성하는 모든 것입니다. 기존의 GitLab.com 인프라, 셀 및 Dedicated을 모두 포함합니다.

아키텍처

아래는 셀 아키텍처입니다. 현재의 GitLab.com 아키텍처(셀 이전)는 https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/에서 찾을 수 있습니다.

반지

Rings는 우리가 프로비저닝하는 셀과 기존 인프라를 그룹화하는 맨털 모델의 기초로 기능합니다. 반지 내부에는 X 개의 셀이 있으며, 이어지는 반지는 점진적으로 더 많은 셀로 전체 플릿을 점차적으로 커버합니다. 각 반지는 이전 반지의 슈퍼셋이 될 것입니다. 예를 들어, 0번 반지에는 0번 반지에 있는 셀만 포함되고, 5번 반지에는 5번 반지와 그 이전의 모든 반지에 있는 셀이 포함됩니다. 변경 사항은 내부 반지에서 외부 반지로 이산적인 단계로 퍼져나갑니다. 예를 들어, 변경 사항이 5번 반지에 도달하면 4, 3, 2, 1번 반지에도 도달하게 될 것입니다.

어떤 롤아웃의 경우 변경 사항은 0번 반지에서 시작하여 변경 사항이 성공하면 연이어 오는 반지로 이동할 수 있으며, 실패하면 롤아웃을 중지하고 모든 고객에게 영향을 주지 않습니다. 이러한 순진한 롤아웃으로 다음과 같은 이점을 얻을 수 있습니다:

  1. 변경 사항의 영향 범위가 작아져 모든 고객에게 동시에 영향을 미치지 않습니다.
  2. 변경 사항의 롤아웃 방법에 대한 명확한 경계가 있습니다.
  3. 스테이징과 같은 다른 환경이 필요하지 않습니다. 모든 셀은 프로덕션 상태가 될 것입니다.
  4. 변경 사항에 대한 확신이 높을수록 더 넓은 대상을 대상으로 합니다.

우리의 목표는 셀 1.0에서 2번 반지 내에 최대 10개의 셀을 갖는 것입니다. 반지 내의 셀 개수는 임의적이며, 그 크기는 아직 결정되지 않았습니다. 이는 공용 릴리스 이전에 자동 배포 패키지를 적절히 테스트하는 필요성과 보안 수정에 대한 전체 프로덕션 롤아웃의 속도, 그리고 사용자의 장애 또는 버그로부터의 보호를 고려할 것입니다.

우리는 결국 반지를 다음과 같이 활용할 것입니다:

  1. 배포.
  2. 구성 변경의 롤아웃.
  3. 피처 플래그의 롤아웃.

스테이징

우리는 반지에 전통적인 스테이징 환경을 갖고 있지 않습니다. 왜냐하면 처음 몇 반지에서 변경 사항을 테스트할 수 있기 때문에 같은 결과를 얻을 수 있습니다. 이는 기존 스테이징 환경은 계속 사용되며, 이는 비셀 인프라에 대해서만 사용될 것입니다.

이 설정을 통해 우리는 현재 스테이징과 관련한 몇 가지 문제를 해결할 수 있습니다:

  1. 스테이징은 프로덕션의 실제 표현이 아닙니다.
  2. 우리는 스테이징을 프로덕션으로 간주하여 배포를 막습니다.
  3. 스테이징의 구성은 프로덕션과 다를 수 있습니다.

대규모 도메인

인프라는 복합적이며 모든 팀이 셀 인프라를 설정하는 데 역할을 합니다.

확신 열은 특정 도메인에 대한 확신과 그 도메인의 셀 경로에 대한 방향을 제공하는 청사진이 있는 경우에 대한 확신을 의미합니다. 청사진이 Merge되면 이상적으로 확신은 👍로 이동해야 합니다.

도메인 오너 청사진 확신
라우팅 그룹::테넌트 스케일 청사진 👍
셀 컨트롤 플레인 그룹::배송/팀::페운데이션 할 일 👎
셀 크기 조정 팀::스캘러빌리티-관측가능성 할 일 👎
CI 러너 팀::스캘러빌리티-실천 할 일 👎
데이터베이스 팀::데이터베이스 신뢰성 청사진 👍
배포 그룹::배송 청사진 👍
관측가능성 팀::스캘러빌리티-관측가능성 청사진 👎
셀 아키텍처 및 도구 팀::페운데이션 청사진 👍
제공 팀::페운데이션 할 일 👎
구성 관리/롤아웃 팀::페운데이션 할 일 👎
재해 복구 팀::프로덕션 엔지니어링 청사진 👍

이해 관계자

Cell 운영에 참여하는 여러 팀이 있습니다. 첫 번째 구분은 도구를 구현하고 유지하는 팀과 해당 도구를 사용하는 팀 사이에 있습니다.

영역 기능 소유자
전용 도구와의 통합*    
  릴리스 매니저 워크플로우와의 통합 team::Delivery-Deployments
  Instrumentor 및 AMP을 사용한 배포 메커니즘 team::Foundations
  Cell 애플리케이션 참조 아키텍처 및 오버레이 team::Ops
  Cell 부트스트래핑, 도구 및 지원 인프라 team::Ops
  Cell 폐지 team::Ops
클러스터 상태를 위한 제어 플레인**    
  GitOps 모델 조사 team::Delivery-Deployments
  CRD + 오퍼레이터 조사 team::Delivery-Deployments
링 기반 배포 자동화    
  링 경계 내에서 변경 사항 전파 team::Delivery-Deployments
  링 경계 외에서 변경 사항 조정 team::Foundations
  긴급 제동: 패키지 롤아웃 중지 team::Delivery-Deployments
롤백 기능    
  다운타임이 있는 롤백(링 0의 QA Cell용) team::Delivery-Deployments
  롤백 지원을 위한 지연된 포스트 배포 마이그레이션 team::Environment Automation
Observability    
  Cell 건강 메트릭 team::Scalability-Observability
  클러스터 건강 메트릭 team::Scalability-Observability
  패키지 상태 team::Delivery-Deployments
사건 라이프사이클 관리    
  당직 엔지니어 호출 team::Ops
  사건 도구 team::Ops
네트워크 엣지    
  웹 애플리케이션 방화벽 team::Foundations
  CDN team::Foundations
  로드 밸런싱 및 네트워킹 team::Foundations
  속도 제한 team::Foundations

* 이들 항목은 SaaS 플랫폼 및 코어 플랫폼의 다양한 이해 관계자의 기여가 필요할 수 있습니다. 관련 이해 관계자는 소유 팀과 고객 팀의 요구 사항을 충족시키기 위해 밀접히 협력해야 합니다.

** 이들 항목은 Cell 2.0 반복 이후 고려해야 합니다.

이러한 기능의 사용자는 릴리스 관리자, 당직 엔지니어 및 Team::Ops입니다. 다음 디렉터리은 해당 그룹이 cell 클러스터에서 수행할 수 있는 작업을 정의합니다:

  1. 릴리스 관리자
    • 경계 내에서 배포 명령
    • “졸업함” 패키지 선언
    • 경계 내에서 롤백 배포
  2. 당직 엔지니어
    • 실패한 배포에 대한 알림 수신
    • 패키지 롤아웃 일시 중지(다음 링에 도달하지 못함)
    • 실패한 배포에 대한 조사 진행
  3. Team::Ops
    • Cell 부트스트래핑
      • 프로비저닝
      • 폐지
      • 재균형
      • Cell-Ring 연관성