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

지역 복구

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

다음은 RTO를 지역 복구를 위해 48시간으로 끌어올리는 능력을 제한하는 최우선 과제들을 나열한 것입니다.

  1. 우리는 Chef를 사용하여 관리되는 상당량의 레거시 인프라를 보유하고 있습니다. 이 구성은 우리에게 어렵게 만들어져 새로운 인프라를 대체 지역에서 만들기 위해 많은 양의 수동 복사 및 복제를 필요로 합니다.

  2. 운영 인프라는 단일 지역인 us-central1에 위치해 있습니다. 이 지역의 지역 장애 발생 시, 우리는 런북과 도구 스크립트의 로컬 복사만으로 운영 인프라를 다시 구축해야 합니다.

  3. 관측성은 단일 지역에 호스팅되어 있습니다.

  4. 도커 이미지 및 패키지를 빌드하는 인프라(dev.gitlab.org)는 단일 지역에 위치하고 있으며, 단일 장애 지점입니다.

  5. 우리에게 지역 전환을 위한 인프라스트럭처가 헤드스타트를 제공할 수 있는 런칭패드가 없습니다. 우리의 IaC(Infrastructure-as-Code)는 우리에게 프로비저닝을 위해 지역을 전환할 수 있는 기능을 제공하지 않습니다.

  6. 우리는 구글이 우리에게 새로운 지역에서 필요한 대용량 SSD를 제공할 수 있을지에 대한 확신이 없습니다.

  7. 우리는 내부 DNS에 글로벌 DNS를 사용하고 있어, 여러 지역에서 동일한 이름을 가진 여러 인스턴스를 사용하기가 어렵습니다. 우리는 또한 내부 엔드포인트의 DNS 이름에 지역을 통합하지 않습니다(예: 대시보드, 로그 등).

  8. RPO를 줄이기 위해 다른 지역에 복제를 배포하는 경우, 아직 지연 시간이나 클라우드 비용 영향에 대해 확신이 없습니다.

  9. 우리는 구글 클라우드 플랫폼에서 컴퓨트, 네트워크 및 API에 대해 특별/협상된 할당량 증가를 받았으며, 이는 단일 지역에 대해서만 적용되며, 이러한 할당량을 새로운 지역에 맞추고 동기화해야 합니다.

  10. 우리는 엣지에서 트래픽을 다른 지역으로 돌리는 방법을 표준화하지 않았습니다.

  11. 모니터링 및 구성에 있어 우리는 us-east1 지역을 하드코딩한 곳이 있습니다.

지역 복구 작업 스트림

우리의 지역 복구 계획의 첫 번째 단계는 대량의 수동 단계를 포함하여 복구 지역에 새로운 인프라를 생성하는 것입니다. 복구를 위해 우리에게 헤드스타트를 제공하기 위해, 우리는 GCP의 새로운 지역에 “지역 대두” 배포를 제안합니다.

“지역 대두”는 다음 요구 사항들을 충족해야 합니다:

  1. 특정 지역이 할당되어 있어야 합니다.
  2. 할당량이 설정되고 동기화되어 있어, 우리가 새로운 지역에서 us-east1을 모두 복제할 수 있어야 합니다.
  3. 서브넷이 또는 예약되어야합니다. us-east1을 위한 동일한 VPC에서.

다음은 대부분 병렬로 수행 될 수있는 작업 스트림입니다. 지역 복구의 최종 목표는 대체 지역으로부터 us-east1로의 모든 데이터 복원을 위한 기본 골조를 가진 대두가 있는 것입니다. 이 대두는 복구 지역에서 us-east1로의 완전한 데이터 복원을 위한 통로로 사용될 수 있습니다.

대체 지역 선택

  • 의존성: 없음
  • 팀: 운영

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

  1. 컴퓨트 사용량을 충족 할 수 있는 용량이 있는지 확인합니다.
  2. 네트워크 및 네트워크 지연 요구 사항(있는 경우)
  3. 지역 간의 기능 동등성.

