• 소개
  • 서문
  • 주요 용어
  • 링 배포
  • 참고 자료
• 목표 및 비목표
  • 목표
  • 비목표
• 요구 사항
• 제안된 실행 계획
  • 반복
    • 셀 1.0
    • 셀 1.5 및 2.0
    • 마인드맵
    • 배포 코디네이터 및 셀 클러스터 코디네이터
  • 절차
    • 자동 배포
    • 롤백
    • 핫 패칭
    • 배포 헬스 메트릭
  • FAQ

Disclaimer: 이 블루프린트는 보다 강력한 기능을 제공하며 크로스-기능적 조율이 더 필요합니다. - 신뢰 수준: 낮음

Cellular Architecture를 사용한 응용 프로그램 배포

이 블루프린트는 셀 아키텍처에 의해 소개된 새로운 스케일링 차원을 지원할 수 있는 배포 전략에 대해 설명합니다.

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

소개

서문

고수준에서 볼 때, 셀 클러스터는 3가지 항목으로 구성된 시스템입니다.

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

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

중요한 점은 세컨더리 셀이 GitLab Geo를 기본적으로 지원하더라도 라우터가 그것을 지원할 때까지는 사용자에게 이 기능을 제공할 수 없을 것이라는 것입니다.

주요 용어

• 배포 - 인프라에 설치되는 GitLab 애플리케이션 및 해당 컴포넌트
• auto-deploy 버전 - 배포에 적합한 패키지를 생성하는 활성 버전
• 링 - 셀 클러스터의 논리적 파티션. 다음 링으로의 배포를 위해 현재 링 내에서 패키지가 유효성을 검사해야 함
• 퍼리미터 - 릴리스 매니저들의 “완료 정의”를 표시하는 링, 퍼리미터 내에서 유효성이 검증된 패키지는 전체 플릿에 롤아웃될 수 있음
• graduated 버전 - 퍼리미터 외부의 셀에 배포될 수 있는 안전한 버전
• .com - 우리의 이전 인프라 또는 현재 운영 중인 인프라
• 프라이머리 셀 - 클러스터 전체 데이터 및 서비스에 대한 리더인 GitLab 설치. 처음에는 이전 GitLab.com 배포일 것입니다. 이것은 암시적으로 .com을 우리의 기존 인프라로 간주함
• 세컨더리 셀 - 특정 조직에 대한 권한이 있는 GitLab 설치. GitLab Dedicated 도구를 사용하여 배포됨

링 배포

셀 프로젝트 배포의 규모와 강력한 사용자 분할을 함께 고려하면 링 배포 접근 방식과 잘 부합됩니다.

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

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

1. 배포 과정은 링 0부터 외부 링으로 진행됨
2. 링은 배포와 관련된 동일한 리스크 팩터를 공유하는 셀들의 모음
3. 배포는 어떤 단계에서든 중지될 수 있으며 패키지는 외부 링에 도달하지 않음
4. “퍼리미터” 링을 정의하고, 이는 릴리스 매니저들을 위한 “완료 정의”로 표시함
   • 키스 이건 링 1과 링 2를 통과하는 패키지 라이프 사이클에서 설명된 바와 같이, 퍼리미터를 건너는 것입니다.
   • 퍼리미터 내에서 포스트-배포 마이그레이션의 성공적인 실행으로 패키지를 graduated로 표시함
   • graduated 패키지는 매월 릴리스할 수 있는 유효한 후보
   • graduated 패키지는 자동으로 나머지 링에 롤아웃됨
   • 배포는 자동화되어야 함: 퍼리미터 내에서는 릴리스 매니저의 책임, 외부에서는 Team:Ops의 책임

참고 자료

• Cell 1.0 블루프린트
• 이 블루프린트에 대한 Merge Request
• 셀에 대한 배송 관점
• Cells 이전의 GitLab.com 배포 프로세스

목표 및 비목표

목표

