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

# Zonal Recovery

Zonal Recovery의 RTO (Recovery Time Objective) 및 RPO (Recovery Point Objective) 개선

다음은 현재의 DR 도전 과제를 나타내며, 해당 아키텍처 청사진에서 해결해야 할 문제 후보입니다.

  1. Postgres 레플리카는 용량이 거의 가득 차 있으며, 매뉴얼으로 확장됩니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다. 장애 조치용으로 과도한 프로비저닝은 상당한 클라우드 비용이 발생합니다(자세한 내용은 문서 맨 끝의 제안 섹션 참조).
  2. HAProxy(로드 밸런싱)는 매뉴얼으로 확장되며, Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다.
  3. CI 실행 매니저는 2개의 가용 영역에서 실행되며 용량이 거의 가득 차 있습니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다.
  4. 가용 영역 내에는 병목 현상 제한이 있으며, 로드가 실패한 가용 영역에서 이격되면 매뉴얼으로 조정해야 하는 레플리카의 수가 있습니다.
  5. Gitaly의 RPO는 디스크 스냅샷의 빈도로 제한되고, RTO는 Terraform CI 파이프라인 및 Chef 구성을 통해 프로비저닝 및 구성하는 데 소요되는 시간에 따라 제한됩니다.
  6. Chef로 관리되는 VM에서 수집한 메트릭을 모니터링하는 인프라는 2개의 가용 영역에 중복되어 있고, 매뉴얼으로 확장됩니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다.
  7. 모든 Chef로 관리되는 VM의 구성을 담당하는 Chef 서버는 us-central1에 위치한 단일 장애 지점입니다. 로컬 Postgres 데이터베이스와 로컬 디스크가 있습니다.
  8. Docker 이미지 및 패키지 빌드를 담당하는 dev.gitlab.org 인프라는 단일 지역에 위치하고 있으며, 단일 장애 지점입니다.

Zonal recovery 작업 스트림

Zonal 복구 주변의 개선 작업은 자동으로 확장되지 않는 플리트의 프로비저닝 시간을 단축하는 데 중점을 두고 있습니다. 이미 HAProxy와 같은 정적으로 할당된 VM을 완전히 제거하는 데 진행 중인 작업이 있습니다. 또한 Gitaly, PostgreSQL 및 Redis와 같이 자동으로 확장할 수 없는 플리트의 시작 및 구성 시간을 단축하는 데 노력을 기울일 수 있습니다.

단일 영역 장애를 흡수하기 위한 과도한 프로비저닝

  • 의존성: 없음
  • 팀: 운영, 확장성:실천, 데이터베이스 신뢰성

모든 Chef로 관리되는 VM 플리트는 용량이 거의 가득 차 있으며, Terraform/Chef를 사용하여 매뉴얼으로 확장하고 프로비저닝해야 합니다. 한 가용 영역의 장애 발생 시, 본래 복구 시간 목표가 추가 서버를 Terraform을 통해 프로비저닝하는 데 필요합니다. 이를 회피하는 한 가지 방법은 추가 용량 한 영역분을 가지고 있는 과도하게 프로비저닝하는 것입니다.

  1. Patroni Main(n2-highmem-128 6.5k/month): 추가 노드 3개로 월 20k 추가
  2. Patroni CI(n2-highmem-96 5k/month): 추가 노드 3개로 월 15k 추가
  3. HAProxy(t2d-standard-8 285/month): 추가 노드 20개로 월 5k 추가
  4. CI Runner managers(c2-standard-30 1.3k/month): 추가 노드 60개로 월 78k 추가

Kubernetes 가로 자동 확장기 (HPA)는 전달 서비스에 구성된 최대 파드 수를 가지고 있습니다. 이는 데이터베이스와 같은 하류 의존성을 확장 이벤트로 인한 포화로부터 보호하기 위해 구성되어 있습니다. 한 가용 영역을 빠르게 확장할 수 있게 하려면 이러한 한계를 조정하거나 재검토해야 합니다.

로드 밸런싱 레이어로서의 HAProxy 제거

  • 의존성: 없음
  • 팀: 기초 시설

HAProxy는 us-east1의 3가지 AZ에 정적으로 할당된 Chef로 관리되는 VM 플리트입니다. 한 가용 영역의 장애 발생 시 이 플리트를 신속히 확장해야 하므로 RTO가 증가합니다.

FY24Q4에 기초 시설팀에서 비 프로드 환경에서 Istio 사용을 위한 개념 증명에 착수했습니다. FY25에는 Istio 및 GKE Gateway를 사용하여 HAProxy 대체본을 예상합니다. 이 작업을 완료하면 로드 밸런싱 레이어에 대한 영향이 줄어들며, HAProxy 플리트를 매뉴얼으로 확장할 필요가 사라집니다. 또한 약 17k/month를 HAProxy 노드에 사용하고 있으므로 이 플랫폼을 줄일 수 있다면 클라우드 지출을 줄일 수도 있습니다.

단일 영역 장애를 위한 HA Chef 서버 구성 생성

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

Chef는 Kubernetes 외부의 워크로드를 구성하는 데 책임이 있습니다. 이는 us-central1-b에 있는 단일 장애 지점입니다. 데이터는 로컬 디스크에 유지되며, 아직 고가용성 구성으로 이동하는 것에 대해 조사하지 않았습니다. us-central1-b의 한 가용 영역 장애가 발생하는 경우 서버는 스냅샷에서 다시 구축되어 최대 4시간의 데이터 손실이 발생합니다.

단일 영역 장애를 위한 HA Packaging 서버(dev.gitlab.org) 구성 생성

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

us-east1-c에서 한 가용 영역 장애가 발생하는 경우 서버는 스냅샷에서 다시 구축되어 최대 4시간의 데이터 손실이 발생합니다. 이 호스트의 추가적인 과제는 GitLab-CE 인스턴스이므로 기능이 제한될 것입니다. 가장 적절한 접근 방법은 아마도 패키징 CI 파이프라인을 ops.gitlab.net로 이동하는 것일 것입니다.

사전 구성된 골든 OS 이미지를 사용하여 Chef 프로비저닝 시간 개선

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

2022년 Gitaly 플리트 업그레이드를 위해 골든 OS 이미지를 빌드하는 예정된 CI 파이프라인이 생성되었습니다. 우리는 이 작업을 재개하고 Gitaly 및 다른 VM을 위한 이미지를 생성하여 구성 시간을 단축할 수 있습니다. 이미지를 사용하면 복구 시간을 약 15분 단축하여 Zonal 장애에 대한 RTO를 개선할 수 있다고 추정됩니다.

인프라에서 Chef 의존성 X% 제거

  • 의존성: 없음
  • 팀: 운영, 확장성:가시성, 확장성:실천

Gitaly, PostgreSQL, CI 실행 매니저, HAProxy, Bastion, CustomersDot, Deploy, DB Lab, Prometheus, Redis, SD Exporter, 및 Console 서버는 모두 Chef로 관리됩니다. 복구 속도를 개선하기 위해 해당 인프라를 Kubernetes 또는 Ansible로 이동할 수 있습니다.

Gitaly 스냅샷 복원을 위한 Write-ahead-log

  • 의존성: 없음
  • 팀: Gitaly

Gitaly의 RPO를 줄이기 위해 FY25Q1에 계획된 작업이 있습니다.