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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @nolith @skarbek @None devops platforms 2024-01-09

면책 조항: 이 청사진은 더 많은 역할 간 조정을 필요로 합니다. - 신뢰 수준: 낮음

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

Cell Architecture에서 소개된 새로운 확장 차원을 지원할 수 있는 배포 전략에 대해 설명합니다.

이 전환의 복잡성은 Platforms 섹션의 많은 팀이 이 아키텍처에서 프로덕션 등급 평가에 필요한 기능을 소유하는 데 참여해야 함을 의미합니다.

소개

서문

고수준의 관점에서 Cell Cluster는 3개의 항목으로 구성된 시스템입니다.

  1. 라우터 - GitLab 어플리케이션과는 독립적으로 배포된 고가용성 라우팅 시스템입니다.
  2. 주 셀(primary cell) - 클러스터 전체 데이터 및 서비스의 리더인 GitLab 설치입니다. 이것은 과거의 GitLab.com 배포입니다.
  3. 0개 이상의 보조 셀(secondary cells) - 제한된 기관의 권한을 갖는 GitLab 설치입니다. 이러한 셀은 GitLab 전용 도구를 사용하여 배포됩니다.

다이어그램에서 사용자는 라우터를 통해 시스템과 상호 작용합니다. 보조 셀은 내부 API를 사용하여 주 셀과 통신하며 운영에 필요한 데이터베이스 행의 로컬 복사본을 보유하고 있습니다.

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

주요 용어

  • 배포 - 인프라에 설치되는 GitLab 어플리케이션 및 해당 구성 요소
  • auto-deploy 버전 - 배포 가능한 패키지를 생성하는 활성 버전
  • ring - 셀 클러스터의 논리적 파티션. 다음 링으로 배포하려면 현재 링 안에서 패키지가 유효성 검사되어야 함
  • perimeter - 릴리스 관리자를 위한 “완료 정의”를 표시하는 링. 둘러싸는 내에서 유효성이 검증된 패키지는 나머지 클러스터에 롤아웃될 수 있음
  • graduated 버전 - 둘러싸는 외부 셀에 안전하게 배포할 수 있는 버전
  • .com - 예전에 존재하거나 현재 운영 중인 인프라
  • 주 셀 - 클러스터 전체 데이터 및 서비스의 리더인 GitLab 설치. 초기에는 과거의 GitLab.com 배포가 해당됩니다. 이것은 명시적으로 우리의 예전 인프라인 .com을 포함합니다.
  • 보조 셀 - 제한된 기관의 권한을 갖는 GitLab 설치. GitLab 전용 도구를 사용하여 배포됩니다.

링 배포

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

위 이미지에서는 주 셀과 10개의 보조 셀로 구성된 클러스터의 가능한 링 레이아웃을 보여줍니다. 이것은 Cell 1.0 단계의 상한선입니다.

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

  1. 배포 프로세스는 Ring 0에서 외부 링으로 진행됩니다.
  2. 링은 배포와 관련된 동일한 리스크 요소를 공유하는 셀의 모음입니다.
  3. 배포는 어떤 단계에서든 중단될 수 있으며, 패키지는 외부 링에 도달하지 않을 것입니다.
  4. “perimeter” 링을 정의하고, 릴리스 관리자를 위한 “완료 정의”로 표시합니다.
    • 릴리스 관리자의 논리적인 포인트는 PDM(Post-Deployment Migrations)가 주요 스테이지에서 성공적으로 실행된 후입니다. 구체적으로, 이 문서에 설명된대로 Ring 1과 Ring 2 사이입니다.
    • 외부 링에서는 자동으로 graduated 패키지가 배포됩니다.
    • 배포는 자동화되어야 합니다: 둘러싸는 내에서는 릴리스 관리자의 책임이며, 그 외에는 Team:Ops의 책임입니다.

참고 자료

목표 및 비목표

