Disaster Recovery (DR) 설계는 고가용성 아키텍처의 핵심이며, TA 역량 평가와 실전 클라우드/온프레미스 인프라 설계에서 반드시 등장하는 고급 주제입니다.
아래에 DR 개요, 유형별 비교, 설계 기준, 문제, 암기카드/인덱스 요약까지 직무역량 평가/블로그 오픈북용으로 정리해드리겠습니다.
🛡️ Disaster Recovery (DR) 설계
장애·재해 상황에서 서비스 연속성 보장을 위한 설계 전략
✅ 1. DR 설계 목적 및 개요
| 목적 | 장애/재해 상황에서도 업무 연속성(Business Continuity) 확보 |
| 대상 | 자연재해, 인프라 장애, 데이터 유실, 랜섬웨어, 네트워크 단절 |
| 핵심 지표 | RTO (Recovery Time Objective) RPO (Recovery Point Objective) |
📌 용어 요약
- RTO: 장애 발생 → 서비스 복구까지 걸리는 시간
- RPO: 복구 시점 기준으로 허용 가능한 데이터 손실량
🧱 2. DR 유형별 설계 전략
| Cold Site | 예비 센터만 구축, 서비스/데이터는 없음 | 수일 | 낮음 | 장비만 구축 |
| Warm Site | 일부 시스템/데이터 미리 배치 | 수 시간 | 중간 | 백업+일부 미운영 |
| Hot Site | 모든 시스템/데이터 상시 운영 | 수 분 | 높음 | 실시간 복제 |
| Active-Passive | 주 → 예비 노드 전환 | 중 | 중간 | RDS Multi-AZ |
| Active-Active | 다수 리전/센터 동시에 운영 | 낮음 | 매우 높음 | GSLB, Aurora Global |
🏗️ 3. DR 설계 아키텍처 비교
🔹 Cold Site 구성도
🔹 Active-Passive 구성
🔹 Active-Active 구성
🔐 4. 실무 설계 요소 (클라우드/온프레미스 공통)
| 데이터 복제 | 실시간 복제(Sync), 비동기 복제(Async) |
| DNS 이중화 | Route53, GSLB, Geo DNS |
| 네트워크 구성 | 전용선, VPN, VNet Peering, Transit Gateway |
| 스토리지 | Blob, Object, NFS 등의 Cross-Region Replication |
| 데이터 무결성 | 복제 오류 감지 및 검증 |
| Failover 자동화 | DB, LB, App 수준 전환 자동화 (ex. Route53 Failover Policy) |
☁️ 5. 클라우드별 DR 지원 예시
| AWS | Route53 GSLB, S3 CRR, Aurora Global, CloudEndure |
| Azure | Azure Site Recovery, GRS(GRS+RA), Azure Front Door |
| GCP | Cloud DNS, GCS Multi-Region, Spanner Global |
🎓 6. 직무역량 평가 예시 문제
문제 1 [중]
다음 중 Cold Site DR 구성의 특징으로 적절한 것은?
A. 서비스가 실시간으로 두 위치에서 실행된다
B. 재해 발생 시 수분 이내 자동 전환된다
C. 예비 센터에 장비만 배치되고 서비스는 중단 상태이다
D. 실시간 동기 복제를 통해 항상 최신 데이터가 유지된다
정답: C
해설: Cold Site는 가장 저비용 DR 구성으로, 미리 시스템을 구동하지 않음
문제 2 [상]
Active-Active DR 구성의 주요 리스크로 적절한 것은?
A. 데이터 복구 시간이 길다
B. 예비 사이트가 장애 시 사용할 수 없다
C. DNS 장애에 대응하지 못한다
D. 실시간 동기화 중 충돌로 인한 데이터 불일치 가능성
정답: D
해설: Active-Active 구성은 동시 쓰기나 네트워크 분리 시 동기화 충돌 발생 가능
문제 3 [상]
RTO = 1시간, RPO = 0분 기준의 DR 설계로 가장 적합한 것은?
A. Cold Site
B. Warm Site
C. Active-Passive with async replication
D. Active-Active with sync replication
정답: D
해설: 0분 데이터 손실을 허용하지 않기 때문에 Sync 복제가 필수
🧠 암기카드 요약
| RTO | 복구 시간 목표 (예: 5분, 1시간) |
| RPO | 복구 시점 목표 (데이터 손실 허용 범위) |
| Cold Site | 장비만 존재, 복구 시간 오래 걸림 |
| Warm Site | 일부 시스템 사전 배치, 복구 시간 중간 |
| Hot Site | 상시 운영, 빠른 전환 |
| Active-Passive | 1차 운영, 2차 대기 (Failover 발생 시 전환) |
| Active-Active | 양쪽 운영, GSLB 기반 트래픽 분산 |
| GSLB | 지리적 DNS 분산, 리전 단위 장애 회피 |
| CloudEndure | AWS 실시간 DR SaaS 도구 |
📁 블로그 오픈북용 키워드 인덱스
- Disaster Recovery 설계 유형
- RTO RPO 정의
- Cold Site Warm Site Hot Site
- Active-Active DR 구성
- Active-Passive DR 설계
- DR 자동화 전환
- 클라우드 DR 서비스 비교
- Route53 Failover / GSLB
- DR 테스트 절차
- DR 설계 시 고려할 질문
🛡️ DR 설계 시나리오 기반 실전문제 (20문항)
✅ NO.01 [중]
당신의 조직은 AWS 환경에서 2개 리전(A, B)을 운영 중이며, RTO 1시간, RPO 15분이 요구된다. 가장 적절한 DR 구성 방식은?
A. Cold Site
B. Warm Site
C. Active-Passive with Async Replication
D. Active-Active
정답: C
해설: Warm은 느리고, Active-Active는 비용이 크며 Sync는 불필요. Async Passive가 요구 조건 충족.
✅ NO.02 [상]
Active-Active DR 구성을 사용하는 글로벌 서비스에서 리전 간 네트워크 분리(Network Partition)가 발생했다. 이때 가장 우려되는 것은?
A. 데이터 복제 속도 저하
B. 인스턴스 간 부하 불균형
C. 데이터 일관성 충돌
D. 트래픽 증가로 인한 비용 상승
정답: C
해설: Active-Active는 양쪽에서 쓰기 가능하여 동시 쓰기 시 일관성 문제 발생 위험.
✅ NO.03 [중]
Azure 환경에서 Geo-Redundant Storage(GRS)는 어떤 DR 구성에 해당하는가?
A. Cold Site
B. Active-Passive
C. Active-Active
D. Warm Site
정답: B
해설: GRS는 주 리전에서만 사용하고 백업용으로 비동기 복제됨.
✅ NO.04 [하]
Cold Site 구성의 특징으로 가장 적절한 것은?
A. 모든 시스템과 데이터가 실시간으로 동기화되어 있다
B. DR 센터에 인프라만 준비되어 있고 운영은 하지 않는다
C. 장애 발생 시 즉시 자동으로 전환된다
D. 가장 높은 비용이 발생한다
정답: B
✅ NO.05 [상]
주 리전 장애 시 자동으로 리전 간 전환되도록 하기 위해 가장 먼저 고려해야 할 서비스는?
A. 고정 IP 구성
B. Auto Scaling 그룹
C. GSLB 또는 DNS Failover
D. VPC 피어링
정답: C
✅ NO.06 [중]
DR 설계 시 RTO가 짧아야 하는 경우에 적절한 구성은?
A. 매일 백업 후 외부 저장소 이동
B. Cold Site
C. Active-Passive with Sync Replication
D. 수동 DB 복원
정답: C
✅ NO.07 [하]
RPO 0분이 요구되는 서비스에서 반드시 적용해야 하는 복제 방식은?
A. Async
B. Snapshot
C. Tape Backup
D. Sync
정답: D
✅ NO.08 [상]
Kubernetes 클러스터를 멀티 리전 DR 환경으로 구성할 때 가장 중요한 요소는?
A. 동일 CIDR 설정
B. Node 라벨링
C. 클러스터 간 DNS 라우팅 및 상태 모니터링
D. Helm Chart 통일
정답: C
✅ NO.09 [중]
Warm Site의 단점으로 가장 적절한 것은?
A. 운영 비용이 매우 높다
B. 복구 시간이 며칠 걸린다
C. 데이터 일관성 유지가 어렵다
D. 일부 시스템만 구동되므로 전체 성능 테스트가 어렵다
정답: D
✅ NO.10 [중]
다음 중 DR 테스트의 주요 목적이 아닌 것은?
A. 시스템의 가용성을 검증
B. 데이터 일관성 유지 확인
C. 실제 장애 발생 빈도를 예측
D. 복구 절차의 유효성 검증
정답: C
✅ NO.11 [하]
RTO가 24시간, RPO가 12시간인 서비스에 적절한 DR 방식은?
A. 실시간 복제 + Active-Active
B. Cold Site + Tape Backup
C. GSLB 기반 Active-Passive
D. RDS Multi-AZ 구성
정답: B
✅ NO.12 [상]
DR 전환 중 데이터 손실 없이 상태를 유지하기 위한 전략으로 적절하지 않은 것은?
A. 실시간 데이터 복제
B. Sync 복제
C. LAG 기반 전환 지연
D. 재해 발생 후 Tape 복구
정답: D
✅ NO.13 [중]
AWS CloudEndure의 특징으로 적절한 것은?
A. 수동 백업 시스템
B. 인프라 비용이 가장 적게 든다
C. 온프레미스 → 클라우드 실시간 복제 지원
D. GSLB 기능 제공
정답: C
✅ NO.14 [상]
Active-Passive 구성에서 장애 전환이 실패할 가능성이 가장 큰 요소는?
A. Passive 사이트에서 서비스가 이미 동작 중임
B. 네트워크 성능 저하
C. DNS 전환 실패 또는 TTL 지연
D. DB Write Conflict
정답: C
✅ NO.15 [중]
RDS Multi-AZ 구성의 DR 특성으로 적절하지 않은 것은?
A. 자동 장애 전환
B. 동일 리전 내에서만 구성 가능
C. 수동 백업 복구 방식
D. 데이터 손실 없는 복제
정답: C
✅ NO.16 [하]
DR 설계의 주요 목표가 아닌 것은?
A. 서비스 무중단 운영
B. 장애 발생 시 복구 시간 최소화
C. 백업 데이터 압축률 향상
D. 데이터 손실 최소화
정답: C
✅ NO.17 [중]
멀티 리전 DR에서 트래픽 분산을 위해 가장 일반적으로 사용하는 방법은?
A. VPN 라우팅
B. SSH 포트 포워딩
C. 글로벌 DNS(GSLB) 라우팅
D. LB IP 수동 등록
정답: C
✅ NO.18 [중]
DR 테스트 주기가 길어지면 발생할 수 있는 리스크는?
A. 스토리지 비용 증가
B. 전환 속도 향상
C. 복구 스크립트 오류 및 절차 누락
D. RTO 감소
정답: C
✅ NO.19 [상]
Kubernetes에서 멀티 클러스터 기반 DR을 구성할 때 반드시 고려해야 할 요소는?
A. Ingress Controller는 클러스터당 하나만 둔다
B. etcd는 외부 백업이 불필요하다
C. 클러스터 간 인증 통합, 동일 네임스페이스 구조
D. 모두 동일한 kube-proxy 설정 사용
정답: C
✅ NO.20 [중]
DR 설계 시 데이터 무결성을 검증하는 가장 좋은 방법은?
A. 백업 압축 로그 확인
B. 장애 후 운영자 보고
C. 정기적 검증을 위한 체크섬 비교 자동화
D. 백업 용량 증가 모니터링
정답: C
🧠 활용 팁
- 이 문제들은 모두 RTO/RPO 요구사항 기반 시나리오 판단 능력, DR 구성 비교, 클라우드 서비스 활용도, 장애 전환 절차 설계력을 평가합니다.
- 실제 시험 대비 시에는 “요구조건 → 복구 방식 도출 → 위험 요소 식별” 흐름으로 사고하는 것이 핵심입니다.
'서버 시스템 > 서버 아키텍처' 카테고리의 다른 글
| 멀티 존(Multi-Zone) / 멀티 리전(Multi-Region) 고가용성 설계 (0) | 2025.09.02 |
|---|---|
| Kubernetes 기반 서버 인프라 구성 (0) | 2025.09.02 |
| MSA(Microservice Architecture)의 Inner/Outer Architecture 구조 (0) | 2025.09.02 |
| 서버 아키텍처 기본 개념 #2 (0) | 2025.09.01 |