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

Zonal Recovery

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

다음은 현재의 재해 복구(DR) 도전 과제를 나타내며, 이 아키텍처 청사진에서 다룰 문제 후보입니다.

  1. Postgres 복제본은 용량 근처에서 실행되며 수동으로 확장됩니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다. Zone 장애를 흡수하기 위해 과도한 프로비저닝은 상당한 클라우드 지출을 추가할 것입니다(자세한 내용은 문서 맨 아래의 제안 섹션 참조).
  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 서버는 모든 Chef로 관리되는 VM의 구성을 담당하며 us-central1에 위치한 단일 장애 지점입니다. 지역적인 단일 장애 지점으로 us-central1에 위치하며 로컬 Postgres 데이터베이스와 로컬 디스크에 파일이 저장되어 있습니다.
  8. Docker 이미지 및 패키지를 빌드하는 인프라(dev.gitlab.org)는 단일 지역에 위치하고 있으며, 단일 장애 지점입니다.

Zone 복구 작업 스트림

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

단일 Zone 장애를 흡수하기 위한 과다 프로비저닝

  • 의존성: 없음
  • 팀: Ops, Scalability:Practices, Database Reliability

모든 Chef로 관리되는 VM 플릿은 용량에 근접하게 실행되며 Terraform/Chef를 사용하여 수동으로 확장 및 프로비저닝이 필요합니다. Zone 장애의 경우 Terraform을 통해 서버를 더 프로비저닝하는 것이 복구 시간 목표에 도움이 됩니다. 이를 피하는 한 가지 방법은 과다 프로비저닝하여 전체 Zone의 추가 용량을 확보하는 것입니다.

  1. Patroni Main (n2-highmem-128 6.5k/월): 추가 노드 3개당 +20k/월
  2. Patroni CI (n2-highmem-96 5k/월): 추가 노드 3개당 +15k/월
  3. HAProxy (t2d-standard-8 285/월): 추가 노드 20개당 +5k/월
  4. CI 러너 관리자 (c2-standard-30 1.3k/월): 추가 노드 60개당 +78k/월

Kubernetes 수평 자동 스케일러(HPA)는 프런트엔드 서비스에 구성된 최대 Pod 수를 가지고 있습니다. 이는 데이터베이스와 같은 하향 의존성을 보호하기 위해 구성됩니다. 우리가 Zone을 빠르게 확장하도록 허용한다면, 이러한 제한은 재해 복구 상황을 고려했을 때 조정되어야 합니다.

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

  • 의존성: 없음
  • 팀: Foundations

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

FY24Q4에 Foundations 팀은 비 프로드 환경에서의 Istio 사용에 대한 개념 증명 작업을 시작했습니다. FY25에는 Istio 및 GKE Gateway를 사용한 HAProxy의 대체를 예정하고 있습니다. 이 작업을 완료하면 재해로 인한 영역 별 장애로 인한 LoadBalancing 레이어에 대한 영향을 줄일 수 있으며, 수동으로 HAProxy 플릿을 확장할 필요가 없어집니다. 추가로, HAProxy 노드에 약 17k/월을 지출하고 있으므로, 이 풋프린트를 줄일 수 있다면 클라우드 지출이 감소할 수 있습니다.

단일 Zone 장애를 피하기 위한 HA Chef 서버 구성 생성

  • 의존성: 없음
  • 팀: Ops

Chef는 Kubernetes 밖의 워크로드가 있는 VM을 구성하는 역할을 합니다. 이는 우리가 us-central1-b에 위치한 단일 장애 지점입니다. 데이터는 로컬 디스크에 지속됩니다. 아직 고가용성으로 이동하는 것에 대한 조사를 진행하지 않았습니다. us-central1-b의 영역적 장애의 경우 서버를 스냅샷에서 다시 빌드해야 하며 최대 4시간의 데이터가 손실될 수 있습니다.

Zonal Recovery Work-streams

복구 시간 목표를 더 잡지 않는 자동으로 확장되지 않는 플릿에 대해 프로비저닝 시간을 개선하기 위한 작업이 진행 중입니다. 이미 HAProxy와 같이 정적으로 할당된 VM을 완전히 제거하기 위한 진행 중인 작업이 있습니다. 또한 Gitaly, PostgreSQL 및 Redis와 같이 자동으로 확장할 수 없는 플릿에 대해 프로비저닝 및 구성 시간을 단축할 수 있는 노력을 기울일 수 있습니다.

단일 존 장애를 피하기 위한 HA Packaging 서버(dev.gitlab.org) 구성

  • Dependencies: 없음
  • Teams: Ops

us-east1-c 존의 장애의 경우 서버를 스냅숏에서 다시 빌드해야 하며, 최대 4시간의 데이터가 손실될 수 있습니다. 이 호스트의 추가적인 도전 과제는 GitLab-CE 인스턴스이므로 기능이 제한될 것입니다. 가장 좋은 접근 방법은 아마도 packaging CI 파이프라인을 ops.gitlab.net로 이동하는 것일 것으로 보입니다.

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

  • Dependencies: 없음
  • Teams: Ops

2022년 Gitaly fleet 업그레이드를 위해 예약된 CI 파이프라인이 생성되어 골든 OS 이미지를 빌드했습니다. 이 작업을 재개하고 Gitaly 및 기타 VM의 이미지를 생성하여 구성 시간을 단축할 수 있습니다. 이미지를 사용하면 회복 시간을 약 15분 단축하여 존 장애에 대한 RTO를 개선할 수 있을 것으로 추정됩니다.

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

  • Dependencies: 없음
  • Teams: Ops, Scalability:Observability, Scalability:Practices

Gitaly, Postgres, CI 러너 매니저, HAProxy, Bastion, CustomersDot, Deploy, DB Lab, Prometheus, Redis, SD Exporter 및 Console 서버는 Chef로 관리됩니다. 회복 속도를 향상시키기 위해, 이 인프라를 Kubernetes 또는 Ansible로 이동하여 구성 관리를 할 수 있습니다.

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

  • Dependencies: 없음
  • Teams: Gitaly

Gitaly에 RPO를 줄이기 위한 트랜잭션 로그를 추가하는 FY25Q1에 계획된 작업이 있습니다.