DR 이용자 가이드
자연 재해나 대형 장애 등 물리적으로 복구 불가능한 상황에 대비하기 위해 작성된 가이드입니다.
재해 복구 전략
다중 가용 영역 및 다중 리전(Multi-AZ & Multi-Region) 환경
카카오클라우드는 독립적인 서비스 환경 단위인 리전(Region)과, 리전 내에서 지리적으로 분산된 데이터 센터 단위인 가용 영역(AZ, Availability Zone)으로 이루어져 있습니다.
각 AZ는 리전 내에서 물리적으로 서로 다른 위치에 구성되어 있으며, 카카오클라우드는 다중 가용 영역(Multi-AZ)을 제공합니다. 화재·정전·지진 등 특정 AZ에서 물리적 복구가 불가능한 전면 장애가 발생하더라도 동일 리전 내 다른 AZ에서 애플리케이션과 서비스가 중단 없이 운영될 수 있도록 고가용성과 내결함성을 보장합니다. 멀티 리전(Multi-Region) 환경에서는 복수의 리전에 서비스를 분산 운영함으로써, 특정 리전 전체에 장애가 발생하는 상황에서도 다른 리전을 통해 서비스를 지속적으로 제공할 수 있습니다.
이처럼 다중 가용 영역과 멀티 리전 구성을 통해, 장애 범위와 규모에 관계없이 물리적으로 격리된 공간에서 서비스 연속성을 확보할 수 있습니다.
| 리전 | 위치 | 가용 영역 |
|---|---|---|
| kr-central-2 | 대한민국 수도권 | kr-central-2-a |
| kr-central-2-b | ||
| kr-central-2-c | ||
| kr-central-2-d (예정) | ||
| kr-gov-central-1 | 대한민국 수도권 | kr-gov-central-1-a |
| kr-gov-central-2 | 대한민국 수도권 | kr-gov-central-2-a |
- 정보/공공기관용 계정은
kr-gov-central-1과kr-gov-central-2리전에만 액세스할 수 있습니다.
재해 복구 목표
카카오클라우드의 DR 이용자 가이드를 참고하여 재해 복구 전략을 수립할 경우, RTO와 RPO를 최소한으로 줄일 수 있습니다. (향후 GSLB 서비스 제공 시, Active-Active 환경으로 구성하여 RTO, RPO를 0에 가깝게 구성할 수 있음)
- 복구 시간 목표(RTO): 장애나 중단이 발생한 후 시스템이나 서비스를 복구하는 데 걸리는 최대 허용 시간을 의미하며 비즈니스에 중요한 애플리케이션이나 데이터가 얼마나 빨리 복구되어야 하는지 결정합니다.
- 복구 시점 목표(RPO): 장애나 중단이 발생하기 전으로 데이터를 복구할 수 있는 시점의 최대 허용 기간을 의미합니다. 허용 가능한 데이터 손실의 양을 나타내며, 데이터가 어느 시점까지 복구되어야 하는지를 정의합니다.
다중 리전(Multi-Region) 환경에서의 재해 복구 전략
카카오클라우드 서비스 이용 중 재해 상황을 대비한 복구 전략 3가지를 소개합니다.
1. Backup-Restore 구성
Backup-Restore 구성은 서비스 중인 특정 리전에 재해 상황 발생 시, 미리 스케줄링된 백업을 이용하여 데이터를 효과적으로 복원할 수 있습니다.
Backup-Restore Architecture
Backup-Restore 특징
- RPO(데이터 손실): Active-Standby 구성에 비해 RPO(데이터 손실)가 길어 데이터 손실 가능성이 크지만, 재해가 발생한 리전의 데이터가 스케줄링된 볼륨 백업을 통해 복원되므로 효과적인 데이터 복원이 가능합니다.
- RTO(복구 시간): 재해 발생 시 복구 리전에 전체 인프라를 새로 프로비저닝해야 하므로, Active-Standby 구성에 비해 RTO(복구 시간)가 깁니다.
- 평상시에는 DR 리전의 리소스를 운영하지 않다가 재해 발생 시에만 생성하므로, Active-Standby 구성 대비 비용이 절감됩니다.
재해 상황 발생 시, 복구 과정
Backup-Restore 구성 중 재해 상황 발생 시, 아래의 과정으로 복구를 진행할 수 있습니다.
- DR 리전에서 관리형 데이터베이스(MySQL) 서비스를 통해 백업 데이터로 인스턴스 복원
- 백업된 이미지 또는 배포 구성을 통해 DR 리전에 Application 재배포
- DR 리전의 LB 엔드포인트로 DNS 레코드를 업데이트하여 서비스 트래픽 전환 및 복구 완료
2. Active-Standby 구성
Active-Standby 구성은 Backup-Restore 구성과 유사하지만, DR 리전에 DR 검증이 가능한 최소한의 인프라가 사전에 프로비저닝되어 있습니다.
Main 리전에 재해 상황이 발생할 경우, DR 리전의 인프라를 Full Scale로 확장하여 신속하게 서비스를 복구할 수 있습니다. 이로 인해 Backup-Restore 구성 대비 RTO가 짧으나, 최소 인프라의 상시 운영에 따른 비용이 발생합니다.
Active-Standby Architecture
Active-Standby 특징
- RPO(데이터 손실): 데이터 동기화 프로그램(마켓플레이스 또는 오픈소스 솔루션)을 활용하여 DR 리전으로 실시간 데이터 동기화가 가능하므로, RPO를 0에 가깝게 구성할 수 있습니다.
- RTO(복구 시간): DR 리전에 Main 리전과 동기화된 최소한의 인프라가 사전 구성되어 있어, 추가 인프라 확장 소요 시간에 따라 달라질 수 있으나 Backup-Restore 대비 빠른 복구가 가능합니다.
- Backup-Restore 구성에 비해 RTO와 RPO를 더 짧게 구성할 수 있으나, 최소 인프라의 상시 운영으로 인해 추가 비용이 발생합니다.
재해 상황 발생 시, 복구 과정
Active-Standby 구성 중 재해 상황 발생 시, 아래의 과정으로 복구를 진행할 수 있습니다.
- DR 리전에 Replica 구성된 데이터베이스를 Primary로 승격(Promote)하여 서비스 전환
- Standby 리전의 인프라로 요청이 전달될 수 있도록 Standby 리전의 LB 엔드포인트로 DNS 레코드를 업데이트 (단, TTL을 낮게 설정해 두어야 전환 속도가 빠르며, 글로벌 DNS 전파 시간 고려 필요)
- Standby 리전에 사전 복제해 둔 스냅샷 또는 백업 이미지를 통해 나머지 인프라(VM 또는 K8s Pod)를 Full Scale로 확장하여 서비스 복구
3. Active-Active 구성
Active-Active 구성은 각 리전에 동일한 인프라가 구성되어 동시에 서비스가 되는 구조입니다. 따라서 특정 리전에 재해 상황 발생 시에도 정상 리전에서 서비스를 지속적으로 운영할 수 있습니다.
Active-Active 특징
- GSLB를 사용하여 각 리전(kr-gov-central-1, kr-gov-central-2)에 동시에 서비스 가능
- 특정 리전에 재해 상황 발생 시에도 정상 리전에서 서비스를 지속적으로 운영이 가능하여 RTO와 RPO는 0으로 수렴
GSLB 서비스는 현재 개발 중으로, Active-Active 구성은 GSLB 릴리즈 후 적용할 수 있습니다.