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
ongoing	`@jarv`	`@None`			2024-01-29

지역 복구

지역 복구의 회복 시간 목표(RTO) 및 회복 지점 목표(RPO) 개선

다음은 지역 복구의 RTO를 48시간으로 줄이는 데 제한 요인으로 작용하는 주요 도전과제입니다.

쉐프를 사용하여 관리되는 유수의 레거시 인프라가 있습니다. 이 구성은 관리하기 어렵고, 대체 지역에서 새로운 인프라를 만들기 위해 많은 양의 매뉴얼 복사와 복제가 필요합니다.
운영 인프라는 단일 지역 us-central1에 위치해 있습니다. 이 지역에서의 지역 장애 발생 시, 런북과 툴링 스크립트의 지역 복사본만을 사용해 운영 인프라를 다시 구축해야 합니다.
관측 가능성은 단일 지역에 호스팅됩니다.
도커 이미지 및 패키지를 생성하는 인프라(dev.gitlab.org)는 단일 지역에 위치해 있으며, 단일 장애 지점입니다.
지역을 전환하여 프로비저닝하는 것을 허용하지 않는 IaC(Infrastructure-as-Code)로 인해, 본인들에게 지역 전환 기능을 제공하는 발사대가 없습니다.
새로운 지역에서 필요한 대규모 SSD 양을 구축하기 어렵다는 점에 대해, Google이 우리에게 필요한 용량을 제공할 자신이 없습니다.
내부 DNS에 대해 글로벌 DNS를 사용하고 있어 여러 지역에서 동일한 이름을 갖는 여러 인스턴스를 사용하는 것이 어렵습니다. 또한, 내부 엔드포인트(대시보드, 로그 등)의 DNS 이름에 지역을 포함시키지 않습니다.
RPO를 줄이기 위해 다른 지역에 레플리카를 배포하더라도 지연 시간이나 클라우드 비용 영향에 대해 아직 확신할 수 없습니다.
구글 클라우드 플랫폼에서 Compute, 네트워크, API에 대한 특별/협상된 할당량이 단일 지역에만 적용된 것이며, 새로운 지역에서 이러한 할당량을 일치시키고 동기화시켜야 합니다.
1개의 지역에서 트래픽을 다른 지역으로 돌리는 방법을 표준화하지 않았습니다.
모니터링 및 구성에서 us-east1 지역을 하드코딩한 경우가 있습니다.

지역 복구 작업 스트림

우리의 지역 복구 계획의 첫 번째 단계는 대량의 매뉴얼 단계가 관련된 새로운 인프라를 회복 지역에 생성하는 것입니다. 복구를 위해 우리에게 발판을 제공하기 위해, 새로운 GCP 지역에 “지역 분리” 배포를 제안합니다.

“지역 분리”는 다음 요구 사항을 충족합니다:

특정 지역이 할당됩니다.
할당량이 설정되고 동기화되어 새 지역에서 us-east1을 복제할 수 있습니다.
동일 VPC에서 us-east1과 동일한 하위넷이 할당되거나 예약됩니다.
클라우드 지출을 낮추면서 RTO를 낮추는 데 유용한 곳에 일부 인프라가 배포됩니다.

다음은 대부분 병렬로 수행할 수 있는 작업 스트림입니다. 지역 복구의 최종 목표는 대량 분리를 통해 대안 지역으로부터 us-east1로의 전체 데이터 복원을 위한 기본 구조가 있는 것입니다.

대체 지역 선택

우리는 us-central1을 선택했습니다. 이에 대한 토론은 https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25094에서 이루어졌습니다.

의존성: 없음
팀: 운영

재해 복구를 위한 대체 지역을 선택할 때 고려해야 할 사항은 다음과 같습니다:

컴퓨팅 사용량을 충족시키기 위해 충분한 용량이 있는지 확인합니다.
네트워크 및 네트워크 지연 요구사항(있는 경우)
지역 간의 기능 동등성

새로운 지역에서 프론트엔드 서비스를 지원하는 Kubernetes 클러스터 배포

의존성: 외부 프론트엔드 로드 밸런싱
팀: 운영, 기초 시설, 제공

GitLab.com에는 웹, API, Git, Git HTTPs, Git SSH, 페이지, 레지스트리가 프론트엔드 서비스로 있습니다. 이러한 서비스는 모두 us-east1에 배포된 4개의 Kubernetes 클러스터에서 실행됩니다. 이러한 서비스들은 상태가 없거나 데이터를 위한 멀티 리전 스토리지 버킷을 사용합니다. us-east1에서 장애가 발생하는 경우, 대체 지역에서 이러한 클러스터를 다시 구축하고 배포를 위해 설정해야 합니다.

글로벌 DNS에서 존별 DNS로 전환

의존성: 없음
팀: Gitaly

