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 -

Cells: 인프라

사전 준비사항

  1. Cells Iteration, 특히 Cells 1.0
  2. GitLab Dedicated
  3. GitLab Dedicated Architecture

철학

  • 기본적으로 Cell 지역화: 모든 서비스는 문서화되고 충분한 이유가 없는 한 Cell 지역적(local)이어야 합니다. Cell을 지역적으로 유지하면 Cell과 서비스 간의 통신이 내부적으로 유지되며, 서비스는 더 작은 규모에서 실행되고, 영향 범위가 훨씬 작아집니다. 예시: Gitaly 및 GitLab 레지스트리는 Cell 지역적입니다.
  • 동질적인 환경: 현재로서는 모든 GitLab Cell이 동일해야 합니다. 부트스트래핑과 프로비저닝은 자동화되어야 합니다. 첫 번째 반복에서 모든 Cell이 동일한 크기이며, 다른 크기로 실행하는 것에는 이점이 있지만, 이로 인해 복잡성과 범위가 증가합니다.
  • 새로운 시작, 그러나 그리 많지는 않게: 새로운 GitLab 인스턴스가 생성되므로 모든 것을 다시 만드는 것이 유혹적일 수 있습니다. 기존 인프라, 전용 도구 및 시간을 균형있게 유지해야 합니다.
  • 모든 운영이 동일하게 전개됨: 구성 변경, 피처 플래그, 배포 및 운영 작업은 이상적으로 변경 사항을 전개하는 동일한 프로세스를 거쳐야 합니다. 모든 것을 1가지 방식으로 수행하면 효율성을 높일 수 있으며 자동화에 대한 단일한 진실된 정보원이 됩니다.
  • 도구 중앙 집중화: GitLab.com을 관리하기 위한 많은 도구와 별도로 GitLab Dedicated를 위한 도구가 있으며, 이는 각각의 독립성, 작업 중복 및 이식성이 줄어드는 결과를 초래합니다. 우리는 GitLab.com에 대한 여러 Cell을 프로비저닝해야 하므로, 이러한 이유로 GitLab Dedicated를 위해 특별히 도구를 구축해야 합니다. 가능한 한 이 도구를 최대한 활용해야 하며, 동의하지 못하는 사항이 있다면 의견 반영, 진행, 불일치(disagree, commit, and disagree)하여 단일 도구를 개선해야 합니다. 불충분한 점이 있는 도구로 시작하는 것은 괜찮으며, 반복적인 접근 방식은 2개의 미성숙한 제품 대신 _하나_의 성숙한 제품으로 이끌어줍니다.

용어집/보편적 언어

  • 프로비저닝(Provision): 새로운 Cell을 생성할 때 사용합니다. 예시: 우리는 새로운 Cell 5를 _프로비저닝_했는데, 이는 새로운 Cell입니다.
  • 배포(Deploy): 기존 Cell 내에서 실행중인 코드를 변경할 때 사용합니다. 예시: 우리는 GitLab.com에 새로운 auto-deploy 버전을 배포했습니다.
  • 구성 변경(Configuration change): 응용 프로그램 또는 인프라에서 구성을 변경할 때 사용됩니다. 예시: VM에 추가된 라벨에 대한 구성 변경을 수행했습니다.
  • Cell: GitLab의 단일 단위 및 인스턴스입니다. 이 용어는 테넌트로 불리우는 GitLab Dedicated를 참조하는 데 사용되지 않습니다.
  • 클러스터(Cluster): 여러 Cell 및 현재의 GitLab.com 인프라의 집합입니다. 예시: 우리는 클러스터 내에서 레지스트리의 버전을 변경해야 합니다.
  • 플리트(Fleet): 단일 테넌트 및 다중 테넌트의 모든 SaaS 환경을 포함하여 우리의 프로덕션 환경으로 구성되는 집합입니다. 기존의 GitLab.com 인프라, Cell 및 Dedicated를 포함합니다.

아키텍처

아래는 Cell 아키텍처입니다. 현재의 GitLab.com 아키텍처(Cells 이전)는 https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/에서 찾을 수 있습니다.
  • KAS: 선택하여 확장 ```plantuml @startuml skinparam frame { borderColor<> #F4B400 } skinparam frame { borderColor<> #4285F4 } skinparam cloud { borderColor<> #F48120 } together { frame "cluster 1" <> { component "agentk" as cluster1AgentK } frame "cluster 2" <> { component "agentk" as cluster2AgentK } frame "cluster 3" <> { component "agentk" as cluster3AgentK } frame "workstation" <> { component "kubectl" } } cloud wss://kas.gitlab.com <> as kas.gitlab.com { component "routing service" } cluster1AgentK <..d..> kas.gitlab.com cluster2AgentK <..d..> kas.gitlab.com cluster3AgentK <--d--> kas.gitlab.com kubectl <--d--> kas.gitlab.com together { frame "gprd-gitlab-cell-1" <> { component kas as kasCell1 component webservice as webserviceCell1 component redis as redisCell1 collections "gitaly(s)" as gitalyCell1 kasCell1 <-d-> webserviceCell1 kasCell1 <-d-> redisCell1 kasCell1 <-d-> gitalyCell1 } frame "gprd-gitlab-cell-2" <> { component kas as kasCell2 component webservice as webserviceCell2 component redis as redisCell2 collections "gitaly(s)" as gitalyCell2 kasCell2 <-d-> webserviceCell2 kasCell2 <-d-> redisCell2 kasCell2 <-d-> gitalyCell2 } } "routing service" <--d--> kasCell1 "routing service" <--d--> kasCell1 "routing service" <..d..> kasCell2 "routing service" <..d..> kasCell2 @enduml ``` </details>

