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 @nolith @skarbek @None devops platforms 2024-01-09

Disclaimer: 이 청사진은 더 많은 업무 부서 간 조정이 필요합니다. - 신뢰 수준: 낮음

Cellular Architecture를 활용한 애플리케이션 배포

이 청사진은 셀 아키텍처에 의해 도입된 새로운 스케일링 차원을 지원할 수 있는 배포 전략을 설명합니다.

이 전환의 복잡성은 이 아키텍처에서 프로덕션 등급 등급에 도달하기 위해 필요한 기능을 소유권을 가지고 참여할 수 있는 플랫폼 부문의 많은 팀들을 요구할 것입니다.

소개

서문

고수준의 시각에서 셀 클러스터는 다음 3가지 항목으로 이루어진 시스템입니다:

  1. 라우터 - GitLab 애플리케이션과 독립적으로 배포된 HA 라우팅 시스템.
  2. 프라이머리 셀 - 클러스터 전체 데이터 및 서비스에 대한 리더인 GitLab 설치. 이것은 기존의 GitLab.com 배포입니다.
  3. 0개 이상의 선컨더리 셀 - 유한한 조직의 권한을 가진 GitLab 설치들. 이러한 셀들은 GitLab Dedicated 도구를 사용하여 배포됩니다.

다이어그램에서 확인할 수 있듯이, 사용자는 라우터를 통해서만 시스템과 상호 작용합니다. 선컨더리 셀은 내부 API를 사용하여 프라이머리 셀과 통신하고 운영에 필요한 데이터베이스 행의 로컬 사본을 갖고 있습니다.

선컨더리 셀이 GitLab Geo를 기본적으로 지원하더라도, 라우터가 이 기능을 지원할 때까지 사용자들에게 이 기능을 제공할 수 없을 것입니다.

주요 용어

  • 배포 - 인프라에 설치되는 GitLab 애플리케이션 및 해당 컴포넌트
  • auto-deploy 버전 - 배포 가능한 패키지를 생성하는 활성 버전
  • 링 - 셀 클러스터의 논리적 파티션. 다음 링으로 배포하려면 현재 링 내에서 패키지를 유효하게 검증해야 합니다.
  • 퍼리미터 - 릴리스 관리자들을 위한 “끝의 정의”를 나타내는 링. 퍼리미터 내에서 검증된 패키지는 나머지 플리트에 롤아웃될 수 있습니다.
  • graduated 버전 - 퍼리미터 바깥의 셀에 배포하기에 안전하다고 판단된 버전
  • .com - 우리 옛날에 존재하거나 현재 실행 중인 인프라
  • 프라이머리 셀 - 클러스터 전체 데이터 및 서비스에 대한 리더인 GitLab 설치. 초기에는 기존의 GitLab.com 배포입니다. 기존 인프라
  • 선컨더리 셀 - 유한한 수의 조직에 대해 권한을 가진 GitLab 설치들. GitLab Dedicated 도구를 사용하여 배포됩니다.

링 배포

셀 프로젝트 배포의 규모와 강력한 사용자 파티셔닝은 링 배포 접근 방식과 잘 매핑됩니다.

위의 이미지는 프라이머리 셀과 10개의 선컨더리 셀, 셀 1.0 마일스톤의 상한선을 가진 클러스터의 가능한 링 레이아웃을 보여줍니다.

일반적인 규칙은 다음과 같습니다:

  1. 배포 프로세스는 링 0부터 외부 링까지 진행됩니다.
  2. 링은 배포와 관련된 동일한 위험 요소를 공유하는 셀들의 집합입니다.
  3. 배포는 어떤 단계에서라도 중단될 수 있고, 패키지는 외부 링에 도달하지 않을 것입니다.
  4. “퍼리미터” 링을 정의합니다. 이는 릴리스 매니저들에게 “끝의 정의”를 나타냅니다.
    • 퍼리미터를 넘어가는 것은 주어진 패키지 수명 주기의 논리적인 지점입니다.
    • 퍼리미터 내에서 포스트-배포 마이그레이션을 성공적으로 실행하면 패키지는 graduated로 표시됩니다.
    • graduated 패키지는 월간 릴리스의 유효한 후보입니다.
    • graduated 패키지는 나머지 링에 자동으로 롤아웃됩니다.
    • 배포는 자동화되어야 합니다: 퍼리미터 내에서는 릴리스 매니저들의 책임, 퍼리미터 외부에서는 Team:Ops의 책임입니다.

애플리케이션 변경 수명 주기

