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

재해 복구

이 문서는 작업 중인 것으로, 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 값은 목표값이지만, regional bucket replication의 제한 사항과 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 (Self-Managed용 패키지 배포) 0 0

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

지역 복구에는 멀티리전 버킷에 저장된 백업을 사용하여 GitLab.com을 완전히 재구축해야 합니다. 복구는 아직 최종적으로 확인되지 않았으므로 지역 실패에 대한 RTO가 얼마나 걸릴지 알지 못합니다. FY25의 대상 RTO는 지역 장애에서 48시간 이내에 복구하는 절차를 갖추는 것입니다.

멀티리전 버킷을 듀얼리전 버킷보다 선택하는 고려 사항은 다음과 같습니다:

  • 우리는 단일 지역에서 운영하므로 멀티리전 리포지터리는 재해 복구를 위해만 사용됩니다.
  • Google은 재해 복구를 위해 듀얼리전을 권장하지만, 듀얼리전은 디스크 스냅숏을 위한 사용 가능한 저장 유형이 아닙니다.
  • 멀티리전 버킷의 대역폭 제한을 완화하기 위해 Gitaly VM 인프라를 여러 프로젝트에 걸쳐 분산시킵니다.

지역 및 존 복구에 대한 제안

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

  2. 우리는 프론트엔드 트래픽을 처리하는 Kubernetes 클러스터에서 최대 복제본을 설정하여 하류 의존성을 포화시키지 않도록 합니다. 존 장애의 경우, 최대 복제본을 증가시키기 위해 클러스터 재구성이 필요합니다. ↩

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