대규모 도메인

인프라는 다층 구조를 갖고 있으며, 모든 팀은 셀 인프라를 설정하는 데 참여합니다.

신뢰도(Confidence) 열은 특정 도메인과 해당 도메인의 경로에 대한 우리의 신뢰도를 나타냅니다. 블루프린트가 Merge되면, 해당 도메인에 대한 방향을 제시하는 블루프린트가 있기 때문에 이상적으로 신뢰도는 👍로 이동해야 합니다.

도메인 소유자 블루프린트 신뢰도
라우팅(Routing) 그룹::테넌트 스케일(group::tenant scale) 블루프린트 👍
셀 제어 평면(Cell Control Plane) 그룹::배송/team::Foundations 할 일 👎
셀 크기 결정(Cell Sizing) 팀::확장성-가시성(team::Scalability-Observability) 할 일 👎
CI 러너(CI Runners) 팀::확장성-실천(team::Scalability-Practices) 할 일 👎
데이터베이스(Databases) 팀::데이터베이스 신뢰성(team::Database Reliability) 할 일 👎
배포(Deployments) 그룹::배송(group::Delivery) 블루프린트 👍
가시성(Observability) 팀::확장성-가시성(team::Scalability-Observability) 블루프린트 👎
셀 아키텍처 및 도구(Cell Architecture and Tooling) 팀::Foundations 할 일 👎
프로비저닝(Provisioning) 팀::Foundations 할 일 👎
구성 관리/롤아웃(Configuration Management/Rollout) 팀::Foundations 할 일 👎

이해관계자

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

영역 기능 소유자
전용 도구와 통합(Integration with Dedicated tools*)    
  릴리스 매니저의 워크플로우와의 통합(Integration with Release Managers’ workflows) team::Delivery-Deployments
  Instrumentor 및 AMP을 사용한 배포 메커니즘(Deployment mechanics using Instrumentor and AMP) team::Foundations
  셀 애플리케이션 참조 아키텍처 및 오버레이(Cell application reference architectures and overlays) team::Ops
  셀 부트스트래핑, 도구 및 지원 인프라(Cell bootstrapping, tooling, and supporting infrastructure) team::Ops
  셀 해제(Cel deprovisioning) team::Ops
클러스터 상태를 위한 제어 평면(Control Plane for cluster state**)    
  GitOps 모델 조사(Investigate GitOps model) team::Delivery-Deployments
  CRD + 오퍼레이터 조사(Investigate CRD + operator) team::Delivery-Deployments
링 기반의 배포 자동화(Ring-based deployment automation)    
  링 범위 내의 변경 전파(Propagating changes inside a ring perimeter) team::Delivery-Deployments
  링 범위 외의 변경 전파 조정(Orchestrating changes propagation outside ring perimeter) team::Foundations
  비상 제동: 패키지 배포 중지(Emergency brake: stopping a package rollout) team::Delivery-Deployments
롤백 기능(Rollback capabilities)    
  다운타임이 있는 롤백(QA Cell in ring 0을 위한 롤백) (Rollback with downtime (for QA Cell in ring 0)) team::Delivery-Deployments
  롤백 지원을 위한 지연된 포스트 배포 마이그레이션(Delayed Post Deploy Migrations for rollback support) team::Environment Automation
가시성(Observability)    
  셀 헬스 메트릭(Cell health metric) team::Scalability-Observability
  플릿 헬스 메트릭(Fleet health metric) team::Scalability-Observability
  패키지 상태(Package States) team::Delivery-Deployments
사고 라이프사이클 관리(Incident Lifecycle Management)    
  당직 엔지니어 호출(Paging Engineer On Call) team::Ops
  사고 도구(Incident tooling) team::Ops
네트워크 엣지(Network Edge)    
  웹 애플리케이션 방화벽(Web Application Firewall) team::Foundations
  CDN team::Foundations
  로드 밸런싱 및 네트워킹(Load Balancing and networking) team::Foundations
  속도 제한(Rate Limiting) team::Foundations

* 이러한 항목들은 SaaS 플랫폼 및 코어 플랫폼의 다양한 이해관계자의 기여가 필요할 수 있습니다. 이해관계자들은 소유 팀과 고객 팀의 요구를 충족시키기 위해 이 작업에 적합하게 협업해야 합니다.

** 이러한 항목들은 셀 2.0 이터레이션 이후를 위한 고려 사항입니다.

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

  1. 릴리스 매니저
    • 링 내에서 배포 명령
    • “진급(graduated)” 패키지 선언
    • 링 내에서의 롤백 배포
  2. 당직 엔지니어
    • 실패한 배포에 대한 경고 수신
    • 패키지 롤아웃 일시 중지(다음 링에 도달하지 못함)
    • 실패한 배포에 대한 조사 수행
  3. 팀::Ops
    • 셀 부트스트래핑
      • 프로비저닝
      • 해제
      • 다시 균형 유지
      • 셀-링 연관성