이 부분에서는 새로운 패키지가 새로운 인프라에 배포되는 방식과 기존 도구 및 프로세스와의 상호 작용과 훅을 설명합니다.

GitLab.com 배포 프로세스는 핸드북에서 자세하게 설명되어 있으며, 여기서는 링 배포에 대해 이야기하기 위해 필요한 부분에 대해서만 간략화할 것입니다.

현재 프로세스

현재 GitLab.com 배포는 다음 두 가지 주요 프로세스로 구성됩니다:

  1. 자동 배포 패키지를 위한 릴리스 도구 조정 파이프라인은 배포와 QA를 스테이징 및 프로덕션 환경을 통해 연차적으로 실행합니다. 이 프로세스의 시간표는 사용 가능한 릴리스 매니저에 따라 다르지만, 보통 하루에 10회 실행됩니다.
  2. 포스트 배포 마이그레이션 파이프라인은 현재 프로덕션 환경에서 실행 중인 포스트 배포 마이그레이션을 실행하여 배포된 변경 사항의 품질 보증을 완료합니다. 이 프로세스는 환경 롤백이 더 이상 불가능한 지점을 표시하기 때문에 보통 하루에 한 번 실행됩니다.
flowchart TB subgraph release_tools [릴리스 도구 조정 파이프라인] direction LR gstg_cny[GSTG\n 카나리] --> gstg_cny_qa[QA] gstg_cny_qa --> gprd_cny[GPRD\n 카나리] gprd_cny --> gprd_cny_qa[QA] gprd_cny_qa --> baking_time[1시간\n 베이킹 타임] baking_time --> promotion[▶️\n 매뉴얼\n 프로모션] promotion --> gstg[GSTG\n 메인] --> gstg_qa[QA] promotion --> |30분 지연|gprd[GPRD\n 메인] end pkg((자동 배포\n패키지\n태깅)) --> release_tools subgraph pdm [포스트 배포 마이그레이션] direction LR pdm_gstg[GSTG] --> pdm_gstg_qa[QA] --> pdm_gprd[GPRD] end %% 내용 배치를 돕는 레이아웃을 위한 보이지 않는 링크 release_tools ~~~ pdm

패키지는 포스트 배포 마이그레이션을 실행한 후에만 Self-Managed형 고객에게 릴리스될 수 있습니다.

기존 인프라와 Cells의 공존

잠시동안 기존(레거시) 배포 및 Cells가 공존합니다. 초기에 우리의 링 배포 구현은 오직 세 개의 링으로만 구성될 것입니다.

  • 링 0: QA 셀과 기타 실험적 빌드를 호스팅하며, 이 링은 레거시 프로덕션 카나리 스테이지와 동기화됩니다.
  • 링 1: 레거시 프로덕션 메인 스테이지를 위한 빈 플레이스홀더. 기존 배포에서 기존 사용자를 추출할 수 있게 되면, 이 링은 본인, 무료 사용자 및 일반적으로 새 기능에 빠르게 접근하고 싶어하는 모든 조직을 호스팅할 수 있습니다.
  • 링 2: 고객을 위한 첫 번째 셀을 호스팅합니다.

우리의 릴리스 프로세스의 성격 상, 이러한 첫 번째 링은 기존의 릴리스 도구에 의해 제어될 것입니다.

flowchart LR subgraph release_tools [릴리스 도구 조정 파이프라인] direction LR gstg_cny[GSTG\n 카나리] --> gstg_cny_qa[QA] gstg_cny_qa --> gprd_cny[GPRD\n 카나리] gprd_cny --> gprd_cny_qa[QA] gprd_cny_qa --> baking_time[1시간\n 베이킹 타임] baking_time --> promotion[▶️\n 매뉴얼\n 프로모션] promotion --> gstg[GSTG\n 메인] --> gstg_qa[QA] promotion --> |30분 지연|gprd[GPRD\n 메인] end subgraph pdm [포스트 배포 마이그레이션] direction LR pdm_gstg[GSTG] --> pdm_gstg_qa[QA] --> pdm_gprd[GPRD] end subgraph Ring Deployment direction LR ring_0[링 0] --> ring_0_qa[QA] ring_1[링 1] ring_2[링 2] %%% 내용 레이아웃을 돕기 위한 보이지 않는 링크 ring_1 ~~~ ring_2 end pkg((자동 배포\n패키지\ntagging)) --> release_tools %% 링 배포 후크 gstg_cny_qa --> ring_0 ring_0_qa --> baking_time pdm_gprd ---> |pkg graduation|ring_2 promotion --> |30분 지연| ring_1
미래 - 셀만

