DBA 가 알려주는 고가용성(HA)의 쉬운 이해
고가용성(HA, High Availability)은 “서버를 두 대로 만든다”가 아니라, 장애가 발생해도 서비스가 끊기지 않게(또는 최소 시간 내 복구되게) 설계·운영하는 체계입니다.
SQL Server의 HA를 이해하려면 먼저 가용성(Availability) 숫자, 그리고 RTO/RPO(복구 목표)를 기준으로 “무엇을 선택해야 하는지”가 보이기 시작합니다.
1. 가용성(Availability)이란 무엇인가?
1.1 가용성의 정의와 계산식
가용성은 “시스템이 사용자 요청을 정상 처리할 수 있는 시간의 비율”입니다.
- Availability(%) = (총 운영 시간 – 다운타임) / 총 운영 시간 × 100
- 흔히 “Nines(9의 개수)”로 표현합니다. (예: 99.99% = ‘4 nines’)
가용성 수치가 의미하는 연간 다운타임(대략치)
(1년 = 365일 기준)
| 가용성 | 다운타임 비율 | 연간 다운타임(대략) |
|---|---|---|
| 99% | 1% | 3.65일 |
| 99.9% | 0.1% | 8.76시간 |
| 99.95% | 0.05% | 4.38시간 |
| 99.99% | 0.01% | 52.56분 |
| 99.999% | 0.001% | 5.26분 |
실무적으로 중요한 포인트는 “목표 가용성”이 곧 허용 다운타임이며, 이 숫자가 곧 아키텍처 비용과 운영 난이도를 결정한다는 점입니다.
1.2 가용성 vs 내결함성 vs 복구성(그리고 RTO/RPO)
세 개념은 비슷해 보이지만, 설계/운영 관점에서 역할이 다릅니다.
| 개념 | 설명 | 핵심 질문 |
|---|---|---|
| 가용성(Availability) | 장애가 발생해도 서비스를 계속 제공할 수 있는 능력 | “장애 시 자동/신속 복구가 가능한가?” |
| 내결함성(Fault Tolerance) | 일부 구성요소가 고장 나도 서비스 중단 없이 계속 동작 | “장애가 나도 멈추지 않는가?”(비용/복잡도↑) |
| 복구성(Recoverability) | 장애 후 정상 상태로 되돌아오는 능력 | “얼마나 빨리/얼마나 덜 잃고 복구하는가?” |
여기에 실무에서 반드시 붙는 두 지표가 있습니다.
- RTO (Recovery Time Objective): “얼마나 빨리 복구해야 하는가?” (최대 허용 중단 시간)
- RPO (Recovery Point Objective): “데이터를 얼마나 잃어도 되는가?” (최대 허용 데이터 손실)
예를 들어,
- RTO 5분 / RPO 0초 → 동기식 복제 + 자동 페일오버 수준이 필요할 가능성이 큼
- RTO 2시간 / RPO 10분 → 로그 기반/비동기 기반도 현실적 선택지가 됨
2. SQL Server에서의 HA 구성 방식 개요
SQL Server의 HA는 크게 인스턴스 단위(서버 장애 대응)와 데이터베이스 단위(복제 기반)로 나뉩니다.
2.1 대표 옵션(실무에서 자주 쓰는 것 중심)
| 구성 방식 | 단위 | 핵심 특징 | 주 용도 |
|---|---|---|---|
| Failover Cluster Instance(FCI) | 인스턴스 | 공유 스토리지 기반, SQL 인스턴스가 통째로 이동 | 서버 장애 대응(인스턴스 HA) |
| Always On Availability Group(AG) | DB | 각 노드가 DB 복제본 보유, 로그 기반 동기/비동기 복제 | DB 단위 HA + 읽기 부하 분산 |
| Log Shipping | DB | 로그 백업/복원으로 지연 복제(대부분 수동 전환) | DR/저비용 복구, RPO 허용 가능 |
| Database Mirroring(레거시) | DB | 구형 기술(현재는 대체로 AG 권장) | 기존 시스템 유지(점진적 감소) |
| Backup/Restore | DB | 마지막 보루. HA라기보다 복구 전략 | 모든 전략의 기반 |
용어 정리: 과거 “MSCS”라고 불리던 영역은 현재 Windows에서는 WSFC(Windows Server Failover Clustering) 기반으로 이해하는 것이 정확합니다.
또한 “Always On”은 마케팅/기능군 용어로, 실무에서는 FCI(인스턴스) 와 AG(DB)를 구분해서 설계합니다.
3. FCI(구 MSCS, WSFC 기반) 공유 스토리지 방식 쉽게 이해하기
3.1 구조 개념(한 문장)
데이터는 공유 스토리지에 1벌만 있고, SQL 인스턴스(이름/IP 포함)가 노드 간 이동합니다.
- Active 노드가 서비스 제공
- 장애 발생 시 Passive 노드가 같은 디스크를 인계받아 SQL Server 서비스를 올림
- 클러스터가 네트워크 이름/가상 IP/서비스 리소스를 함께 전환
3.2 장점(FCI가 강한 지점)
- 개념이 직관적(“인스턴스가 통째로 넘어간다”)
- 애플리케이션 입장에서는 접속 대상이 단순(일반적으로 동일한 인스턴스 이름/주소)
- 서버 장애 대응에 강함(인스턴스 단위로 일관성 확보)
3.3 단점(운영 리스크 포인트)
- 공유 스토리지는 설계에 따라 SPOF(단일 실패 지점)가 될 수 있음
→ 스토리지 이중화/복구 전략이 핵심 - SAN/공유 디스크 기반 인프라 의존도가 높아 비용/운영 난이도가 커질 수 있음
- 클라우드에서도 가능은 하지만(공유 디스크/파일 공유 기반 등), 온프레보다 제약/구성 난이도가 높아지는 경우가 많음
4. Always On Availability Group(AG) 방식 쉽게 이해하기
4.1 구조 개념(한 문장)
각 노드가 DB 복제본을 각각 들고 있고, 트랜잭션 로그를 네트워크로 전송해 동기화합니다.
핵심 구성 요소(개념만 잡아도 충분)
- Primary Replica: 쓰기(Write) 처리
- Secondary Replica: 복제본 유지(동기/비동기)
- Commit 모드
- Synchronous Commit: RPO=0에 가까운 설계 가능(대신 지연이 Primary에 반영됨)
- Asynchronous Commit: WAN/원거리 DR에 유리(대신 데이터 손실 가능성 존재)
- Listener: 애플리케이션이 접속하는 논리 엔드포인트(전환 시 대상이 바뀜)
4.2 장점(AG가 강한 지점)
- 공유 스토리지 불필요(스토리지 독립성)
- 읽기 전용 복제본(Read-only Secondary) 활용 가능
→ 리포팅/조회 부하 분산, 백업 오프로딩 전략과 결합 가능 - 네트워크 기반 복제이므로 클라우드/하이브리드 아키텍처에 유연
- DB 단위로 Failover 가능(핵심 DB만 우선 보호 같은 전략 가능)
4.3 단점(AG에서 실제로 어려운 지점)
- 구성 요소가 많아 설계/운영 난이도↑
(엔드포인트, 리스너, 동기화 상태, 라우팅, 쿼럼 등) - 네트워크 지연/대역폭이 부족하면 복제 지연(Lag) 및 성능 영향이 커질 수 있음
- 여러 DB를 함께 쓰는 애플리케이션은
“같은 AG로 묶기”, “Failover 시점 정합성”, “배치/잡 의존성” 등을 꼼꼼히 설계해야 함
(특히 교차 DB 트랜잭션이 많은 경우 운영 규칙이 중요)
참고: SQL Server 에디션/버전에 따라 AG 기능(복제본 수, 읽기 라우팅, 고급 기능 등)에 제약이 있을 수 있으므로, 실제 설계 시 “에디션 요구사항”을 먼저 확인하는 것이 안전합니다.
5. FCI vs AG 비교 요약(실무 관점)
| 항목 | FCI(공유 스토리지) | AG(복제 기반) |
|---|---|---|
| 데이터 저장 | 공유 스토리지 1벌 | 노드별 DB 복제본 |
| Failover 단위 | 인스턴스 단위 | DB 단위 |
| 읽기 분산 | 일반적으로 어려움 | 가능(읽기 전용 Secondary) |
| 구성 난이도 | 상대적으로 낮음 | 상대적으로 높음 |
| 핵심 리스크 | 스토리지/SPOF, 공유 인프라 | 네트워크/복제지연, 운영 복잡도 |
| 클라우드 적합성 | 가능하나 제약/복잡도가 커질 수 있음 | 일반적으로 유리 |
현실적인 결론은 단순합니다.
- “인스턴스 단위로 단순하게 서버 장애만 막고 싶다” → FCI 성향
- “DB 단위로 유연하게 + 읽기 분산/DR까지 확장하고 싶다” → AG 성향
6. 23년차 DBA의 실무 팁과 조언(진짜 중요한 것)
6.1 선택은 ‘기술’이 아니라 ‘목표(RTO/RPO) + 운영 현실’로 한다
다음 3가지를 먼저 수치로 적으면, 답이 빨리 나옵니다.
- RTO: 장애 후 몇 분 안에 복구해야 하는가?
- RPO: 데이터 손실은 0초인가, 10초/1분/10분까지 허용되는가?
- 운영 가능성: 우리 팀이 이 구조를 24×7로 모니터링/조치할 수 있는가?
6.2 쿼럼(Quorum) 설계를 소홀히 하면 “살아있는 서버가 죽는다”
2노드 구성에서는 특히 쿼럼/위트니스(witness)가 중요합니다.
쿼럼이 불안정하면 장애가 아닌데도 클러스터가 리소스를 내릴 수 있습니다.
6.3 문서보다 강한 것은 “손의 기억(리허설)”이다
HA는 구성보다 전환/복구 절차가 더 중요합니다.
- Planned failover(계획 전환) 절차
- 장애 상황(노드 다운/네트워크 분리/스토리지 지연)에서의 판단 기준
- 롤백 전략(전환 실패 시 원복 기준, 데이터 정합성 확인)
분기 1회라도 실제 페일오버 리허설을 해보면 운영 품질이 달라집니다.
6.4 학습 팁: VM 2대 + Witness 1개로 “전환 체감”부터
- VM 2대 구성(Primary/Secondary)
- 간단한 테스트 DB 한 개
- Sync/Async 전환, Failover 수행
- 로그 전송 지연을 일부러 만들고(Lag), 모니터링으로 확인
개념은 책에서 잡아도 되지만, 감각은 반드시 실습에서 잡힙니다.
7. 자주 묻는 질문(FAQ)
Q1. FCI와 AG 중 어느 것이 더 안정적인가요?
둘 다 안정적입니다.
FCI는 인스턴스 단위 전환이 단순한 대신 공유 인프라(스토리지)가 설계 핵심이고,
AG는 SPOF를 줄이고 확장성이 좋지만 네트워크/운영 복잡도를 감당해야 합니다.
안정성은 ‘구성 자체’보다 ‘운영 리허설과 모니터링 체계’에서 갈립니다.
Q2. AG를 구성할 때 최소 몇 대의 노드가 필요한가요?
기술적으로는 Primary + Secondary 2대로도 구성이 가능하지만,
운영 안정성(쿼럼)을 고려하면 2대 + Witness(제3의 투표) 구조를 강하게 권장합니다.
실무에서 “3표(3 votes)” 구성이 안정적입니다.
Q3. 동기식(Sync) AG의 트랜잭션 지연은 어느 정도인가요?
정해진 값은 없습니다. 동기식은 특성상 Primary가 Secondary의 로그 하든(harden) 응답을 기다리는 구간이 생기므로,
네트워크 왕복(RTT) + 스토리지 성능이 지연에 직접 반영됩니다.
같은 데이터센터/저지연 네트워크에서는 매우 작을 수 있지만, 원거리(WAN)에서는 수십 ms 이상도 가능합니다.
원거리 DR은 일반적으로 비동기(Async)를 고려합니다.
Q4. FCI에서 공유 스토리지 장애가 나면 어떻게 되나요?
공유 스토리지가 멈추면 인스턴스가 함께 멈출 수 있습니다.
따라서 스토리지는 이중화/복구 전략(스토리지 레벨 HA/복제, 백업/복구 Runbook)이 함께 있어야 합니다.
Q5. 클라우드 환경에서는 무엇을 추천하나요?
클라우드에서는 네트워크 기반 복제가 자연스럽고 구성 유연성이 좋아 AG가 많이 선택됩니다.
FCI도 구현 가능하지만(공유 디스크/파일 공유 등), 제약과 운영 복잡도가 커질 수 있으므로 조직 역량/요구 RTO/RPO 기준으로 선택하는 것이 안전합니다.
Q6. 초보 DBA는 무엇부터 시작해야 하나요?
개념은 “가용성/RTO/RPO”부터, 실습은 “Failover를 직접 해보는 것”부터 시작하세요.
눈으로 보는 것보다, 실제로 전환을 한 번이라도 해보는 경험이 가장 빠릅니다.
8. 마무리
DBA의 실무는 결국 “장애는 반드시 발생한다”는 전제에서 시작합니다.
FCI든 AG든, “구성 방법”보다 중요한 것은:
- 목표(RTO/RPO)에 맞는 선택
- 전환/복구 절차의 리허설(손의 기억)
- 모니터링과 운영 규칙의 정착
입니다.
구조를 외우기보다, 장애를 가정하고 실제로 전환·복구해보는 것이 진짜 HA 학습의 지름길입니다.