Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
ongoing |
@jarv
|
@None
| 2024-01-29 |
- Zonal Recovery의 RTO (Recovery Time Objective) 및 RPO (Recovery Point Objective) 개선
- Zonal recovery 작업 스트림
# Zonal Recovery
Zonal Recovery의 RTO (Recovery Time Objective) 및 RPO (Recovery Point Objective) 개선
다음은 현재의 DR 도전 과제를 나타내며, 해당 아키텍처 청사진에서 해결해야 할 문제 후보입니다.
- Postgres 레플리카는 용량이 거의 가득 차 있으며, 매뉴얼으로 확장됩니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다. 장애 조치용으로 과도한 프로비저닝은 상당한 클라우드 비용이 발생합니다(자세한 내용은 문서 맨 끝의 제안 섹션 참조).
- HAProxy(로드 밸런싱)는 매뉴얼으로 확장되며, Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다.
- CI 실행 매니저는 2개의 가용 영역에서 실행되며 용량이 거의 가득 차 있습니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다.
- 가용 영역 내에는 병목 현상 제한이 있으며, 로드가 실패한 가용 영역에서 이격되면 매뉴얼으로 조정해야 하는 레플리카의 수가 있습니다.
- Gitaly의
RPO
는 디스크 스냅샷의 빈도로 제한되고,RTO
는 Terraform CI 파이프라인 및 Chef 구성을 통해 프로비저닝 및 구성하는 데 소요되는 시간에 따라 제한됩니다. - Chef로 관리되는 VM에서 수집한 메트릭을 모니터링하는 인프라는 2개의 가용 영역에 중복되어 있고, 매뉴얼으로 확장됩니다. 새로운 인스턴스는 Terraform CI 파이프라인과 Chef 구성을 거쳐야 합니다.
- 모든 Chef로 관리되는 VM의 구성을 담당하는 Chef 서버는
us-central1
에 위치한 단일 장애 지점입니다. 로컬 Postgres 데이터베이스와 로컬 디스크가 있습니다. - Docker 이미지 및 패키지 빌드를 담당하는
dev.gitlab.org
인프라는 단일 지역에 위치하고 있으며, 단일 장애 지점입니다.
Zonal recovery 작업 스트림
Zonal 복구 주변의 개선 작업은 자동으로 확장되지 않는 플리트의 프로비저닝 시간을 단축하는 데 중점을 두고 있습니다. 이미 HAProxy와 같은 정적으로 할당된 VM을 완전히 제거하는 데 진행 중인 작업이 있습니다. 또한 Gitaly, PostgreSQL 및 Redis와 같이 자동으로 확장할 수 없는 플리트의 시작 및 구성 시간을 단축하는 데 노력을 기울일 수 있습니다.
단일 영역 장애를 흡수하기 위한 과도한 프로비저닝
- 의존성: 없음
- 팀: 운영, 확장성:실천, 데이터베이스 신뢰성
모든 Chef로 관리되는 VM 플리트는 용량이 거의 가득 차 있으며, Terraform/Chef를 사용하여 매뉴얼으로 확장하고 프로비저닝해야 합니다. 한 가용 영역의 장애 발생 시, 본래 복구 시간 목표가 추가 서버를 Terraform을 통해 프로비저닝하는 데 필요합니다. 이를 회피하는 한 가지 방법은 추가 용량 한 영역분을 가지고 있는 과도하게 프로비저닝하는 것입니다.
- Patroni Main(
n2-highmem-128
6.5k/month): 추가 노드 3개로 월 20k 추가 - Patroni CI(
n2-highmem-96
5k/month): 추가 노드 3개로 월 15k 추가 - HAProxy(
t2d-standard-8
285/month): 추가 노드 20개로 월 5k 추가 - 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에 계획된 작업이 있습니다.