완전성을 위해 레거시 인프라가 폐기되고 모든 사용자가 새 셀로 이관되는 잠재적인 미래 시나리오에 대해 설명합니다.

이 프로젝트의 진화에 따라 변경될 수 있으며 예를 들어 스테이징 환경의 미래는 셀의 개발에 영향을 받을 것으로 예상됩니다. 그러나 여기서는 이 문서의 범위를 줄이기 위해 현재 스테이지 환경을 그대로 두겠습니다.

flowchart LR subgraph release_tools [릴리스 도구 코디네이터 파이프라인] direction LR gstg_cny[GSTG\n 캐너리] --> gstg_cny_qa[QA] baking_time[1시간\n 조리 시간] --> promotion[▶️\n 매뉴얼\n배포] promotion --> gstg[GSTG\n메인] --> gstg_qa[QA] end subgraph 배포 후 이동 direction LR pdm_gstg[GSTG] --> pdm_gstg_qa[QA] --> pdm_gprd[링 1] end subgraph 링 배포 direction LR ring_0[링 0] --> ring_0_qa[QA] ring_1[링 1] ring_2[링 2] --> ring_3[링 3] --> ring_N[링 N] end pkg((자동 배포\n패키지\n태깅)) --> release_tools %% 링 배포 후크 gstg_cny_qa --> ring_0 ring_0_qa --> baking_time pdm_gprd ---> |pkg 졸업|ring_2 promotion ---> |30분 지연| 링 1

동시에 존재하는 시나리오와의 변경 사항은 다음과 같습니다.

  1. 링 2 이후에 새로운 링이 존재합니다. 패키지의 진행은 각 링에서 게이트를 강제하는 링 배포 엔진에 의해 조정됩니다.
  2. 릴리스 도구 코디네이터 파이프라인은 이제 링만 관리하며, 프로덕션에서 캐너리(Canary) 및 메인 스테이지 개념은 더 이상 존재하지 않습니다.
  3. 배포 후 이동 파이프라인은 링 1에서 마이그레이션 실행을 제어합니다(이 단계에서는 더 이상 필요하지 않은 토론 주제).

참고 자료

목표 및 비목표

목표

  • 릴리스 매니저의 인지적 부담 증가를 제한하고, 여기서 패키지가 릴리스 매니저의 책임이 아니라는 명확한 인도 지점으로 선정했습니다.
  • 각 링에서 자동 검증이 수행되므로 장애의 범위를 제한합니다.
  • 신뢰할 수 있는 자동화된 배포 보장
  • 실패한 배포의 자동 처리 보장
  • 패키지 배포 및 배포의 가시성 제공

비목표

  • 릴리스 도구를 셀 애플리케이션 배포의 책임을 확장시키지 않습니다. 보다 구체적이고 작은 소프트웨어 조각을 사용하여 도구를 한 가지 작업에 집중할 수 있습니다.
  • 릴리스 관리와 관련된 주요 변경 사항 도입
  • 셀의 라이프사이클 관리
  • 셀 간의 트래픽 라우팅 관리
  • 개별 컴포넌트 배포

요구 사항

보조 셀을 배포 파이프라인에 통합하기 전에 즉시 해결해야 할 몇 가지 문제가 있습니다.

  1. 라우터가 존재해야 하며 고가용성(HA)이어야 하며 독립적인 배포 파이프라인이 있어야 합니다.
    • 이는 적절한 테스트를 위해 필요합니다. 아래에서 설명하는 것처럼 QA 셀에 대한 테스트를 실행할 QA가 지정된 배포를 위해 QA 세포로 라우팅해야 합니다. 라우터는 비슷한 방식으로 자산을 리디렉션하기 위한 책임을 맡게 될 것입니다.
  2. 자산 배포
    • .com에 대해서는 이미 존재합니다. 현재 이 작업은 HAProxy를 통해 처리되지만, Cells의 경우 라우팅 레이어가 유사한 방식으로 자산을 리디렉션하게 됩니다.
    • 자산이 다르게 관리되도록 선택된 경우 배송은 가능한 제로 다운타임 업그레이드를 제공하기 위해 배포해야 하며, 셀 설치를 지원하기 위한 구성도가 변경되어야 합니다.
  3. 피처 플래그
    • 현재의 피처 플래그 워크플로우 및 도구가 주 셀에 적용되어 작동할 것으로 가정합니다. 보조 셀에는 영향을 미치지 않을 것입니다.
    • 장애를 완화하기 위해 피처 플래그의 사용은 주 셀에만 제한됩니다.
    • 작업이 여러 셀로 확장되는 경우 장애를 완화하기 위한 피처 플래그가 오랜 기간 동안 적용되는 것을 방지해야 합니다. 이는 고객이 자신의 작업이 셀을 넘나드는 경우 유사한 경험을 하고 .com 운영자로서 피처 플래그 뒤의 코드가 다르고 그로 인한 영향에 대해 걱정할 필요가 없도록 보장합니다.
    • 이 영역에 대한 추가 가이드, 문서 작성이 필요합니다. 엔지니어는 조직이 어떤 셀에 속하는지는 중요하지 않아야 합니다. 따라서 피처 플래그 토글은 엔지니어가 해당 셀에 대해 걱정할 필요를 추상화시킵니다.