• 릴리스 매니저의 인지 부하 증가를 제한하고, 그 과정에서 패키지가 더 이상 릴리스 매니저의 책임이 아닌 지점을 퍼리미터로 정의함
• 셀 클러스터를 링으로 분할하여 실패의 폭을 제한하고 각 링 사이에 자동 유효성 검사가 이루어지도록 함
• 배포가 신뢰할 수 있도록 자동화되도록 함
• 실패한 배포를 자동으로 처리함
• 패키지 롤아웃 및 배포에 대한 관찰 가능성 제공 ```

비목표

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

요구 사항

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

1. 라우터가 존재해야 하며, HA여야 하며, 독립적인 배포 파이프라인을 가져야 합니다.
   • 적절한 테스트를 위해 필요합니다. 아래에서 설명한 대로 QA 셀이 필요하므로 QA는 해당 셀로 배포를 지시하고 테스트를 실시해야 합니다. 라우터는 QA 테스트를 적절한 셀로 라우팅해야 합니다.
2. 자산 배포
   • 현재 .com에 이미 존재합니다. 현재 이 작업은 HAProxy를 통해 처리되지만, 셀이 추가되면 라우팅 계층이 유사한 방식으로 자산을 재지정하는 책임을 갖게 됩니다.
   • 자산을 다르게 관리하기로 결정된 경우, 이로 인해 Delivery가 가능한한 지속적인 업그레이드를 제공하는 방식으로 자산을 배포하고, 셀 설치를 구성하여 자산에 대한 라우팅을 지원해야 합니다.
3. 피처 플래그
   • 현재 피처 플래그 워크플로우와 도구가 기본 셀에서 잘 동작할 것으로 가정합니다. 보조 셀에는 영향을 주지 않을 것으로 예상됩니다.
   • 이용 중인 피처 플래그를 통해 사건을 완화하는 것은 기본 셀에만 제한됩니다.
   • 피처 플래그가 오랜 기간 동안 셀의 이질을 방지하기 위해 도구가 개선되어야 합니다. 이렇게 하면 작업이 셀을 넘나드는 경우에 고객이 유사한 경험을 할 수 있고, .com의 운영자로서는 버전의 차이와 피처 플래그 뒤의 코드 변화에 대한 영향을 걱정할 필요가 없습니다.
   • 이 분야에 대한 추가 지침과 문서가 개발되어야 합니다. 엔지니어들은 조직이 속한 셀에 대해 신경 쓸 필요가 없습니다. 따라서 피처 플래그 토글은 엔지니어가 신경 써야 하는 필요성을 추상화시킵니다.

제안된 실행 계획

인도 관점에서 셀 1.0, 1.5 및 2.0의 3가지 제안된 셀 반복 사이에 큰 변화는 없습니다. 분할은 특정 셀에 속한 조직을 위해 사용 가능한 기능의 범위를 줄이는 반복적인 접근 방식에 기반합니다. 배포적인 관점에서 첫 번째 반복에서 여러 보조 셀이 가능하도록 하고 무엇이 가능한지에 대한 로드맵을 연구해야 합니다.

반복

셀 1.0

이 반복에서의 목표는 셀을 구축하고 통합하기 위한 우리의 노력을 집중하는 것입니다. 다음 마일스톤과 그들의 퇴직 기준은 플랫폼 섹션의 공동 노력이며 여러 팀에 걸쳐 확장됩니다.

1. 전용 기술 스택 확장:
   • Instrumentor 및 AMP가 GCP를 지원
   • 셀이 Instrumentor에서 참조 아키텍처로 정의됨
2. 셀 클러스터 코디네이터를 위한 제어 평면
   • Switchboard는 현재 Dedicated에서 사용 중이지만 셀에 적합한 도구가 아닙니다. Deployment workflow에 통합될 수 있는지 평가하기 위해 Dedicated에서 생성된 다른 도구의 기능을 평가해야 합니다.
   • 전체 인프라를 수렴하는 셀 배치 구현
   • 링 개념의 구현: 초기에는 링 0 및 링 2만 존재
3. 첫 번째 보조 셀: 링 0의 QA 셀
   • 현재 도구를 사용하여 QA 셀로 배포를 수행하기 위한 현재 도구와의 통합
   • QA 셀에서 자체 QA 스모크 테스트 실행
   • QA 셀은 프로덕션 캐너리 단계와 병렬로 업데이트됨: QA 셀 장애는 소프트로 보여지며 auto_deploy를 차단하지 않음
4. 셀을 위한 제어 평면 - 개별 대시보드 및 경보
   • 가시성이 레거시 인프라와 적어도 동등함
   • 경보가 레거시 인프라와 적어도 동등함
5. 처음 고객 보조 셀: 링 2
   • release-tools가 PDM 실행 후 패키지를 ‘졸업’
   • 코디네이터가 링 2 배포를 관리함
6. 여러 보조 셀 지원
   • 코디네이터가 동일한 링에 여러 셀을 수렴시키도록 함

• 제한 사항:
  • 모든 보조 셀이 동일한 링, 링 2에 속함
  • 롤백은 가능하지만 모든 보조 셀에서 다운타임이 필요함

셀 1.5 및 2.0

다음 기능은 셀 1.5 및 2.0 사이에 분배될 수 있으며, 모두 운영 측면을 개선하기 때문에 그것들을 우리가 셀을 운영하는 데 더 많이 배우면서 우선순위를 정해야 합니다.

1. 셀을 위한 제어 평면 - 추가적인 링
   • 보조 셀은 여러 링에 분산될 수 있음
   • 다음 링으로의 배포는 현재 링이 수렴한 후 자동으로 시작됨
   • 긴급 브레이크: 다음 링으로의 패키지 롤아웃을 차단하는 기능
2. QA 셀이 auto-deploy를 차단하게 됨
3. 셀을 위한 제어 평면 - 클러스터 대시보드 및 경보
   • 대시보드는 특정 셀과 링 배포에 필요한 패키지를 나타내야 함
   • 원하는 버전을 실행하지 않는 모든 셀이 쉽게 파악되고 합리적인 시간 안에 수렴되지 않았다면 경보가 울려야 함
   • 링 내에서 패키지 롤아웃을 차단하기 위한 배포 건강 지표 (four golden signals의 z-점수?)
4. 셀의 포스트 디플로이 마이그레이션 (PDM) 단계를 응용프로그램 배포로부터 분리하여 셀 롤백을 수행할 수 있는 능력을 보장해야 함.
   • 이 능력이 없으면 롤백이 성공적으로 완료되려면 셀이 다운타임을 겪어야 함. 이는 방해적이며 현명한 해결책으로 간주되어서는 안 됨.
   • 기본 셀에서 PDM의 분리는 원하는대로 작동합니다. 따라서 주요 셀은 사건을 완화하기 위한 옵션으로 롤백을 가질 것입니다.
5. 깃랩 응용프로그램을 배포하는 것에만 타겟팅할 수 있도록 우리에게 가능하게 하는 수정된 도구화. 현재 사용할 도구가 전체 설치와 버전을 수렴하는 전략을 사용하므로, 긴 CI 파이프라인과 장시간 동작하는 작업이 발생합니다.
6. 자동 롤백 - 배포에 실패하면 어떤 이유에서든 자동으로 롤백 절차가 시작되어 해당 셀에 발생하는 중단을 최소화해야 합니다.

여기서의 초점은 지금까지 구축된 것을 프로덕션화하고 첫 반복(MVP 단계) 중에 발생한 기술 부채 영역을 정리하는 것입니다.

마인드맵

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

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

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

GitLab Dedicated 스택은 주로 Switchboard, Amp 및 Tenctl의 여러 도구들을 통해 GitLab의 설치를 제어하는 자체 방법을 갖고 있습니다. Switchboard의 사용은 Cells에 맞추어져 있지 않으므로 활용할 수 없습니다. Instrumentor 및 Amp와 같은 다른 도구들은 Dedicated 팀과 Cells 간에 더 이상 이동할 수 있도록 수정되거나 플랫폼에 대해 더 이동 가능하도록하기 위한 수정이 필요할 수 있습니다. 이러한 도구들과 Cells의 상호 작용 및 그들을 어떻게 활용할 수 있는지를 평가해야 할 것입니다. 작업이 어떻게 예정되느냐에 따라, 초기 기간 또는 Cells에 대한 MVP(최소 가치 제품) 기간 동안 요구 사항이 충족되도록 팀 멤버가 팀 간 경계를 넘어 밀접하게 협력하는 데 많은 노력이 필요할 수 있습니다.

이 단락에서는 데이터 리포지터리가 업데이트되어 배포할 원하는 버전을 가지고 있고, 이를 지원하기 위해 Cell 클러스터 코디네이터가 생성된 이상적인 상호 작용을 설명합니다.

Cell 1.0에서는 내부에 단일 보조 셀, QA Cell이 있을 것입니다. 우리는 release-tools을 확장하여 명령 도구를 사용하여 Cell 업데이트를 필요에 따라 수행해야 합니다.

release-tools은 graduated될 수 있도록 특정 셀에 자동화된 버전 업그레이드를 조화롭게 할 수 있도록 도와줄 것입니다.

절차

자동 배포

자동 배포는 당사의 기본 셀이 당사의 기존 .com 인프라와 동등하다는 것을 감안하여 오늘처럼 계속 작동해야 합니다. 따라서 자동 배포와 관련된 기존 절차는 여전히 활용될 수 있습니다. 핫 패치, 롤백, 자동 배포 선택, PDM, 기존 자동 배포 일정 등을 고려해야 할 새로운 절차를 추가해야 합니다. 이 새로운 기능을 추가해야 할 부분입니다.

• 자동 배포는 링 0 및 1로 제한됩니다.
  • 링 0에는 QA Cell과 .com 인프라의 카나리아 스테이지가 포함됩니다.
  • 링 1에는 .com 인프라의 본 스테이지가 포함됩니다. 이것은 release tools의 막다른 부분입니다.
  • 모든 셀이 동일한 방식으로 배포될 것입니다. 이는 다른 배포 기술을 처리할 필요가 없도록 합니다.
  • release-tools은 그들의 코디네이터 파이프라인의 일부로 링 0으로의 배포를 시도합니다.
• Release-tools는 반드시 패키지를 graduate할 수 있어야 합니다.
  • GitLab의 graduate 버전은 본 프로덕션의 메인 스테이지로의 성공적인 배포 및 게시 후 마이그레이션 (PDM)의 완료된 모든 auto-deploy 버전을 말합니다.
  • 이는 우리가 우리의 기존 절차를 사용하여 애플리케이션 코드가 잘못될 수도 있으므로 고심해본 높은 심각도의 이슈를 해결하기 위해 기대할 수 있을 것입니다.
  • 우리는 공식 릴리즈된 버전의 GitLab을 실행하고 싶어하지 않습니다. 왜냐하면 이들은 auto-deploy들보다 느리게 만들어지기 때문에 우리는 이상 반응 SLA를 놓칠 위험이 있습니다. Cell 아키텍처에서 대부분의 이슈는 Primary Cell에서 발견되어 수정된 후에 어디에든 배포되기 전에 고쳐져야 할 것입니다.
  • 매뉴얼 테스트를 통해 문제가 발견될 때 문제가 발생할 가능성이 있는 몇 가지 graduated 패키지의 배포를 중단할 수 있는 능력이 있도록 새로운 절차, runbook 및 문서가 필요할 것입니다.
  • 우리가 이러한 실패 사례를 추적하는 것이 현명할 것입니다. 실제로 QA는 문제를 찾아야 할 것이므로 우리가 자동화된 배포를 실행할 수 있는 여건을 만들어주기 위해서입니다.

현재, 일부 작은 컴포넌트는 .com 인프라에 자체 배포됩니다. 특히, Zoekt, Container Registry, Mailroom은 그들만의 새로운 버전을 제공할 정기적인 간격을 가지고 있습니다. 현재, 사용할 도구들로 인해 이 부분은 Secondary Cells로 가져오지지 않을 것입니다. 대신에, 빌드한 기본 브랜치에 지정된 기본 버전에 명시된 버전과 같이 내부적으로 안정화된 버전을 신뢰할 것입니다. 이는 우리의 릴리스가 어떻게 완성되었는지를 흉내내며 이로 인해 Cells와 잘 어울릴 것이기 때문입니다.

롤백

장기적으로, 셀에 배포 도구를 수정하여 각각의 셀에 안전하게 롤백할 수 있도록 하기 위한 유예 기간을 제공할 수 있도록 변경해야 할 것입니다. 현재의 경우, Primary Cell로서, 우리는 레거시 .com 또는 PDM을 일일에 한 번 실행하도록 유지하고 있습니다. 셀로의 배포를 실행하는 도구는 현재 PDM을 실행하지 않는 방법이 없습니다. 따라서 특정 셀에 장애 발생 시 또는 배포 후에 알림될 수 있는 장애를 완화하기 위해 절차화 및 도구 업데이트가 필요할 것입니다.

핫 패칭

핫 패칭은 문제를 완화할 수 있는 우리의 일부인 것입니다. 우리가 graduate 버전에 의존한다면, 핫 패처는 보조 셀을 위한 자리가 없을 것입니다. 하지만, 여전히 기본 셀에 활용될 수는 있을 것입니다. 그러나 더 안전한 배포 방법을 선호하여 핫 패칭을 없애는 것이 현명할 것입니다.

참조로, 우리는 2023년에 프로덕션을 핫 패칭한 적이 단 한 번 있습니다.

배포 헬스 메트릭

현재 .com 레거시 인프라의 Main 스테이지나 Primary Cell로의 배포를 자동화하지는 않습니다. 운영 부담을 줄이기 위해 존재하는 메트릭에 의존하여 특정 설치의 건강 지표를 형성하고 적절한 시간에 배포를 자동으로 트리거할 수 있어야 합니다. 이 배포 헬스 지표는 각 셀로 가져가야 할 것입니다. 여러 다양한 형식에서 암시된 것처럼, 자동 배포는 오늘처럼 상대적으로 유사하게 작동해야 합니다. Cells는 release-tools 파이프라인에 추가되어 트리거가 다른 영역에서 발생합니다. 트리거할 시기와 내용은 명확하게 정의되어야 합니다. 기대하는 것은 보조 셀이 GitLab의 graduate 버전만 수령하도록 하는 것입니다. 따라서 Primary Cell에서 PDM(Post Deployment Migration)이 성공적으로 실행될 때 해당 패키지는 graduate로 간주되고 다음 대상 링의 모든 셀로 배포할 수 있게 됩니다. 이미 우리가 Self-managed 고객을 위해 릴리스를 빌드할 때 바로 이 개념을 활용하고 있습니다. 이 분기점은 이미 릴리스 매니저들에게 자연스러운 것으로 여겨지며, 따라서 Cells 배포에 대한 좋은 이어져갈 요소가 됩니다.

가능한 빨리 셀로 배포할 수 있도록 노력해야 합니다. 단일 링에 존재하는 모든 셀에 대해 병렬로 배포할 수 있어야 합니다. 이렇게 함으로써 셀 간의 버전 이질성을 최소화하고 잠재적인 문제를 감소시킬 수 있습니다. 버전 이질성이 너무 커지면 자동 배포가 일시 중지되고 우리가 너무 뒤쳐진 이유를 조사합니다. 이러한 상황을 미리 알고 있다면 이상적입니다. 기대치는 PDM당 셀에 배포할 수 있는 것입니다. PDM이 건너 뛰어지는 날도 있습니다. 왜 PDM이 중단되는지 케이스별로 평가하여 우리의 셀 배포에 미치는 손해를 결정해야 합니다.

퍼미터 밖의 링은 오케스트레이션 엔진에 의해 Self-managed됩니다. release-tools가 패키지를 graduate시킨 후에는 잊어버리고 있습니다. 오케스트레이션 엔진은 원하는 GitLab 버전을 퍼미터 바깥의 첫 번째 링에 있는 모든 셀에 수렴하게 하고, 다음 링으로 넘어가는 것은 모든 셀이 수렴했을 때에만 가능합니다.

FAQ

개발자가 MR이 다양한 셀에 배포될 때 지표를 볼 수 있을까요?

아니요. 우리 현재의 라벨링 스키마는 주로 커밋이 프로덕션에 착륙했음을 보여주고, PDM이 성공적으로 실행되어 해당 관찰된 커밋이 Self-managed 고객을 위한 릴리스에 배치될 수 있는 안전한 상태임을 보여주는 데 주로 사용됩니다. 이 단계에 도달한 후, 패키지에 문제가 거의 없으므로 우리가 배포의 여러 링으로 나아갈 때 이슈/MR을 상태로 업데이트할 필요가 없습니다. 개발자들은 배포된 버전이 어떤 셀에 배포되었는지 신경 쓸 필요가 없습니다.

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

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

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

릴리스 및 자동 배포 절차는 크게 동일하게 유지해야합니다. 우리가 코드를 랜딩시키는 곳이 변하는 것입니다. 이 영역의 변경 사항은 Iteration 2.0에 가까울수록 가장 크게 증가할 것입니다. GitLab의 여러 환경이나 스테이지가 변경되기 시작할 때에 해당하는 경우에만.

하나의 티어를 제외한 모든 티어가 실패한 배포, 그 패키지를 모든 셀로 롤백하는 것을 트리거하는 것이 무엇인가요?

우리가 이에 대해 반복하고 프로세스를 개발하길 원할 특성에 따라 다릅니다. 예를 들어, 첫 번째 티어의 첫 번째 셀에서 실패할 경우 해당 셀을 조사해야 하지만, 모든 셀에 이러한 증상이 전반적인지 확인해야 합니다. 이러한 경우에는 케이스별로만 처리할 수 있습니다. 마지막 티어와 마지막 셀에 도달하고 어떤 실패가 발생한다면, 다른 셀을 롤백할 이유가 없어야 합니다. 충분한 시간이 경과하여 애플리케이션 실패를 잡을 수 있어야 하기 때문입니다.

Self-managed 릴리스는 무슨 일이 일어날까요?

이론적으로는 크게 변경되지 않습니다. 현재 우리는 프로덕션, 또는 .com의 Main 스테이지를 Self-managed할 수 있는 상태로 변경할 수 있으려는 변경의 증거로 사용하고 있습니다. Cellular 구조에서 이 개념은 동일한 위치에 존재하게 됩니다. 단지 용어가 변경될 뿐입니다. 이 경우에는 graduate 패키지가 이제 릴리스할 수 있는 안전한 것으로 간주됩니다.

PreProd에는 무슨 일이 일어날까요?

이 인스턴스는 릴리스 후보 생성 시에 GitLab 패키지 및 Helm 차트의 혼합 설치를 테스트합니다. 이것은 릴리스가 태그되기 전에 마지막 단계입니다. 이는 Cellular 작업에 영향을 받지 않습니다. 그러나 우리는 preprod를 관리하는 방식을 바꿀 수 있습니다.

Staging에는 무슨 일이 일어날까요?

Staging은 배포의 장기간 인스턴스 테스트와 QA와 함께 중요합니다. 가설적으론 Staging은 대신 티어 0에 배포할 수 있으려고 완전히 사라질 수도 있습니다. 위의 Iteration 3을 참조하세요 {+TODO 적절한 링크 추가+}

Ops에는 무슨 일이 일어날까요?

변경할 필요가 없습니다. 그러나 세포 관리가 쉬워지면 가능한 한 작동 방식을 유사하게 만드는 것이 현명할 것입니다. 운영 팀이 많은 인스턴스에 대한 독특한 지식으로 과부담을 가지 않도록 하기 위해.

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