고가용성(HA)은 서비스가 '거의 항상' 켜져 있도록 설계하는 것이고, 재해 복구(DR)는 만에 하나 서비스가 중단되더라도 '빠르게 되살리는' 것입니다. AZ-305 시험에서는 이 두 가지를 어느 계층에서, 어떤 서비스로 달성할지 묻는 문제가 자주 등장합니다. 이 글에서는 핵심 서비스를 하나씩 짚어보고 시험에서 자주 헷갈리는 선택 기준까지 정리해 드리겠습니다.
---
RTO와 RPO 그리고 비즈니스 연속성 설계
재해 복구 설계의 출발점은 두 개의 숫자입니다. 바로 RTO와 RPO입니다.
RTO(Recovery Time Objective, 복구 목표 시간)는 장애 발생 후 서비스가 다시 정상 운영될 때까지 허용되는 최대 시간입니다. 예를 들어 RTO가 4시간이라면, 장애 발생 4시간 안에 서비스를 재개해야 합니다. RTO가 짧을수록 더 빠른 전환 인프라가 필요하고, 비용도 올라갑니다.
RPO(Recovery Point Objective, 복구 목표 시점)는 장애 발생 시 허용 가능한 최대 데이터 손실 범위입니다. RPO가 24시간이라면 최근 24시간 이내의 데이터가 손실될 수 있음을 의미합니다. 이 값은 백업 또는 복제의 빈도를 결정합니다. 일별 1회 백업 체계에서는 RPO가 최대 24시간이 됩니다. 만약 시간당 백업으로 바꾸면 RPO는 최대 1시간으로 단축됩니다.
중요한 것은 보존 기간과 RPO를 혼동하지 않는 것입니다. 보존 기간은 '얼마나 오래된 시점으로 복구할 수 있는가'를 결정하고, RPO는 '마지막 백업 이후 최대 몇 시간치 데이터를 잃을 수 있는가'를 결정합니다. 월별 백업 보존 기간이 12개월이면 10개월 전 복구가 가능하지만, 이 정책의 RPO는 보존 기간이 아니라 일별 백업 주기(최대 24시간)로 결정됩니다.
비즈니스 연속성 설계의 핵심은 RTO와 RPO 목표에 맞는 수단을 선택하는 것입니다. 목표가 느슨할수록(예: RTO 12시간, RPO 24시간) 백업 기반 솔루션으로 충분하고, 목표가 엄격할수록(예: RTO 수 분, RPO 수 초) 상시 복제와 자동 장애 조치가 필요합니다.
---
가용성 영역과 가용성 집합
Azure에서 단일 데이터센터 장애를 피하는 가장 기본적인 방법은 두 가지입니다.
가용성 집합(Availability Set)은 같은 데이터센터 내에서 VM을 서로 다른 물리적 랙에 배치합니다. 장애 도메인과 업데이트 도메인으로 VM을 분산하여 동일 물리 하드웨어 장애나 계획된 유지보수가 모든 VM에 동시에 영향을 주지 않도록 합니다. SLA는 99.95%입니다.
가용성 영역(Availability Zone)은 한 단계 더 나아갑니다. 동일 Azure 리전 내에서 서로 독립적인 전원·냉각·네트워크를 갖춘 물리적으로 분리된 데이터센터(영역)에 VM을 분산 배치합니다. 한 영역 전체가 정전되더라도 다른 영역의 VM은 정상 작동합니다. SLA는 99.99%입니다.
가용성 영역은 리전 내 장애를 대응하는 기술입니다. 리전 전체가 서비스 불가 상태가 되면 가용성 영역으로는 대응이 불가능하며, 다중 리전 아키텍처가 필요합니다.
시험 구분 기준: 단일 데이터센터 랙 장애 → 가용성 집합, 동일 리전 내 영역 장애 → 가용성 영역, 리전 전체 장애 → 다중 리전 설계입니다.
!Availability Zone vs Availability Set
지역 쌍과 다중 리전 아키텍처
Azure는 특정 리전들을 지리적으로 가까운 쌍으로 묶어 관리합니다. 이것이 지역 쌍(Region Pair)입니다. 예를 들어 한국 중부(Korea Central)와 한국 남부(Korea South)는 쌍을 이룹니다.
지역 쌍의 주요 특징은 다음과 같습니다.
Azure 플랫폼 업데이트 시 쌍 리전에 동시에 배포하지 않아 업데이트 중단 위험을 분산합니다. GRS(지역 중복 스토리지)나 크로스 리전 복원(CRR)을 구성하면 데이터가 자동으로 쌍 리전에 복제됩니다. Azure Key Vault는 리전 장애 시 쌍 리전으로 자동 failover되며, 이 상태에서는 읽기 전용 모드로 동작합니다. 기존 키 조회·암호화·복호화는 가능하지만 새 키 생성이나 수정은 불가능합니다.
리전 장애에 대응하는 다중 리전 아키텍처는 크게 두 가지 패턴입니다.
첫째, 보조 리전에 동일 인프라를 상시 운영하는 Active-Active 또는 Warm Standby 패턴입니다. RTO와 RPO를 매우 짧게 유지할 수 있지만, 보조 리전의 인프라 운영 비용이 추가됩니다.
둘째, 보조 리전에는 복제 데이터만 유지하고 장애 발생 시 인프라를 즉시 프로비저닝하는 Cold Standby 패턴입니다. 비용 효율적이지만 RTO가 다소 길어집니다. Azure Site Recovery를 활용한 VM DR이 이 패턴의 대표 사례입니다.
VMSS 기반 웹 백엔드라면 보조 리전에 동일한 VMSS를 배포하고 Azure Front Door로 글로벌 장애 조치를 구성하는 것이 권장 패턴입니다. Front Door는 30초 간격으로 백엔드 상태를 프로브하여 주 리전 장애 시 자동으로 보조 리전으로 트래픽을 전환합니다.
---
Azure Site Recovery와 Backup 전략
Azure Backup과 Azure Site Recovery는 이름이 비슷해 보이지만 목적이 다릅니다.
Azure Backup은 특정 시점의 데이터 스냅샷을 Recovery Services Vault에 저장하는 서비스입니다. 일별·주별·월별·연별 보존 계층을 구성하여 최대 99년까지 보존 가능합니다. 온프레미스 Windows Server 파일과 폴더를 Azure에 직접 백업하려면 MARS(Microsoft Azure Recovery Services) Agent를 설치합니다. MARS Agent는 별도 백업 서버 없이 파일·폴더·시스템 상태를 Recovery Services Vault로 전송하며, 기존 Windows Server Backup과 독립적으로 동시에 운영할 수 있습니다.
Azure Site Recovery(ASR)는 VM 디스크를 보조 리전으로 지속적으로 복제(RPO 수 분~15분 수준)하여 장애 발생 시 자동 장애 조치(Failover)를 실행하는 서비스입니다. 평상시에는 보조 리전에 VM이 실행되지 않고 복제 데이터만 유지되므로 비용이 최소화되며, 장애 시 자동으로 VM이 생성되어 RTO 1시간 이내 복구가 가능합니다. 온프레미스-to-온프레미스, 온프레미스-to-Azure, Azure-to-Azure 모두 지원하며, Recovery Plan으로 장애 조치 순서와 의존성을 자동 처리합니다. 프로덕션에 영향 없이 DR 계획을 검증하는 테스트 장애 조치(Test Failover) 기능도 제공합니다.
Recovery Services Vault는 Azure Backup과 Site Recovery 모두의 중앙 보관함입니다. 불변성 잠금(Immutability Lock)을 활성화하면 백업 데이터를 삭제·수정 불가 상태로 보호하여 랜섬웨어에 대응합니다. GRS(지역 중복 스토리지)와 크로스 리전 복원(CRR)으로 리전 장애 시에도 보조 리전에서 복원할 수 있습니다. Vault는 생성 리전에 귀속되므로 멀티리전 환경에서는 리전별로 별도 Vault를 생성해야 합니다. 여러 Vault를 한 화면에서 모니터링하려면 Backup Center를 추가 사용합니다.
수백 개 VM에 표준화된 백업 정책을 일괄 적용하려면 Azure Policy와 Recovery Services Vault 백업 정책을 연동하면 됩니다. 범위 내 신규 VM도 자동으로 정책에 포함되므로 규정 준수 상태가 지속 유지됩니다.
---
서비스 비교표
고가용성 및 재해 복구를 위한 주요 Azure 구성 요소를 범위·SLA·RTO/RPO 기준으로 비교합니다.
| 구성 요소 | 보호 범위 | SLA | RPO | RTO | 주요 특징 | |-----------|-----------|-----|-----|-----|-----------| | 가용성 집합 | 데이터센터 내 랙·호스트 | 99.95% | N/A | N/A | 장애 도메인 분산, 비용 없음 | | 가용성 영역 | 리전 내 독립 데이터센터 | 99.99% | N/A | N/A | 물리 전원·냉각 분리 | | 지역 쌍 + GRS | 리전 간 스토리지 복제 | 99.99%+ | 수 분~1시간 | 수 시간 | 스토리지 계층 지역 중복 | | Azure Backup | 데이터 시점 보존 | - | 수 시간~24시간 | 수 시간~12시간 | 장기 보존, PITR | | Azure Site Recovery | VM 수준 리전 간 복제 | - | 수 분~15분 | 1시간 이내 | 자동 장애 조치, 비용 효율 | | SQL Auto-Failover Group | Azure SQL DB 리전 간 | 99.99% | 5초 미만 | 1시간 이내 | 단일 엔드포인트, 자동 전환 | | Always On AG + ILB | VM 기반 SQL Server | 99.99%+ | 0초(동기) | 수 초 | IaaS 환경, WSFC 기반 |
---
시험에서 자주 헷갈리는 선택 기준
실제 시험에서 자주 등장하는 시나리오와 선택 기준을 정리합니다.
시나리오 1: RTO 12시간, RPO 24시간, 보조 인프라 상시 운영 불가, 비용 효율 우선 Azure Backup PITR을 선택합니다. 보조 리전에 상시 VM을 유지하지 않아도 되고, 일별 백업으로 RPO 24시간을 달성합니다. 활성 지역 복제는 고비용으로 부적합합니다.
시나리오 2: 리전 장애 시 자동 장애 조치 + 애플리케이션 연결 문자열 변경 없이 서비스 재개 (Azure SQL Database) Auto-Failover Group을 선택합니다. Primary Listener(읽기/쓰기)와 Secondary Listener(읽기 전용) 두 개의 고정 DNS 엔드포인트를 제공하여 장애 조치 후에도 연결 문자열 변경이 필요 없습니다. Active Geo-Replication은 수동 장애 조치만 지원하고 별도 엔드포인트 관리가 필요합니다.
시나리오 3: IaaS VM에서 SQL Server 운영 + 수동 개입 없는 자동 장애 조치 Always On AG + ILB를 선택합니다. 동기 커밋 모드에서 RPO=0, 자동 페일오버를 지원합니다. Azure SQL DB 자동 장애조치는 PaaS 서비스이므로 IaaS 유지 요건에 맞지 않습니다.
시나리오 4: 리전 장애에도 VMSS 기반 웹 서비스 연속성 보장 보조 리전 VMSS + Azure Front Door를 선택합니다. 가용성 영역 분산만으로는 리전 전체 장애를 대응할 수 없습니다.
시나리오 5: 온프레미스 파일 서버 에이전트 백업 + 별도 백업 서버 불필요 MARS Agent + Recovery Services Vault를 선택합니다. Windows Admin Center와의 차이는 에이전트 추가 설치 여부입니다. 에이전트 추가 배포가 금지되고 Azure 포털 없이 관리가 필요하면 Windows Admin Center 내장 Backup 기능을 선택합니다.
---
실무 적용 팁
실제 설계에서 자주 빠지는 함정을 정리합니다.
Vault GRS 구성에 주의하세요. GRS를 설정하면 백업 데이터가 쌍 리전에 복제되어 리전 간 데이터 혼합이 발생합니다. 리전별 데이터 분리 규정이 있다면 LRS/ZRS와 리전별 별도 Vault를 선택해야 합니다.
Azure Policy로 백업 거버넌스를 자동화하세요. 수백 개 VM을 수동으로 관리하면 누락이 생깁니다. 내장 정책(Azure Virtual Machines에 대해 Azure Backup 구성)을 사용하면 신규 VM도 자동으로 정책에 포함됩니다.
Site Recovery의 테스트 장애 조치를 정기적으로 실행하세요. 격리된 네트워크에서 진행되므로 프로덕션 환경에 영향을 주지 않습니다.
Key Vault failover 중 애플리케이션 동작을 미리 검증하세요. failover 상태에서 Key Vault는 읽기 전용 모드이며 새 키 생성이나 수정은 불가능합니다. 쓰기 로직이 있다면 failover 중 오류가 발생할 수 있습니다.
---
정리
핵심을 세 줄로 요약합니다.