단일 장애 지점인 Gitaly VM들은 us-east1에 배포된 단일 장애 지점입니다. 노드의 내부 DNS 이름은 다음과 같은 규칙을 따릅니다:

gitaly-01-stor-gprd.c.gitlab-gitaly-gprd-ccb0.internal
 ^ 이름                    ^ 프로젝트

존별 DNS로 전환함으로써, 내부 DNS 항목을 변경하여 DNS 이름에 지역을 포함하도록 설정할 수 있습니다:

gitaly-01-stor-gprd.c.us-east1-b.gitlab-gitaly-gprd-ccb0.internal
 ^ 이름                  ^ 존     ^ 프로젝트

이를 통해, 새로운 지역이나 존으로 복구할 때 동일한 이름을 유지할 수 있습니다.

gitaly-01-stor-gprd.c.us-east1-b.gitlab-gitaly-gprd-ccb0.internal
gitaly-01-stor-gprd.c.us-east4-a.gitlab-gitaly-gprd-ccb0.internal

Kubernetes 밖의 VM fleet의 경우, 이러한 이름들은 복구 지역에서 동일한 노드 이름을 갖도록 합니다.

Gitaly

의존성: 글로벌 DNS에서 존별 DNS로 전환 (선택 사항, 그러나 원하는 선택 사항)
팀: Gitaly, 운영, 기초 시설

전체 Gitaly fleet을 복원하는 데는 새로운 지역에 배포된 많은 수의 VM이 필요합니다. 또한 디스크 스냅샷을 기반으로 복원하는 데 많은 대역폭이 필요합니다. 성공적인 Gitaly 복원을 보장하기 위해, 할당량을 us-east1과 동기화시켜야 하며, 최종 검증이 필요합니다.

PostgreSQL

의존성: 사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간을 개선 (선택 사항, 그러나 원하는 선택 사항), 대체 지역에서의 로컬 백업(데이터 디스크 스냅샷 및 WAL 아카이빙).
팀: 데이터베이스 신뢰성, 운영

Patroni 프로비저닝용 구성에서는 단일 지역당 클러스터만 허용됩니다. 대체 지역에 대해 네트워킹 인프라, Consul, 로드 밸런서를 설정해야 합니다. 복제 시간을 줄이기 위해 데이터베이스에 “계층화된 클러스터”를 설정할 수 있습니다.

Redis

의존성: 사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간을 개선 (선택 사항, 그러나 원하는 선택 사항)
팀: 운영

Redis를 프로비저닝하려면 대체 지역에서의 서브넷이 할당되어야 하며, 새로운 배포의 최종 검증이 필요합니다.

외부 프론트엔드 로드 밸런싱

의존성: HAProxy 교체, 아마도 GKE 게이트웨이 및 Istio
팀: 운영, 기초 시설

대체 지역에서의 배포를 검증하기 위해 외부 프론트엔드 로드 밸런싱이 필요합니다. 모든 프론트엔드 서비스에는 외부 및 내부 로드 밸런서가 필요합니다.

모니터링

의존성: 인프라를 Chef에서 이동하여 인프라의 X% Chef 의존성 제거 (Prometheus 인프라를 Kubernetes로 이전)
팀: 확장성:가시성, 운영, 기초 시설

다른 지역에서 0 복제본으로 스케일 다운된 대체 Ops Kubernetes 클러스터를 설정합니다.

러너

의존성: 사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간을 개선 (선택 사항, 그러나 원하는 선택 사항)
팀: 확장성:실천, 운영, 기초 시설

대체 지역에서 runner 매니저 및 일시적 VM에 대한 할당량이 설정되었는지 확인하고, 피어링 구성을 통한 네트워킹 구성을 설정 및 검증합니다.

운영 및 패키징

의존성: 단일 존 장애로 인한 장애를 피하기 위한 HA Chef 서버 구성 생성
팀: 확장성:Practices, 운영, 기초, 배포

모든 이미지 생성 및 패키징은 단일 VM에서 수행되며, 운영 도구도 단일 VM에 있습니다. 이 두 가지 모두 지역적 장애가 발생하면 스냅숏에서 다시 빌드해야 하고 약 4시간의 데이터가 손실될 수 있는 장애 지점입니다.

다음은 이 리스크를 완화하기 위한 옵션들입니다.

패키징 작업을 ops.gitlab.net로 이동하여 단일 장애 지점인 dev.gitlab.org을 제거합니다.
ops.gitlab.net에 Geo 기능을 사용합니다.

지역 복구 게임데이

의존성: 복구 개선
팀: 운영

지역 복구를 위한 개선 사항을 따라서 프로시저의 종단간 테스트를 위해 게임데이가 실행되어야 합니다. 검증된 후 기존 재해 복구런북에 추가될 수 있습니다.