• 사전 준비 사항
• 철학
• 용어집/유비쿼터스 언어
• 아키텍처
• 대규모 도메인
• 이해관계자

Cells: 인프라

사전 준비 사항

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

철학

• 기본적으로 셀 지역화: 모든 서비스는 셀 지역화여야 하며, 문서화되어 있지 않고 지역화되어 있지 않을 때에는 전역이 아닙니다. 만약 우리가 모든 것을 셀 지역화한다면, 셀과 서비스 간의 통신은 내부적으로 유지되고, 서비스는 더 작은 규모로 실행해야 합니다. 폭발 반경이 훨씬 작아집니다. 예시로 Gitaly와 GitLab 레지스트리는 셀 지역화됩니다.
• 동질적인 환경: 현재 모든 GitLab 셀은 동일해 보여야 합니다. 부트스트래핑과 프로비저닝은 자동화되어야 합니다. 처음에는 모든 셀이 동일한 크기입니다. 다른 크기로 실행하는 것에는 이점이 있지만, 복잡성과 범위가 증가합니다.
• 새 출발, 그렇지만 그만큼은 아닌: 새로운 GitLab 인스턴스가 생성됩니다. 모든 것을 다시 시작하는 것이 유혹스럽지만, 기존 인프라와 전용 도구, 시간을 균형있게 유지해야 합니다.
• 모든 작업은 동일한 방식으로 배포됩니다: 구성 변경, 기능 플래그, 배포, 운영 작업은 이상적으로 동일한 프로세스를 거치게 됩니다. 일관된 방식으로 작업을 수행하면 효율성이 증가하고 자동화의 단일 근원이 생깁니다.
• 도구 중앙화: 우리에게는 GitLab.com을 관리하기 위한 많은 도구와 별도의 도구가 있습니다. 이는 격리, 노력의 중복, 이동성이 줄어드는 원인이 됩니다. GitLab.com을 위해 여러 셀을 프로비저닝해야 하며, 이를 위해 새로운 도구가 필요합니다. GitLab Dedicated는 이러한 이유로 도구를 만들었습니다. 가능한 한 이 도구를 사용해보아야 합니다. 동의하지 않는 부분이 있을 경우 반대, 커밋 및 반대하여 단일 도구를 개선할 수 있습니다. 단점이 있는 도구로 시작하는 것은 괜찮으며, 반복적인 접근 방식이 _하나_의 성숙 제품을 이끌어냅니다.

용어집/유비쿼터스 언어

• 프로비저닝: 새로운 셀을 생성할 때. 예: 우리는 셀 5를 _프로비저닝_했는데, 이것은 새로운 셀입니다.
• 배포: 기존 셀 내에서 실행 중인 코드를 변경할 때. 예: 우리는 GitLab.com에 새로운 자동 배포 버전을 _배포했습니다.
  • 청사진
• 구성 변경: 응용 프로그램이나 인프라구성을 변경할 때. 예: 가상 머신에 추가된 라벨에 _구성 변경_을 했습니다.
• 셀: 단일 유닛이자 GitLab의 인스턴스. Dedicated에서는 GitLab의 인스턴스를 테넌트라고 부릅니다.
• 클러스터: 셀의 모음 및 기존 GitLab.com 인프라. 예: 클러스터에서 레지스트리의 버전을 변경해야 합니다.
• 플릿: 우리의 생산 환경을 구성하는 단일 테넌트 및 멀티 테넌트 모든 SaaS 환경의 총집합. 기존 GitLab.com 인프라, 셀 및 Dedicated을 포함합니다.

아키텍처

아래는 셀 아키텍처입니다. 현재 GitLab.com 아키텍처(셀 이전)는 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 "클러스터 1" <> { component "에이전트 K" as cluster1AgentK } frame "클러스터 2" <> { component "에이전트 K" as cluster2AgentK } frame "클러스터 3" <> { component "에이전트 K" as cluster3AgentK } frame "작업 스테이션" <<서비스_사용자>> { component "kubectl" } } cloud wss://kas.gitlab.com <> as kas.gitlab.com { component "라우팅 서비스" } 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 } } "라우팅 서비스" <--d--> kasCell1 "라우팅 서비스" <--d--> kasCell1 "라우팅 서비스" <..d..> kasCell2 "라우팅 서비스" <..d..> kasCell2 @enduml ``` </details> 서비스_사용자>

대규모 도메인

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

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

이해관계자

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

* 이러한 항목은 SaaS 플랫폼 및 코어 플랫폼의 다양한 이해관계자의 기여를 요할 수 있습니다. 이해관계자들은 소유 팀 및 고객팀의 요구를 충족시키기 위한 적절한 조율을 위해 이 작업에 긴밀히 협력해야 합니다.

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

해당 기능의 사용자는 배포 관리자, 담당 엔지니어 호출 및 Team:Ops입니다. 다음 목록은 해당 그룹이 셀 클러스터에서 수행할 수 있는 작업을 정의합니다:

1. 배포 관리자
   • 범위 내에서 배포 명령
   • “승격된” 패키지 선언
   • 범위 내에서의 배포 롤백
2. 담당 엔지니어 호출
   • 실패한 배포에 대한 경보 수신
   • 패키지 롤아웃 일시 중지(다음 링에 도달하지 못함)
   • 실패한 배포에 대한 조사 진행
3. Team::Ops
   • 셀 부트스트래핑
     • 프로비저닝
     • 해제
     • 리밸런싱
     • 셀-링 연관성