목표

  • 릴리스 관리자의 인지 부담 증가를 제한하고, 이를 통해 패키지가 릴리스 관리자의 책임이 아닌 명확한 인계 지점으로 정의했습니다.
  • 실패의 확산 반경을 제한하기 위해 셀 클러스터를 링으로 분할하고, 자동 검증은 각 링 사이에서 발생합니다.
  • 배포가 신뢰할 수 있는 자동화되도록 보장합니다.
  • 실패한 배포의 자동 처리를 보장합니다.
  • 패키지 배포 및 배포에 대한 감시를 제공합니다.

비목표

  • release-tools을 확장하여 셀 애플리케이션 배포를 담당하도록 하는 것. 더 구체적이고 특정한 소프트웨어 조각을 사용하여 도구를 하나의 작업에 집중할 수 있도록 합니다.
  • 릴리스 관리와 관련된 중요한 변경 사항을 도입하는 것
  • 셀의 라이프사이클 관리
  • 셀 간의 라우팅 트래픽 관리
  • 개별 구성 요소 배포

요구 사항

보조 셀을 배포 파이프라인에 통합하기 전에 즉시 몇 가지 항목이 필요합니다.

  1. 라우터는 있어야 하며, 고가용성이어야 하며 독립적인 배포 파이프라인이 있어야 합니다.
    • 이는 적절한 테스트를 위해 필요합니다. 아래에서 언급된대로 QA 셀이 필요하며, QA에서 테스트를 실행해야 합니다. 라우터는 적절한 셀로 자산을 리디렉션하기 위해 책임이 있는 당사자가 될 것입니다.
  2. 자산 배포
    • 현재 .com에서 이미 이로운 후입니다. 현재 이는 HAProxy를 통해 처리됩니다. 그러나 Cells의 경우 라우팅 레이어가 역시 자산을 유사한 방식으로 리디렉션하도록 책임을지게 됩니다.
    • 자산을 다르게 관리하기로 선택된 경우, 이는 Delivery가 가능한 한 제로 다운 타임 업그레이드를 제공하고 셀 설치를 자산으로의 라우팅을 지원하도록 필요로할 것입니다.
  3. 기능 플래그
    • 현재의 기능 플래그 워크플로와 도구를 그대로 사용할 것으로 가정합니다.
    • 장애를 완화하기 위한 기능 플래그의 사용은 기본적으로 주 셀에만 제한됩니다.
    • 운영자로서 리셀들이 기능 플래그 뒤에서 코드가 다르고 이에 따른 문제가 발생하는 일에 대해 걱정할 필요가 없도록 보장하기 위해 도구가 성숙해져야 합니다.
    • 이 영역에 대한 더 자세한 지침, 문서가 개발되어야 합니다. 엔지니어는 조직이 어떤 셀이냐에 관심이 없어야 합니다. 따라서 기능 플래그 토글은 엔지니어가 신경 쓸 필요를 추상화해줍니다.

제안된 실행 계획

배포 관점에서는 제안된 3가지 Cells 이터레이션(1.0, 1.5, 2.0) 사이에서 크게 변경되지 않습니다. 이 분할은 주어진 Cell에 바인드된 조직을 위한 사용 가능한 기능의 범위를 줄이는 반복적인 방법입니다. 배포 관점에서는 첫 번째 이터레이션에서부터 여러 보조 셀을 갖도록 가능할 것으로 예상되므로 Cell 아키텍처 버전과는 독립적인 로드맵을 찾아야 합니다.

이터레이션

Cells 1.0