배포를 지원하는 새로운 지역에서 프런트엔드 서비스를 지원하는 Kubernetes 클러스터를 배포합니다.

GitLab.com은 웹, API, Git, Git HTTPs, Git SSH, Pages 및 레지스트리를 프런트엔드 서비스로 제공합니다. 이러한 서비스는 모두 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 모음의 경우, 이러한 이름을 통해 복구 지역에서 동일한 노드 이름을 가질 수 있습니다.

Gitaly

  • Dependencies: 전역 DNS에서 존 DNS로 전환(#switch-from-global-to-zonal-dns) (optional, but desired)
  • 팀: Gitaly, 운영, Foundations

전체 Gitaly 플릿을 복원하려면 대체 영역에 배포된 많은 수의 VM이 필요합니다. 또한 복원은 디스크 스냅숏을 기반으로 하기 때문에 많은 대역폭이 필요합니다. 성공적인 Gitaly 복원을 보장하기 위해서는 할당량을 us-east1과 동기화해야 하며, 단대역 검증이 필요합니다.

PostgreSQL

  • Dependencies: 사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간 개선(zonal.md#improve-chef-provisioning-time-by-using-preconfigured-golden-os-images) (optional, but desired), 대체 영역의 로컬 백업(데이터 디스크 스냅숏 및 ‘WAL’ 아카이빙)
  • 팀: 데이터베이스 안정성, 운영

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

Redis

  • Dependencies: 사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간 개선(zonal.md#improve-chef-provisioning-time-by-using-preconfigured-golden-os-images) (optional, but desired)
  • 팀: 운영

Redis 서브넷을 대체 영역에 할당하고 새로운 배포물의 단대역 검증을 수행해야 합니다.

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

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

모니터링

  • Dependencies: 인프라를 Chef에서 이동하여 인프라의 X% Chef 종속성 제거(zonal.md#eliminate-x-chef-dependencies-in-infra-by-moving-infra-away-from-chef) (Prometheus 인프라를 Kubernetes로 이관)
  • 팀: 확장성:관측, 운영, Foundations

다른 영역에 크기가 0개의 복제본으로 축소된 대체 운영 Kubernetes 클러스터를 설정합니다.

러너

  • Dependencies: 사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간 개선(zonal.md#improve-chef-provisioning-time-by-using-preconfigured-golden-os-images) (optional, but desired)
  • 팀: 확장성:실천, 운영, Foundations

대체 영역에서 실행자 관리자 및 겨시 VM의 할당량이 us-east1과 일치하고, 피어링 구성으로 네트워킹 구성을 설정하고 확인합니다.

운영 및 패키징

  • Dependencies: 단일 영역 장애 시 정전을 피하기 위한 HA Chef 서버 구성 생성(zonal.md#create-an-ha-chef-server-configuration-to-avoid-an-outage-for-a-single-zone-failure)
  • 팀: 확장성:실천, 운영, Foundations, 배포

모든 이미지 생성 및 패키징은 단일 VM에서 수행되며, 운영 도구도 단일 VM에 있습니다. 이 두 가지는 지역 장애가 발생하는 경우 스냅샷에서 다시 작성해야 하며, 약 4시간의 데이터가 손실됩니다.

다음은 이 위험을 완화하는 옵션입니다:

  • 패키징 작업을 ops.gitlab.net으로 이전하여 dev.gitlab.org를 단일 장애점으로 제거합니다.
  • ops.gitlab.net의 Geo 기능 사용 ### 지역 복구 게임데이

  • Dependencies: 복구 개선
  • 팀: 운영

지역 복구 개선 사항에 이어 프로시저의 단대역 테스트를 위해 게임데이를 실행해야 합니다. 검증이 완료되면 기존 재해 복구 런북에 추가할 수 있습니다.