제안된 실행 계획

배달 관점에서는 1.0, 1.5 및 2.0 셀 이터레이션 간에 많은 변화가 없습니다. 분리는 특정 셀에 바운드된 조직에 대한 사용 가능한 기능의 범위를 줄이는 반복적인 접근 방식을 기반으로 합니다. 배포 관점에서 최초 이터레이션부터 여러 보조 셀을 가질 수 있어야 하므로 셀 아키텍처 버전과 독립적인 로드맵을 구상해야 합니다.

이터레이션

셀 1.0

이 이터레이션에서의 의도는 셀을 구축하고 관리하는 자체 도구에 중점을 두는 데 있습니다. 다음 이정표 및 해당 종료 기준은 플랫폼 섹션과 여러 팀에 걸쳐 협력적인 노력입니다.

  1. 전용 기술 스택 확대:
    • Instrumentor 및 AMP 지원 GCP
    • 셀이 Instrumentor의 참조 아키텍처로 정의됨
  2. 셀 클러스터 코디네이터를 위한 제어 평면
    • Switchboard는 현재 Dedicated에서 사용 중이지만 셀에 적합한 도구는 아닙니다. 다른 도구의 기능을 살펴보고 배포 워크플로에 통합하는 데 사용될 수 있는 amp와 instrumentor의 능력을 평가해야 합니다.
    • 전체 인프라의 수렴을 수반하는 셀 배포 구현
    • 초반에는 링 0 및 링 2만 있음
  3. 첫 번째 보조 셀: 링 0의 QA 셀
    • 현재 도구와의 통합을 통해 QA 셀로 배포를 수행하기 위해 자체적으로 배포해야 합니다.
    • QA 셀에서 자체 QA 스모크 테스트 실행
    • QA 셀은 프로덕션 캐너리 스테이지와 병렬로 업데이트: QA 셀 실패는 소프트로 간주되고 자동 배포를 차단하지 않음
  4. 셀을 위한 개별 대시보드 및 경보의 제어 평면
    • 가시성은 레거시 인프라와 동등하게 적어도 있어야 합니다
    • 경보는 레거시 인프라와 동등하게 적어도 있어야 합니다.
  5. 첫 번째 고객 보조 셀: 링 2
    • 릴리스 도구는 PDM 실행 후 패키지를 졸업시킬 수 있어야 합니다.
    • 코디네이터가 링 2 배포를 관리할 수 있어야 합니다.
  6. 여러 보조 셀 지원
    • 코디네이터가 동일한 링 내에서 여러 셀을 원하는 버전으로 수렴시킬 수 있어야 합니다
  • 제한 사항:
    • 모든 보조 셀은 링 2에 있을 것입니다.
    • 롤백은 가능하지만 모든 보조 셀에서 다운타임이 발생할 수 있습니다.

Cells 1.5 and 2.0