이 이터레이션에서의 의도는 Cell을 구축하고 관리하는 우리 자체 도구에 중점을 두는 것입니다. 다음의 마일스톤과 그 종료 기준은 플랫폼 섹션의 공동 노력이며, 많은 팀에 걸쳐 있습니다.

  1. 전용 기술 스택 확장:
    • Instrumentor 및 AMP 지원 GCP
    • 셀은 Instrumentor의 참조 아키텍처로 정의됨
  2. Cells를위한 제어 평면 - Cell 클러스터 조정자
    • Switchboard는 현재 Dedicated에서 활용 중이지만 Cells에는 적합하지 않습니다. 다른 도구의 기능을 평가하여 배포 워크플로에 통합하는 방법을 결정해야 합니다.
    • 셀 배포는 셀의 전체 인프라를 수렴함
    • 링의 개념을 구현: 초기에는 링 0및 2만
  3. 첫 번째 보조 셀: 링 0의 QA 셀
    • 현재 도구를 사용하여 QA 셀로 배포를 수행하고, QA가 해당 셀에 대해 테스트를 수행합니다.
    • QA 셀은 프로덕션 카나리 단계와 병행하여 업데이트됨: QA 셀 실패는 소프트로 간주되어 auto_deploy를 차단하지 않음
  4. Cells를위한 제어 평면 - 개별 대시 보드 및 경보
    • 감시가 기존 인프라와 적어도 동등함
    • 경보가 기존 인프라와 적어도 동등함
  5. 첫 번째 고객 보조 셀: 링 2
    • release-tools는 PDM 실행 후 패키지를 졸업할 수 있음
    • 조정자는 링 2 배포를 관리할 수 있음
  6. 여러 보조 셀 지원
    • 코디네이터는 동일한 링에 여러 셀을 원하는 버전으로 수렴시킬 수 있음
  • 제한 사항:
    • 모든 보조 셀은 동일한 링, 링 2에 있을 것입니다.
    • 롤백은 모든 보조 셀에서 다운 타임을 필요로 하지만 가능함

셀 1.5 및 2.0

다음 기능은 셀 1.5 및 2.0 간에 분배될 수 있으며, 모두 운영 측면을 개선하며 Cells의 운영 방법에 대해 더 많이 알게 될수록 이러한 기능에 우선 순위를 두어야 합니다.

  1. 셀용 제어 플레인 - 추가 링
    • 보조 셀은 여러 링에 걸쳐 분산될 수 있습니다.
    • 현재 링이 수렴된 후 다음 링으로의 배포가 자동으로 시작됩니다.
    • 비상 제동: 다음 링으로의 패키지 롤아웃을 차단하는 기능
  2. QA 셀은 자동 배포의 블로커가 됩니다.
  3. 셀용 제어 플레인 - 클러스터 대시보드 및 경보
    • 대시보드는 특정 셀 및 링 배포에 예상되는 패키지를 나타내어야 합니다.
    • 원하는 버전을 실행하지 않는 모든 셀은 쉽게 확인되어야 하며 시간 안에 수렴되지 않으면 경보가 울려야 합니다.
    • 링 내에서 패키지 롤아웃을 차단하는 배포 헬스 메트릭스(4가지 골든 시그널의 z-스코어가?)
  4. 배포의 Post Deploy Migration(PDM) 단계를 애플리케이션 배포에서 분리하여 셀의 롤백을 수행할 수 있는 능력을 확보해야 합니다.
    • 이 기능이 없으면 롤백이 완료되려면 셀에 다운타임이 발생해야 합니다. 이는 방해가 되고 현명한 해결책으로 간주되어서는 안 됩니다.
    • 주 셀에서 PDM의 분리는 이미 원하는대로 기능하며, 따라서 우리의 주 셀에서는 사고를 완화하기 위해 롤백 옵션이 있을 것입니다.
  5. 기존 도구를 수정하여 GitLab 애플리케이션만 타켓팅할 수 있는 도구
  6. 자동 롤백 - 배포가 어떤 이유로 실패하면 영향 받는 셀에서 장애를 최소화하기 위해 자동으로 롤백 절차가 시작되어야 합니다. 이를 위해 헬스 메트릭스를 사용할 수 있어야 합니다.

여기서 중점은 구축된 것을 생산화하고 첫 번째 반복의 MVP 단계에서 발생한 기술 부채를 정리하는 것입니다.

마인드맵

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

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

자동 배포의 맥락에서 release-tools 프로젝트 내부에 특정 도구를 호출하여 패키지 생성 및 롤아웃을 조율하는 외부 코디네이터 파이프라인이 있습니다.

