DP-300 시험에서 고가용성·재해 복구 파트는 '어떤 상황에 어떤 옵션을 선택하는가'를 집중적으로 묻습니다. Azure SQL Database와 SQL Managed Instance가 제공하는 백업·복제·페일오버 옵션은 다양하지만, 각각의 역할이 명확히 구분됩니다. 백업은 논리적 손상에, 복제는 물리적 재해에, 자동 페일오버는 무중단 연속성에 각각 대응합니다.
PITR — 실수를 되돌리는 타임머신
주말에 개발자가 잘못된 UPDATE 문을 실행해 핵심 테이블 데이터 수천 건을 덮어써버렸다고 상상해보세요. 롤백 스크립트도 없고, 어디서부터 잘못됐는지 정확한 시각만 알고 있는 상황입니다. Azure SQL Database는 이런 논리적 손상을 위한 해답으로 Point-in-Time Restore(PITR)를 제공합니다.
PITR은 자동 백업 세 종류를 조합해 동작합니다. 전체 백업(full)은 주 1회, 차등 백업(differential)은 12시간마다, 트랜잭션 로그 백업(log)은 5~10분마다 자동으로 실행됩니다. 이 세 가지가 결합되어 보존 기간 내 임의의 분 단위 시점으로 복원이 가능합니다.
기본 보존 기간은 7일이며 최대 35일까지 늘릴 수 있습니다. 복원 결과물은 항상 새 데이터베이스로 생성됩니다. 원본을 직접 덮어쓰지 않으므로, 복원 후 DBA가 데이터를 검증하고 애플리케이션 연결을 수동으로 전환해야 합니다.
LTR — 10년치 기록을 보관하는 금고
세무 당국이 7년치 거래 기록을 요구하거나, 의료 규정이 환자 데이터를 10년간 보관하도록 의무화하는 상황을 생각해보세요. PITR의 최대 35일 보존으로는 이 요구사항을 충족할 수 없습니다. Long-Term Retention(LTR)은 이런 규제 준수를 위해 설계된 기능입니다.
LTR은 전체 백업을 Azure Blob Storage에 별도로 저장하여 최대 10년까지 보관합니다. 주별·월별·연별 보존 정책을 세밀하게 설정할 수 있습니다. 예를 들어 주별 백업 12주 보관, 월별 백업 36개월 보관, 연별 백업 5년 보관 등 조합이 가능합니다.
LTR은 PITR과 목적이 다릅니다. PITR이 '어제 오후 3시 17분으로 되돌리기' 같은 정밀 복원을 위한 것이라면, LTR은 '작년 1월 1일 기준 전체 스냅샷 보관' 같은 장기 아카이브용입니다. 두 기능은 서로 보완적이며 함께 사용됩니다.
!PITR vs LTR
Active Geo-Replication — 도시 반대편에 대기 중인 쌍둥이
택배 허브가 태풍으로 마비됐을 때, 다른 도시에 이미 동일한 재고를 갖춘 백업 허브가 있다면 배송은 거의 끊기지 않을 수 있습니다. Active Geo-Replication은 Azure SQL Database를 대상으로 정확히 이 구조를 제공합니다.
Active Geo-Replication은 데이터베이스 단위로 최대 4개의 읽기 가능한 보조 복제본(readable secondary)을 다른 리전에 생성합니다. 복제는 비동기 방식으로 이루어지며, 보조 복제본은 동시에 읽기 전용 워크로드(리포트, 분석 쿼리)에도 활용할 수 있습니다.
장애 발생 시 수동 페일오버(manual failover)를 통해 보조 복제본을 주 복제본으로 승격시킵니다. 이 과정이 자동으로 이루어지지 않는다는 점이 Auto-Failover Group과의 핵심 차이입니다. Active Geo-Replication은 SQL Managed Instance에서는 지원되지 않습니다.
Auto-Failover Group — 경보가 울리면 자동으로 전환되는 시스템
건물 화재 경보가 울리면 사람이 직접 소화기를 들고 달려가야 할까요, 아니면 스프링클러가 자동으로 물을 뿜어야 할까요? Auto-Failover Group은 데이터베이스 장애 대응에 스프링클러 역할을 합니다.
Auto-Failover Group은 데이터베이스 또는 SQL Managed Instance 그룹을 단위로 자동 페일오버를 지원합니다. 주 리전에 장애가 발생하면 사전 설정된 정책에 따라 보조 리전으로 자동 전환됩니다. 애플리케이션은 읽기/쓰기 리스너 엔드포인트(read-write listener endpoint)를 사용하므로 연결 문자열을 변경하지 않아도 됩니다.
Active Geo-Replication과 달리 Auto-Failover Group은 SQL Database와 SQL Managed Instance 양쪽을 모두 지원합니다. 또한 그룹 내 여러 데이터베이스를 한 번에 관리할 수 있어, 여러 데이터베이스를 운영하는 복잡한 애플리케이션에 적합합니다.
Geo-Replication vs Auto-Failover Group — 어느 쪽을 선택하나
| 항목 | Active Geo-Replication | Auto-Failover Group | |:--|:--|:--| | 단위 | 개별 데이터베이스 | 데이터베이스 그룹 또는 MI | | 지원 제품 | SQL Database만 | SQL Database + SQL MI | | 페일오버 방식 | 수동 | 자동 (정책 설정 가능) | | 읽기 전용 보조 | 최대 4개 | 가능 (읽기 전용 리스너 제공) | | 리스너 엔드포인트 | 없음 | 있음 | | 여러 DB 일괄 관리 | 불가 | 가능 |
단일 데이터베이스에서 보조 복제본을 읽기 워크로드에 활용하면서 수동 제어를 원한다면 Active Geo-Replication을, 여러 데이터베이스를 그룹으로 묶어 자동 전환과 단일 연결 엔드포인트가 필요하다면 Auto-Failover Group을 선택합니다.
Always On AG와 FCI — IaaS(SQL on VM) 환경의 HA
Azure VM 위에서 SQL Server를 직접 운영한다면, 즉 PaaS가 아닌 IaaS 환경이라면 고가용성 구성 방식이 달라집니다. Always On Availability Groups(AG)와 Failover Cluster Instance(FCI)가 이 영역의 핵심 옵션입니다.
Always On AG는 동기(sync) 또는 비동기(async) 복제를 선택할 수 있는 다중 노드 구성입니다. 리스너(listener)를 통해 클라이언트가 항상 주 노드로 연결되며, 장애 시 자동 또는 수동으로 다른 노드가 주 역할을 이어받습니다. 동기 복제는 RPO를 0에 가깝게 줄이지만 쓰기 성능에 영향을 줍니다.
FCI는 인스턴스 수준의 가용성을 제공합니다. 공유 스토리지(shared storage)를 사용하는 클러스터 구성으로, 노드 중 하나가 실패하면 다른 노드가 같은 인스턴스를 이어받습니다. SQL MI의 경우 기본 제공되는 인스턴스 수준 가용성이 FCI와 유사한 역할을 담당합니다.
자주 틀리는 함정 — 비슷해 보이지만 다른 개념들
시험에서 가장 혼동을 일으키는 지점은 PITR과 Geo-Replication을 같은 맥락에서 비교하는 문제입니다. PITR은 논리적 손상을 되돌리는 도구이고, Geo-Replication은 물리적 재해에 대비하는 구조입니다.
또 한 가지 주의할 점은 Active Geo-Replication이 SQL Managed Instance를 지원하지 않는다는 사실입니다. 시험 문제에서 'SQL MI + 읽기 가능 보조 복제본'이 함께 등장하면, 정답은 항상 Auto-Failover Group입니다.
Geo-restore도 빈번히 혼동됩니다. Geo-restore는 기본 region 전체가 다운됐을 때 백업에서 복원하는 방식으로, RPO가 수 시간에 달할 수 있고 실시간 복제가 필요한 경우에는 Active Geo-Replication 또는 Auto-Failover Group을 선택해야 합니다.
시험 핵심 정리
"논리적 손상, 잘못된 쿼리 실행 복구" -- PITR (Point-in-Time Restore) "7년, 10년 규제 보관 기간" -- LTR (Long-Term Retention) "PITR 기본 보존 기간" -- 7일 (최대 35일) "LTR 최대 보존 기간" -- 10년 "단일 DB, 읽기 가능 보조, 수동 페일오버" -- Active Geo-Replication "여러 DB 그룹, 자동 페일오버, 리스너 엔드포인트" -- Auto-Failover Group "SQL MI + 복제" -- Auto-Failover Group (Geo-Replication은 SQL MI 미지원) "IaaS SQL on VM, 동기/비동기 복제, 다중 노드" -- Always On Availability Groups "IaaS SQL on VM, 인스턴스 수준 HA, 공유 스토리지" -- Failover Cluster Instance "페일오버 후 앱 연결 문자열 변경 불필요" -- Auto-Failover Group 리스너 엔드포인트 "기본 region 전체 장애 시 백업 복원" -- Geo-redundant 백업 + Geo-restore
PITR = 논리 손상 단기 복원, LTR = 규제 장기 보관, Active Geo-Replication = 단일 DB 수동 전환, Auto-Failover Group = 그룹 자동 전환