다음 기능은 셀 1.5 및 2.0 사이에 분배할 수 있으며 모두 운영 측면을 개선하므로 우리가 셀 작동에 대해 더 알게 됨에 따라 이러한 기능을 우선순위로 지정해야 합니다.

  1. 셀을 위한 제어 평면 - 추가 링
    • 보조 셀은 여러 링에 걸쳐 분산될 수 있어야 합니다.
    • 다음 링으로의 배포는 현재 링이 수렴된 후 자동으로 시작될 수 있어야 합니다.
    • 긴급 차단: 다음 링으로의 패키지 롤아웃을 차단할 수 있는 기능
  2. QA 셀이 자동 배포를 차단
  3. 셀을 위한 제어 평면 - 클러스터 대시보드 및 경보
    • 대시보드는 특정 셀 및 링 배포에 기대되는 패키지를 나타내야 합니다.
    • 원하는 버전을 실행하지 않는 모든 셀은 쉽게 확인돼야 하며 일정 시간 내에 수렴되지 않을 경우 경보가 울려야 합니다.
    • 링 내부에서 패키지 롤아웃을 차단하기 위한 배포 헬스 메트릭스(z-스코어)가 필요합니다.
  4. 배포 후 이동(포스트 디플로이먼트 마이그레이션) 단계는 셀에서 롤백을 수행하기 위해 응용 프로그램 배포와 분리돼야 합니다.
    • 이 기능이 없으면 롤백을 위해 셀은 다운타임을 필요로 합니다. 이것은 방해적이며 현명한 해결책이 아니어야 합니다.
    • 기본 셀에서 마이그레이션과 응용 프로그램 배포가 분리되는 기능은 이미 원하는 대로 작동합니다. 따라서 기본 셀은 사고를 완화하기 위한 롤백 옵션을 갖추고 있을 것입니다.
  5. 우리가 당초 운영하고자 했던 깃랩 애플리케이션을 배포하기 위한 수정된 도구가 필요합니다. 현재 사용하려고 하는 도구는 인프라와 깃랩 버전을 통합하는 전략을 사용하고 있어서 이것은 긴 CI 파이프라인 및 긴 실행 작업을 만드는 문제점을 일으킵니다.
  6. 자동 롤백 - 배포가 어떤 이유로 실패하면 장애를 최소화하기 위해 자동으로 롤백 절차가 시작되어야 합니다. 이를 위해 건강 메트릭스를 사용할 수 있어야 합니다.

여기서의 중점은 처음 이터레이션의 MVP 단계에서 누적된 기술 채무를 정리하고 완성하는 것입니다.

마인드맵

%%{init: {'theme':'default'}}%% mindmap root((Cells 배포)) 핵심 개념 📚 현재 .com 인프라는 주요 셀입니다. Cell 1.0에 여러 개의 셀을 가질 수 있습니다. Cell은 고가용성 솔루션이 아닙니다. 보조 셀은 내부 API를 사용하여 주요 셀과 통신합니다. 전제 조건 🏗️ 라우터 고가용성 솔루션 독립적인 배포 전용 GCP 지원 Cell 참조 아키텍처 결정 사항 📔 링 스타일 배포 링 0: 현재 Canary + 새로운 QA Cell 링 1: 현재 Main stage 링 2+: 고객을 위한 새로운 보조 셀 외곽선 릴리스 매니저와 팀:Ops 간의 인수점으로 표시됨 내부: 링 0 및 1 외부: 링 2+ 내부에서 PDM 실행 시 패키지 출시 출시된 패키지는 매월 출시될 수 있는 유효한 후보입니다. 우리는 스테이징을 Cell로 이전하지 않습니다. 사용자에게 영향을 미치지 않고 패키지를 검증하는 새로운 QA Cell이 필요합니다. 업그레이드가 필요한 절차 🦾 롤백 자동 배포 롤아웃 배포 후 마이그레이션 배포 건강 메트릭 리스크 영역 ☢️ Cell 1.0 및 1.5에서 도그푸딩이 없습니다.

배포 코디네이터와 셀 클러스터 코디네이터

자동 배포의 맥락에서 release-tools 프로젝트 내의 외부 코디네이터 파이프라인이 있어서, 패키지 생성과 롤아웃을 조절합니다.

오늘날의 GitLab.com 인프라에서는 특정 도구(deployer 및 gitlab-com/k8s-workloads)를 사용하여 배포를 실행하며, SRE 및 릴리스 매니저가 독립적으로 조절할 수 있습니다. 그러나 셀 클러스터의 도입으로 새로운 운영적 도전에 직면하게 될 것이며, 간단한 클러스터 개요, 패키지 롤아웃 상태, 피처 플래그 구성, 프로비저닝 및 프로비저닝과 같은 새로운 운영이 필요하게 될 것입니다.

GitLab Dedicated 스택은 스위치보드, Amp 및 Tenctl을 통해 GitLab 설치를 제어하기 위한 자체 방법을 갖고 있습니다. Switchboard의 사용은 Cells를 위한 것이 아니므로 활용할 수 없습니다. 다른 도구(인스트루먼터 및 Amp)는 Dedicated 팀 및 Cells 간의 사용을 위해 보다 이식성 있도록 수정되거나 사용하는 데 권장됩니다. 이 도구들과 Cells와의 상호작용 및 그들을 어떻게 활용할 지를 평가할 필요가 있습니다. 일정이 어떻게 관리되느냐에 따라 이는 초기 기간 또는 셀 MVP(최소 가치 제품) 기간 동안 팀 간 요구 사항을 보장하기 위해 팀 경계를 횡단하여 긴밀히 협력하는 데 크게 기여할 것입니다.

