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

재해 복구

이 문서는 작업 중이며 GitLab.com SaaS의 아키텍처 변경을 제안합니다. 이러한 변경의 목표는 리전 또는 존 장애가 발생한 경우 GitLab.com 서비스 연속성을 유지하는 것입니다.

  • us-east1 또는 us-central1의 세 가용성 영역 중 하나에서 모든 리소스를 사용할 수 없을 때 존 복구가 필요합니다.
  • GitLab.com 운영에 필수적인 지역 중 하나인 us-east1 또는 us-central1에서 모든 리소스가 사용할 수 없게 되면 리전 복구가 필요합니다.

FY24 및 FY25의 현재 DR 전략에 포함되지 않는 서비스

우리는 DR의 범위를 주요 서비스(Web, API, Git, Pages, Sidekiq, CI 및 Registry)를 지원하는 서비스로 제한했습니다. 이러한 서비스는 GitLab.com의 전체적인 가용성 점수 (내부 링크)에 직접적으로 연결됩니다.

예를 들어, DR에는 다음이 포함되지 않습니다:

  • 코드 제안을 포함한 AI 서비스
  • 추적과 같은 오류 추적 및 기타 관측 서비스
  • 청구 및 새 구독을 책임지는 CustomersDot
  • 고급 검색

DR 구현 대상

FY24의 목표는 다음과 같았습니다:

  RTO(복구 시간 목표) RPO(복구 지점 목표)
존 복구 2시간 1시간
리전 복구 96시간 2시간

씨엔독 아키텍처 전에 FY25 목표는 다음과 같았습니다:

  RTO(복구 시간 목표) RPO(복구 지점 목표)
존 복구 0분 0분
리전 복구 48시간 0분

참고: RPO 값은 목표이지만, 리전 버킷 복제의 제한과 Gitaly와 PostgreSQL의 복제 지연으로 정확히 충족될 수 없습니다.

현재 존 복구의 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)

아직 GitLab.com에서 전체 존 장애를 시뮬레이션하지는 않았습니다. 다음은 우리가 재해 복구런북을 사용하여 테스트한 내용을 기반으로한 RTO/RPO 추정값입니다. 각 서비스가 병렬로 복원될 수 있다고 가정합니다. 병렬 복원은 존 복구의 FY24 RTO 목표인 2시간을 충족시킬 수 있는 유일한 방법입니다.

서비스 RTO RPO
PostgreSQL 1.5시간 <=5분
Redis 1 0 0
Gitaly 30분 <=1시간
CI 30분 해당 사항 없음
로드 밸런싱 (HAProxy) 30분 해당 사항 없음
프런트엔드 서비스 (Web, API, Git, Pages, Registry) 2 15분 0
모니터링 (Prometheus, Thanos, Grafana, 경보) 0 해당 사항 없음
운영 (배포, 런북, 운영 도구, Chef) 3 30분 4시간
PackageCloud (셀프매니지드용 패키지 배포) 0 0

현재 리전 복구의 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)

리전 복구에는 다중 리전 버킷에 저장된 백업을 사용하여 GitLab.com을 완전히 재구축해야 합니다. 복구는 아직 최종적으로 검증되지 않았으므로 리전 장애에 대한 RTO가 얼마나 길지 알 수 없습니다. 우리는 FY25의 목표 RTO로 리전 장애로부터 48시간 이내에 복구하는 절차를 갖추기를 희망합니다.

다음은 이중 리전 버킷 대신 다중 리전 버킷을 선택하는 고려 사항입니다:

  • 우리는 단일 리전에서 운영되므로 다중 리전 저장소는 재해 복구를 위해만 사용됩니다.
  • Google은 재해 복구를 위해 이중 리전을 권장하지만, 이중 리전은 디스크 스냅샷에 사용할 수 없는 저장소 유형입니다.
  • 다중 리전 버킷의 대역폭 제한을 완화하기 위해 Gitaly VM 인프라를 여러 프로젝트에 걸쳐 분산시킵니다.

리전 및 존 복구에 대한 제안


  1. 대부분의 Redis 부하는 주 노드에 있으므로 복제본을 잃어도 서비스 중단이 발생하지 않아야 합니다. 

  2. 우리는 프런트엔드 트래픽을 서비스하는 Kubernetes 클러스터에서 최대 복제본을 설정했습니다. 이는 존 장애의 경우 이러한 최대값을 늘리기 위해 클러스터 구성 변경이 필요합니다. 

  3. 단일 가용성 영역 내에서 Chef는 단일 장애 지점이며 복원 방법으로 디스크 스냅샷을 사용하기 때문에 운영에 대한 RPO는 4시간입니다. 우리의 대부분의 Chef 구성은 Git에도 저장되지만 노드 등록과 같은 일부 데이터는 서버에만 저장됩니다.