오늘의 GitLab.com 인프라에서 배포는 특정 도구(deployer 및 gitlab-com/k8s-workloads)에 의해 실행되며, 해당 도구들은 SRE 및 릴리스 매니저가 독립적으로 운영할 수 있습니다. Cell 클러스터의 도입으로 새로운 운영적인 도전에 직면하게 됩니다. 이는 단순한 클러스터 개요, 패키지 롤아웃 상태, 피처 플래그 구성, 프로비저닝 및 비프로비저닝과 같은 새로운 운영 도전을 의미합니다.

GitLab Dedicated 스택은 Switchboard, Amp 및 Tenctl을 통해 기본적으로 GitLab의 설치를 제어하는 자체 방법을 제공합니다. Switchboard의 사용은 Cells에 대해 적합하지 않으므로 활용할 수 없습니다. 다른 도구인 Instrumentor 및 Amp는 Dedicated 팀 및 Cells 간에 보다 휴대용으로 사용할 수 있도록 수정되거나 적절히 상호작용할 수 있도록 수정될 수 있습니다. 필자는 이러한 도구들, Cells와의 상호작용 및 그들을 어떻게 사용할지를 평가할 필요가 있을 것입니다. 작업이 어떻게 예약되는 지에 따라, 이 작업은 Cell의 초기 기간 또는 MVP기간 동안 요구 사항이 충족될 수 있도록 팀 간에 긴밀히 협력할 수 있는 있음을 포함한 협력적인 노력이 될 수 있습니다.

여기에선, 데이터 저장소가 업데이트되어 배포되어야 하는 원하는 버전과 함께 Cell Cluster Coordinator가 생성되어 셀 배포를 지원하는 이상적인 상호작용을 설명합니다.

셀 1.0에서 퍼리미터 내에서 단일 보조 셀인 QA Cell을 가질 것입니다. 우리는 release-tools를 확장하여 some-tool이 필요 시 Cell 업데이트를 수행할 수 있도록 해야 합니다.

이전 설명에서, 우리는 링 1에서 배포 후 마이그레이션을 실행할 때, release-tools는 해당 버전을 졸업로 표시하고 따라서 퍼리미터 외부로 롤아웃할 수 있는 능력을 갖게 됩니다.

셀 클러스터 코디네이터는 더 높은 링으로의 자동 버전 업그레이드를 조율하는 데 활용될 것입니다. 배포 전후 자동으로 셀을 올바른 링에 배포하거나 올바른 인스턴스가 배포 전후에 건강한지 확인하고 실패할 경우 롤백하며 필요한 팀에게 적시에 경보하는 등의 자동화된 체크를 수행할 수 있도록 도와주는 데 활용될 것입니다.