이 단락에서는 특정 버전으로 데이터 리포지터리를 업데이트하고 셀 클러스터 코디네이터를 생성하여 셀 배포를 지원하는 이상적인 상호작용을 설명합니다.

안내된 대로, 내부에서 Perimeter에 Cell 1.0의 단일 보조 셀인 QA Cell이 사용될 것입니다. release-tools를 확장하여 몇 가지 도구를 명령하여 요구에 따라 셀 업데이트를 수행해야 합니다.

우리가 전제한 대로, 링 1에서 배포 후 마이그레이션을 실행하면, release-tools는 그 버전을 graduated로 표시하고 따라서 Perimeter 바깥쪽으로 롤아웃할 수 있게 될 것입니다.

Cell Cluster Coordinator는 오토메이션된 프로세스 배포 수안을 조화롭게 지원하는 데 활용될 것입니다. 이는 배포가 원하는 링의 올바른 셀에 배포되고 배포 전후에 올바른 상태인지를 확인하기 위해 배포하기 전후에 자동 확인을 수행하여 실패 시 롤백하고 필요한 팀에 경고하는 데 활용될 것입니다.

절차

자동 배포

자동 배포는 오늘날과 동일하게 작동할 것입니다. 우리의 주요 셀은 우리의 기존 .com 인프라와 동일하기 때문에, 자동 배포와 관련된 기존 절차를 계속 활용할 수 있을 것입니다. 핫패칭, 롤백, 자동 배포 픽킹, PDM(Post Deploy Migration), 기존 자동 배포 일정 등과 관련된 기존 절차를 활용할 수 있을 것입니다. 새로운 절차를 추가하여 PDM이 실행된 후에 release-tools이 다음 링으로의 배포를 트리거하기 위해 알고 있도록 해야 합니다. 현재 release-tools은 링 배포와 관련된 어떤 것도 이해하지 못하므로 이러한 기능을 추가해야 합니다.

  • 자동 배포는 링 0 및 1로 제한됩니다:
    • 링 0에는 QA Cell과 .com 인프라의 카나리 스테이지가 포함됩니다.
    • 링 1에는 .com 인프라의 메인 스테이지가 포함됩니다. 이것은 release tools의 차단 지점입니다.
    • 모든 셀은 같은 방식으로 배포됩니다. 이는 서로 다른 배포 기술을 다룰 필요가 없게 합니다.
    • release-tools은 배포 파이프라인의 일부로 링 0으로의 배포를 조정하기 위해 코디네이터와 상호작용합니다.
  • Release-tools은 패키지를 graduated할 수 있어야 합니다:
    • graduated GitLab 버전은 제공되고 Post Deploy Migration(PDM)이 완료된 Production의 Main Stage로 자동 배포된 버전입니다.
    • 이는 우리가 Secondary Cells로 하루에 하나의 패키지 배포가 일어날 것으로 기대하는 것을 의미합니다. 현재 PDM은 하루에 1회만 실행됩니다. 이 규칙에는 예외가 있음을 기억해야 합니다.
    • 이로써 우리는 응용 프로그램 코드가 잘못될 경우 SLA를 놓칠 위험이 있으므로 공식 출시된 GitLab 버전을 실행하고 싶어하지 않습니다. 셀 아키텍처에서 대부분의 문제는 주요 셀에서 발견되어 고쳐지기 때문에 두 번째 셀로 배포되기 전에 해결되어야 합니다.
    • 수작업 테스트를 통해 문제를 발견했을 때의 대비를 위해 새로운 절차, 런북 및 문서가 필요합니다.
    • 실제로 QA는 우리가 자동으로 배포할 수 있도록 오류를 찾아내기 위한 문제를 발견해야 합니다.

현재 일부 작은 컴포넌트는 .com 인프라에 자체 배포됩니다. 특히 Zoekt, Container Registry 및 Mailroom은 .com에 새로운 버전을 제공하기 위한 독자적인 인터벌이 있습니다. 이 기능은 Cells로 전이되지 않을 것이며, 현재 활용할 도구에서 이러한 기능을 가능하게 하는 컴포넌트의 격리를 허용하지 않기 때문입니다. 대신, 현재 기본 브랜치에서 명시된 현재 정의된 버전에 의존할 것이며, 이는 어떻게 우리의 릴리즈가 이뤄지는가를 모방하고 있으므로, 이는 Cells로 잘 전달될 것으로 예상됩니다.

롤백

