| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
Cells 1.0 재해 복구
사용된 용어
- Primary Cell: 현재의 GitLab.com 배포인 GitLab.com SaaS입니다. 이 아키텍처에서 클러스터 전역 서비스로 작동하는 특수 목적의 Cell입니다.
- Secondary Cells: Primary Cell에 연결되어 클러스터 전역의 고유성을 보장하는 Cell입니다.
- Global Service: 전역적인 고유성을 유지하고, 클러스터 전체에서 데이터베이스 시퀀스를 관리하며, 어떤 리소스가 어느 Cell에 속하는지를 분류하는 서비스입니다.
- Routing Service: Global Service에 의존하는 라우팅 규칙을 다른 Cell로 관리하는 서비스입니다.
- RTO: [복구 시간 목표]
- RPO: [복구 지점 목표]
- WAL: Write-ahead logging
목표
Cells 1.0은 여러 Secondary Cell이 Primary Cell과 독립적으로 작동할 수 있는 Cellular의 첫 번째 반복입니다. 그러나 독립적으로 작동할 수 있지만 이 아키텍처에서는 Global Service와 Routing Service에 의존성이 있습니다. 재해 복구를 위해 Cells 1.0에서는 Global Service가 여전히 Primary Cell에 의존성을 가질 수 있습니다. [^cells-1.0] Cells 1.0의 목표는 GitLab Dedicated의 현재 재해 복구 전략인 Geo를 사용하는 것입니다. Cells 1.0 이후에는 백업 데이터를 복원하기 위해 Next Gen Scalable Backup and Restore를 활용할 것입니다.
이 문서는 보조 Cell 복구 전략을 정의하는 데에만 중점을 두고 있습니다. Global Service, Routing Service, Primary Cell 또는 다른 외부 서비스의 복구는 다루지 않습니다.
Cells의 재해 복구는 cells가 다른 도구로 공급되기 때문에 기존의 복구 과정에서 갈라지는 점이 있습니다. 예를 들어:
- Cell을 복구하기 위해 다른 프로세스, runbook 및 도구가 필요합니다.
- Primary Cell 및 다른 Cell의 RPO/RTO가 서로 다릅니다.
이로 인해 Primary Cell 및 Secondary Cell의 RPO/RTO에 대한 서로 다른 목표가 있습니다.
- GitLab.com 재해 복구 도면에서 확인된 Zonal Outages에 대한 RTO 및 RPO FY24 목표를 충족 또는 초과합니다.
- Primary Cell에 대한 FY25 계획을 고려하여 지역 복구 및 대체 지역 선택을 수행합니다.
- Cells에 대한 Dedicated의 동일한 DR 절차를 활용합니다.
RTO/RPO 목표
Zonal Outages:
| RTO | RPO | |
|---|---|---|
| Primary Cell (current) | 2 시간 | 1 시간 |
| Primary Cell (FY25 목표) | <1 분 | <1 분 |
| Cells 1.0 (Primary Cell 제외) | 알 수 없음 | 알 수 없음 |
Regional Outages:
| RTO | RPO | |
|---|---|---|
| Primary Cell (current) | 96 시간 | 2 시간 |
| Primary Cell (FY25 목표) | 48 시간 | <1 분 1 |
| Cells 1.0 (Primary Cell 제외) | 알 수 없음 | 알 수 없음 |
재해 복구 개요
Zonal recovery는 단일 가용 영역에 한정된 재해, 장애 또는 삭제를 의미합니다. 장애는 전체 영역 또는 영역의 일부 인프라를 영향을 줄 수 있습니다. Regional recovery는 전체 지역에 한정된 재해, 장애 또는 삭제를 의미합니다. 장애는 전체 지역 또는 영향을 받는 인프라의 일부를 영향을 줄 수 있습니다.
| 서비스 | 지역 재해 복구 | 예상 RTO | 예상 RPO |
|---|---|---|---|
| GitLab Rails | Cell에서 실행 중인 모든 서비스는 영역을 가로지르는 중복이 있습니다. 이 서비스에는 저장된 데이터가 없습니다. | <=1 분 | 적용되지 않음 |
| Gitaly Cluster | Gitaly Cluster는 단일 SPOF(단일 장애 지점) 노드로 구성되어 있으며 Cells 1.0에서 여전히 그대로 유지됩니다. 영역 장애의 경우에는 백업에서 복원이 필요합니다. | <=30 분 | WAL을 복원하기 전 스냅샷의 재설정을 위해 최대 1시간 2 |
| Redis Cluster | Redis는 여러 가용 영역에 배포되어 있으며, 단일 영역에서의 서비스 중단으로부터 자동으로 복원할 수 있습니다. | <=1 분 | <=1 분 |
| PostgreSQL Cluster | PostgreSQL 클러스터는 여러 가용 영역에 배포되어 있으며, 단일 영역에서의 서비스 중단으로부터 자동으로 복원할 수 있습니다. 장애 조치(Failover)시 일부 데이터 손실이 발생할 수 있습니다. | <=1 분 | <=1 분 |
| 서비스 | 지역 재해 복구 | 예상 RTO | 예상 RPO |
|---|---|---|---|
| GitLab Rails | Cell에서 실행 중인 모든 서비스는 지역적이며, 지역적 장애의 경우에는 재구축이 필요합니다. 이 서비스에는 저장된 데이터가 없습니다. | <=12 시간 | 적용되지 않음 |
| Gitaly Cluster | 초기에 Gitaly Cluster는 단일 SPOF 노드로 구성되어 있으며, Cells 1.0에서 여전히 그대로 유지됩니다. 지역적 장애의 경우에는 재구축이 필요합니다. | 알 수 없음 | WAL을 복원하기 전 스냅샷의 재설정을 위해 최대 1시간 2 |
| Redis Cluster | Redis는 단일 지역에 배포되어 있으며, 지역적 장애의 경우에는 재구축이 필요합니다. 즉시 진행 중인 작업, 세션 데이터 및 캐시를 복구할 수 없습니다. | 알 수 없음 | 적용되지 않음 |
| PostgreSQL Cluster | PostgreSQL 클러스터는 단일 지역에 배포되어 있으며, 지역적 장애의 경우에는 재구축이 필요합니다. 백업 및 WAL 파일에서 복원합니다. 장애 조치(Failover)시 일부 데이터 손실이 발생할 수 있습니다. | 알 수 없음 | <=5 분 |
재해 복구 검증
Cells의 재해 복구는 주기적으로 복원 테스트를 통해 검증되어야 합니다. 이 복구는 프로덕션 환경에서 Cell에서 수행되어야 합니다. 이러한 테스트는 1분기에 한 번 실행되며, 재해 복구 runbook을 사용하여 완료됩니다.
리스크
- Primary Cell은 Dedicated를 사용하지 않으며 Secondary Cells는 사용합니다. 이것은 우리의 프로세스 및 runbook을 분리할 수 있으며 RTO에 영향을 줄 수 있습니다.
- 현재 계획은 Secondary Cells를 Dedicated를 사용하여 실행하는 것입니다. Dedicated의 재해 복구 프로세스는 많은 매뉴얼 단계가 필요하며 아직 자동화되지 않았습니다.3
- Dedicated DR runbook에는 안내가 포함되어 있지만, 재해 발생 시 SRE가 따라갈 수 있는 구조로 되어 있지 않습니다. 4