```

절차

자동 배포

자동 배포는 현재 우리의 주요 셀이 우리의 기존 .com 인프라와 동등하다고 생각하기 때문에 오늘날처럼 계속 작동해야 합니다. 따라서 자동 배포와 관련된 기존 절차는 여전히 활용될 수 있습니다. 핫 패칭, 롤백, 자동 배포 피킹, PDM, 기존 자동 배포 일정 등을 계속 활용할 수 있습니다. 릴리스 도구가 PDM을 실행한 후에 다음 Ring으로 배포를 트리거할 수 있도록하는 새로운 절차가 추가될 것입니다. 현재 릴리스 도구는 Ring 배포와 관련된 어떤 것도 이해하지 못합니다. 이 기능이 추가되어야 합니다.

  • 자동 배포는 Rings 0 및 1로 제한됩니다:
    • Ring 0에는 QA 셀과 .com 인프라의 캐너리 스테이지가 포함됩니다
    • Ring 1에는 .com 인프라의 메인 스테이지가 포함됩니다 - 이것이 릴리스 도구의 막대한 기능 제공의 종료입니다
    • 모든 셀은 동일한 방식으로 배포됩니다. 이는 다양한 배포 기술을 다루지 않아도 되도록 합니다.
    • 릴리스 도구는 분산자 파이프라인의 일환으로 Ring 0에 대한 시험 배포를 조정하기 위해 Coordinator와 상호 작용할 것입니다.
  • 릴리스 도구는 패키지를 졸업할 수 있어야 합니다:
    • GitLab의 졸업 버전은 본 제품의 메인 스테이지로의 성공적인 배포(여기에는 PDM이 완료된)를 가진 자동 배포 버전입니다.
    • 이것은 하루에 하나의 패키지가 보조 셀로 배포되기를 기대할 수 있습니다. 현재 PDM은 하루에 한 번만 실행됩니다. 이 규칙에는 예외가 있음을 유의하십시오.
    • 이러면 응용 프로그램 코드가 잘못될 수도 있는 중대한 문제를 해결하기 위해 기존 절차를 활용할 수 있습니다.
    • 명시적으로 릴리스된 GitLab 버전은 자동 배포보다 훨씬 느리게 생성되기 때문에, SLA(서비스 수준 계약)를 놓칠 위험이 있으므로 GitLab의 공식 릴리스 버전을 실행하고 싶지 않습니다. 셀 아키텍처에서 대부분의 문제는 주요 셀에서 발견되고 이전에 보정되어야만 보조 셀에 배포되기 전에 있어야 합니다.
    • 수동 테스트를 통해 문제가 발견되었을 때 배포를 중단하는 가능성이 있는 졸업 패키지가 실제로 배포되는 것을 막을 수 있는 새로운 절차, 런북 및 문서가 필요합니다.
    • 이러한 실패 케이스를 추적하는 것이 현명할 것입니다. 사실, QA에서 문제를 발견하여 자동 배포를 실행할 수 있도록 하는 것이 좋습니다.

현재 일부 작은 구성 요소는 .com 인프라에 별도로 배포됩니다. 특히 Zoekt, Container Registry 및 Mailroom은 .com에 새 버전을 제공할 자체 케이던스를 갖고 있습니다. 현재 우리가 활용할 도구가 이러한 기능을 활성화할 수 있도록 구성 요소를 분리하는 허용하지 않기 때문에, 이 측면은 보조 셀로 가져가지 않을 것입니다. 대신, 자동 배포 패키지를 빌드한 기본 브랜치에서 지정된 버전에 명시된 버전을 사용할 것입니다. 이것은 우리의 릴리스가 수행되는 방식을 모방하고, 따라서 셀과 잘 어울릴 것으로 예상됩니다.

롤백

장기적으로 볼 때, 셀이 배포 실패를 완화하거나 배포 후 인지된 실패를 완화하기 위해 각각의 grace period를 제공받을 수 있도록 배포 도구를 수정하는 것이 좋습니다. 현재 .com 레거시 인프라 또는 주요 셀에서, 배포를 실행하는 도구는 PDM을 무시할 수 있는 방법이 없습니다. 따라서 특정 셀에 다운타임을 유발하지 않고 롤백할 수 있는 방법이 현재 존재하지 않습니다. 이 영역에서는 절차와 도구 업데이트가 필요할 것입니다.

핫 패칭

핫 패칭은 문제를 완화하는 우리의 능력의 일부입니다. 만약 우리가 졸업 버전에 의존한다면, 핫 패청은 보조 셀에는 없는 것입니다. 그러나 주요 셀에서는 여전히 활용될 수 있을 것입니다. 그러나, 좀 더 안전한 배포 방법을 선호함으로써 핫 패칭을 없애는 것이 현명할 것입니다.

참고로, 우리는 2023년에 운영 버전을 핫 패칭한 적이 단 한 번입니다.

배포 건강 메트릭

현재 우리는 .com 레거시 인프라의 메인 스테이지 또는 주요 셀에 자동 배포를 자동화하지 않습니다. 운영 오버헤드를 줄이기 위해, 특정 설치에 대한 건강 지표를 형성하는 기존 메트릭에 의존하고 적절한 시간에 배포를 자동으로 트리거할 수 있어야합니다. 이 배포 건강 지표는 각 셀로 전달되어야 합니다. 다양한 Rings로의 배포를 트리거하는 도구는 이전 Rings의 상태와 다음 대상 Rings의 건강 상태에 따라 배포를 계속하거나 중지해야함을 인식해야 할 것입니다.

기능 플래그

기능 플래그는 data-stores#83에서 문의되고 있습니다.

패키지 롤아웃 정책

현재 우리가 자동 배포를 사용하는 현재 사용에 의해 구동되고 있는 암묵적인 절차를 가지고 있습니다. 이것은 Cells와 함께 더 중요해질 것입니다. 위에서 다양한 형식으로 암시된 바와 같이, 자동 배포는 대략적으로 오늘과 유사하게 운영되어야 할 것입니다. Cells는 기존의 릴리스 도구 파이프라인에 추가로 구현되어야 합니다. 언제, 무엇을 트리거할 지는 명확하게 정의되어야 합니다. 보조 셀은 GitLab의 졸업 버전만 받아야 합니다. 따라서, 우리는 PDM을 이용해서 패키지가 졸업으로 취급될 때의 게이트키퍼로 활용할 것입니다. 이상적인 경우에는 PDM이 주요 셀에서 성공적으로 실행되면, 해당 패키지가 졸업으로 간주되며, 어떤 외부 Ring에도 배포할 수 있습니다. 이러한 개념은 이미 자체 관리 고객을 위해 릴리스를 빌드할 때 이미 활용되고 있습니다. 이 끊는 지점은 이미 릴리스 매니저들에게 자연스럽게 호군되고 있고, 따라서 셀 배포에 대한 좋은 규정으로 기능할 것입니다.

우리는 셀로 최대한 빠르게 배포할 것을 목표로 해야 합니다. 같은 Ring에 있는 모든 셀에 대해 병렬로 배포할 수 있어야 합니다. 이는 셀 간의 버전 드리프트를 최소화하고 잠재적인 문제를 줄입니다. 버전 드리프트가 심하면 자동 배포가 자체를 일시 중지하고 우리가 너무 뒤쳐진 이유에 대한 조사가 시작될 것입니다. 이 상황에 대해서는 가능한 한 미리 알아야 합니다. 우리는 우리의 Cells에 대해 PDM과 1개의 졸업 패키지 이상의 차이가 나지 않기를 기대합니다. 따라서 기대치는 매 PDM 별로 하루에 한 번 우리의 Cells에 배포될 것입니다. PDM이 건너뛰어지는 날도 있습니다. PDM이 중단되는 이유를 사례 별로 평가하여 이것이 우리의 Cell 배포에 미칠 손해를 결정해야 합니다.

퍼머터 외의 Ring은 오케스트레이션 엔진에 의해 자체 관리됩니다. 릴리스 도구가 패키지를 졸업하면 그것을 잊어버릴 수 있습니다. 오케스트레이션 엔진은 퍼머터 외의 첫 번째 Ring에 있는 모든 Cell에 원하는 GitLab 버전을 수렴시키고, 모든 Cell이 수렴된 후에 다음 Ring으로 이동합니다.

자주 묻는 질문

개발자는 MR이 다양한 셀에 배포될 때 지표를 볼 수 있습니까?

아니요. 현재의 라벨링 체계는 주로 커밋이 프로덕션에 착륙했음을 쇼케이스하기 위한 것이며, PDM이 성공적으로 실행되었음을 나타내어 관찰된 커밋이 Self-Managed 고객용 릴리즈에 배치될 수 있음을 신호합니다. 이 지점에 도달한 이후에는 패키지 관련 문제가 최소화될 것으로 예상되므로, 우리가 여러 배포 링으로 진행함에 따라 이슈/MR의 상태를 업데이트할 필요가 없습니다. 개발자들은 어떤 버전이 어떤 셀에 배포되었는지 신경 쓸 필요가 없습니다.

P1/S1 이슈가 발생했을 때 셀에서 어떻게 완화할 수 있나요?

셀은 여전히 .com의 일부이므로, 우리의 기존 버그 및 취약점 해결 SLA는 여전히 적용됩니다. ‘졸업’된 것으로 간주되는 경우에는 무엇이든 보조 셀에 배포할 수 있습니다. 중요한 우선 순위의 이슈가 발생하면 기존 절차를 자유롭게 활용하여 코드 베이스와 해당 자동 배포 브랜치를 업데이트하고, 추가 테스트를 거친 후 또는 느린 배포를 한 후에 해당 자동 배포 패키지를 셀에 배포할 수 있어야 합니다. 이는 오늘날 활용하는 것과 동일한 완화 방법을 제공합니다. 이로 인해 발생할 수 있는 문제는 완전히 검증되지 않을 수도 있는 일부 코드가 존재할 수 있다는 점입니다. 이 경우에도 우리는 롤백에 의존할 수 있으며, 필요한 경우 다음 자동 배포 시를 위해 해당 패치를 재검토하고 셀을 완화하기 위한 시도를 평가할 수 있습니다.

개발자 관점에서 어떤 변경사항이 예상되나요?

릴리스 및 자동 배포 프로시저는 대부분 동일해야 합니다. 우리는 코드가 착륙하는 곳을 변경하고 있습니다. 이 영역의 변경 사항은 GitLab의 다양한 환경이나 스테이지가 변경되기 시작하는 Iteration 2.0에 가까워질수록 증가할 것입니다.

하나를 제외한 모든 티어에서 배포에 실패했을 때, 그 패키지를 모든 셀에 대한 롤백하기 위한 트리거는 무엇인가요?

이는 이터레이션하고 프로세스 개발을 원할하게 할 다양한 특성에 달려 있습니다. 예를 들어, 첫 번째 티어의 첫 번째 셀에서 실패하면 해당 셀을 조사해야 하지만 이러한 것이 모든 셀에 대해 체계적으로 이루어지지 않았음을 보장해야 합니다. 이는 경우별로 처리해야 합니다. 마지막 티어와 마지막 셀에 도달했을 때 실패가 발생하면, 애플리케이션의 실패를 잡을 시간이 충분히 경과했을 것이므로 다른 셀을 롤백할 이유가 없어야 합니다.

Self-Managed 릴리즈는 어떻게 처리되나요?

이론적으로 크게 변화하지 않습니다. 현재 우리는 Self-Managed용으로 출시될 변경 사항을 입증할 수 있는 프로덕션 또는 .com의 메인 스테이지를 사용하고 있습니다. 이것은 Cellular 아키텍처에서도 동일한 위치에 존재합니다. 여기에는 어휘가 바뀌는데, ‘졸업’된 패키지는 이제 릴리스에 안전하다고 간주됩니다.

PreProd에서 어떻게 됩니까?

이 인스턴스는 릴리스 후보를 생성할 때 GitLab 패키지와 Helm 차트의 하이브리드 설치를 테스트합니다. 이것은 태그가 붙기 직전의 마지막 단계입니다. 이것은 Cells 작업에 영향을 받지 않습니다. 하지만 PreProd의 관리 방식을 변경할 수 있습니다.

Staging은 어떻게 됩니까?

Staging은 QA와 함께 배포의 장기적 인스턴스 테스트에 중요합니다. 가설적으로는 스테이징이 모두가 Tier 0으로 배포되기 위해 완전히 사라질 수도 있습니다. 위의 Iteration 3를 참조하십시오 {+TODO 적절한 링크 추가+}

Ops는 어떻게 됩니까?

변경할 필요는 없습니다. 그러나 Cell 관리가 간단해지면, 가능한 한 오퍼레이션팀에 과부하가 걸리지 않도록 설치를 유사하게 운영하는 것이 현명할 것입니다.

이 답변은 Dev 인스턴스에도 적용될 수 있습니다.