장기적으로, 셀에 대한 배포 도구를 수정하여 각각의 셀이 배포 실패를 안전하게 롤백할 수 있도록 하는 유예 기간을 제공할 수 있도록 하기 위해 노력해야 할 것입니다. 현재 기존 .com 또는 주요 셀의 경우, 일일 PDM은 릴리스 매니저의 재량에 의해 1회 실행됩니다. 셀로 배포하는 도구는 현재 PDM을 실행하지 않는 방법이 없으므로 특정 셀의 다운타임 없이 롤백하는 방법이 현재 존재하지 않습니다. 이러한 영역에서는 절차 및 도구 업데이트가 필요할 것입니다.

핫 패칭

핫 패칭은 문제를 완화하는 데 우리의 능력 중 하나입니다. graduate 버전에 의존하는 경우 핫 패처에는 보조 셀을 위한 공간이 없습니다. 그러나 여전히 주 셀에서는 활용할 수 있습니다. 그러나 보다 안전한 배포 방법을 선호해 핫 패칭을 없앨 수 있다면 더 좋을 것입니다.

참고로, 우리는 2023년에 프로덕션에서 핫 패치를 한 번만 진행했습니다.

배포 건강 지표

현재로서는 .com 레거시 인프라의 Main stage 또는 Primary Cell로의 배포를 자동화하지 않습니다. 운영 오버헤드를 줄이기 위해 기존 메트릭을 활용하여 특정 설치의 건강 지표를 형성하고 적절한 시간에 배포를 자동으로 트리거할 수 있어야 합니다. 또한, 이 배포 건강 지표는 각 셀로 전달되어야 합니다. 다양한 링에서 배포를 트리거하는 도구는 이전 링의 상태 및 다음 대상 링의 건강 상태에 따라 계속하거나 중지해야 합니다.

피처 플래그

피처 플래그에 대해 data-stores#83에서 설명하고 있습니다.

패키지 롤아웃 정책

현재의 자동 배포 사용에 의해 암시적 절차가 있습니다. Cells의 사용으로 인해 이것이 더 중요해질 것입니다. 위의 다양한 형식에서 암시된 바와 같이, 자동 배포는 오늘과 비슷한 방식으로 작동합니다. Cells는 다양한 영역에서 트리거를 가진 기존의 release-tools 파이프라인에 추가됩니다. 언제 트리거할지와 어떤 것을 트리거할지를 정의해야 합니다. 보조 셀은 GitLab의 graduated 버전만 받을 것으로 예상됩니다. 따라서 우리는 Primary Cell에서 Post Deployment Migration 파이프라인을 사용하여 패키지가 graduated로 간주되는지 여부를 게이트키퍼로 활용할 것입니다. 이상적인 세계에서 Primary Cell에서 PDM이 성공적으로 실행되면 해당 패키지가 graduated로 간주되어 어떤 외부 링으로든 배포할 수 있습니다. 이 같은 개념은 이미 우리가 Self-Managed형 고객을 위해 릴리스를 빌드할 때 활용되는 것입니다. 이 경계점은 이미 릴리스 매니저들에게 자연스럽게 익숙하며 따라서 셀 배포에 대한 좋은 옮김이 될 것입니다.

우리는 셀로 빠르게 배포할 수 있도록 노력해야 합니다. 하나의 링에 존재하는 모든 셀에 대해 병렬로 배포할 수 있어야 합니다. 이렇게 하면 셀 간의 버전 이격을 최소화하고 잠재적 문제를 줄일 수 있습니다. 버전 이격이 심하면 자동 배포가 일시 중지되어 너무 뒤떨어진 이유에 대해 조사를 시작해야 합니다. 이러한 상황에 대해 가능한 한 미리 알고 있으면 이상적입니다. PDM마다 셀에 배포해야 하는 것은 PDM마다 셀 배포입니다. PDM이 건너뛰는 날도 있습니다. 그런 날에는 PDM이 왜 중지되었는지 문제를 평가하여 셀 배포에 미칠 손해를 결정해야 합니다.

마지막 링은 Orchestration 엔진에 의해 Self-Managed형됩니다. release-tools이 패키지를 graduated로 만드는 대로 그것을 잊어버릴 수 있습니다. Orchestration 엔진은 퍼미터 외부의 Ring 2에 있는 모든 셀에 원하는 GitLab 버전을 수렴시키고 다음 링으로 이동합니다.

자주 묻는 질문

개발자는 MR이 다양한 셀로 배포될 때 지표를 볼 수 있나요?

아니요. 현재의 라벨링 체계는 주로 커밋이 프로덕션에 착륙했고, PDM이 성공적으로 실행되었음을 명시하여 관찰된 커밋이 Self-Managed형 고객을 위해 릴리스될 안전한 상태임을 나타내는 데 사용됩니다. 이 단계 이후에 패키지의 문제는 최소화되어야 하기 때문에 여러 링에 배포됨에 따라 버전이 어떤 셀에 배포되었는지를 신경써야 할 필요가 없습니다.

P1/S1 문제가 셀에 존재할 경우 어떻게 이를 완화하나요?

셀은 여전히 .com의 일부이므로 우리의 현재 버그 및 취약점 해결을 위한 SLA가 적용됩니다. 우리는 ‘graduated’로 간주되는 경우에 보조셀에 원하는 것을 자유롭게 배포할 수 있습니다. 높은 우선순위의 문제가 발생하면 기존 절차를 자유롭게 활용하여 코드베이스를 업데이트하고 임의의 자동 배포 브랜치를 업데이트하고 테스트를 거쳐 천천히 배포하거나, 혹은 사후로 하는 것이 가능하여 이를 셀에 배포할 수 있어야 합니다. 이를 통해 오늘날 우리가 활용하는 것과 비슷한 완화 방법을 사용할 수 있습니다. 이로 인해 완전히 검증되지 않은 코드가 존재할 수 있지만, 이 경우에 롤백에 의존할 수 있고, 이러한 경우의 다음 자동 배포를 위한 패치를 재평가하고 셀을 다시 완화하는 시도를 해야 할 것입니다.

개발자들의 관점에서 예상되는 변경 사항은 무엇인가요

릴리스 및 자동 배포 절차는 크게 변경되지 않아야 합니다. 우리는 코드가 착륙하는 위치를 변경하고 있습니다. 이 영역에서의 변경 사항은 주로 이터레이션 2.0에 가까워질수록 가장 많이 증가할 것입니다. 이는 GitLab의 다양한 환경 또는 단계가 변화하기 시작하는 시점입니다.

하나를 제외한 모든 티어가 실패한 배포가 발생할 경우 모든 셀로의 패키지 롤백을 트리거하는 것은 무엇인가요?

이는 반복하고 프로세스를 개발하고자 할 다양한 특성에 따라 다릅니다. 예를 들어, 첫 번째 티어의 첫 번째 셀에서 실패한 경우 해당 셀을 조사하고, 이것이 모든 셀에 대한 체계적인 문제가 아닌지 확인해야 합니다. 이는 경우에 따라 처리되어야 합니다. 마지막 티어 및 마지막 셀에 도달해 실패가 발생한 경우, 애플리케이션 오류를 잡은 시간이 충분히 경과했을 것으로 예상되기 때문에 다른 셀의 롤백을 해야 할 이유가 없어야 합니다.

Self-Managed형되는 릴리스에는 어떤 일이 벌어집니까?

이론적으로는 크게 변하지 않습니다. 현재 우리는 Self-Managed형용으로 릴리스 가능한 변경 사항을 검증하기 위해 프로덕션 또는 .com의 Main Stage을 사용하고 있습니다. 이것은 Cellular 아키텍처에서도 동일한 위치에 존재하기 때문에 이는 변하지 않습니다. 어휘는 변경됩니다. 이러한 경우에는 graduated 패키지가 이제 릴리스할 수 있는 안전한 패키지로 간주됩니다.

PreProd에서는 어떤 일이 벌어집니까?

이 인스턴스는 릴리스 후보를 만들 때 GitLab 패키지와 Helm 차트의 혼합 설치를 테스트합니다. 이것은 태그가 붙기 직전의 마지막 단계입니다. 이는 셀 작업에 영향을 받지 않습니다. 그러나 프리프로드가 어떻게 관리되는지는 변경될 수 있습니다.

스테이징에서 어떤 일이 벌어집니까?

스테이징은 GitLab의 장기 인스턴스 테스트와 QA와 함께 배포의 중요한 부분입니다. 가설적으로는 시간이 지남에 따라 스테이징이 완전히 사라지고 0티어로 배포될 수도 있습니다. 위의 이터레이션 3을 참조하십시오 {+TODO 적절한 링크 추가+}

Ops에서 어떤 일이 벌어집니까?

변경할 필요가 없습니다. 그러나 Cell 관리가 쉬워진다면 이 설치가 유사하게 작동하도록 만드는 것이 현명할 것입니다. 고유한 지식을 오퍼레이션 팀에 과부하를 주지 않기 위해 이러한 조치를 취하는 것이 좋습니다.

이와 같은 대답은 개발 인스턴스에 대해서도 제공될 수 있습니다.