VM 하나로 서비스를 운영하다 재부팅 한 번에 다운타임을 겪고 나면 고가용성을 고민하게 됩니다. 가용성 세트와 가용성 영역을 장애 범위·SLA·비용 기준으로 비교하고, 우리 워크로드엔 무엇이 맞는지 정리했습니다.
- 가용성 세트 : 한 데이터센터 안에서 랙·전원·업데이트 그룹 분산. 하드웨어 장애·유지 관리 재부팅 대비. SLA 99.95%.
- 가용성 영역 : 리전 내 물리적으로 분리된 DC 3곳에 분산. 데이터센터 전체 장애 대비. SLA 99.99%.
- 공통 : 최소 2대 이상을 나눠 배치해야 SLA가 적용됨. 단일 VM은 해당 없음.
고가용성 설계의 출발점은 “어떤 장애를 견딜 것인가”입니다. 서버 한 대의 디스크가 고장 나는 정도인지, 데이터센터 건물 하나가 정전으로 통째로 내려가는 정도인지에 따라 답이 갈립니다. 가용성 세트는 전자, 가용성 영역은 후자까지 견딥니다.
두 방식 한눈에 비교
| 기준 | 가용성 세트(Availability Set) | 가용성 영역(Availability Zone) |
|---|---|---|
| 분산 단위 | 같은 DC 내 장애/업데이트 도메인 | 리전 내 물리적 분리 DC 3곳 |
| 견디는 장애 | 랙·전원·유지 관리 재부팅 | 데이터센터 전체 장애 |
| 다중 VM SLA | 99.95% | 99.99% |
| 지연/네트워크 | 매우 낮음(같은 DC) | 영역 간 소폭 지연 |
| 추가 비용 | 없음(VM 비용만) | 영역 간 트래픽 비용 발생 가능 |
| 리전 지원 | 대부분 | 지원 리전에 한함 |
둘의 관계는 포함이 아니라 대안입니다. 하나의 VM은 세트나 영역 중 하나에만 속합니다. 영역을 지원하는 리전이고 미세한 지연이 문제되지 않으면, 대개 영역 분산이 더 넓은 보호를 제공합니다.
장애 도메인과 업데이트 도메인
가용성 세트를 이해하려면 두 개념을 알아야 합니다. 장애 도메인(Fault Domain)은 전원·네트워크 스위치를 공유하는 물리적 랙 묶음으로, 하나가 죽어도 다른 도메인의 VM은 살아 있습니다. 업데이트 도메인(Update Domain)은 플랫폼 유지 관리 시 동시에 재부팅되지 않도록 나눈 논리 그룹입니다. 세트에 VM을 2대 이상 두면 이 둘에 자동 분산돼, 랙 장애와 계획된 재부팅을 모두 견딥니다.
가용성 영역의 동작
가용성 영역은 같은 리전 안이지만 독립된 전원·냉각·네트워크를 가진 물리적으로 분리된 데이터센터입니다. 보통 리전당 3개 영역이 있고, VM을 영역 1·2·3에 나눠 배치하면 영역 하나가 통째로 내려가도 나머지 두 영역이 서비스를 이어갑니다. 로드 밸런서를 영역 간에 걸쳐 두면 트래픽이 살아 있는 영역으로 자동 분배됩니다.
같은 DC 내 하드웨어·재부팅만 견디면 되고 지연이 극도로 민감하면 가용성 세트, 데이터센터 전체 장애까지 견뎌야 하고 리전이 영역을 지원하면 가용성 영역. 프로덕션이고 리전이 영역을 지원하면 영역 분산을 우선하세요.
설정 예시
# 가용성 세트에 VM 배치
az vm create --resource-group rg-demo --name web1 \
--availability-set myAvSet --image Ubuntu2204 ...
# 가용성 영역에 VM 배치 (영역 1)
az vm create --resource-group rg-demo --name web1 \
--zone 1 --image Ubuntu2204 ...
# web2는 --zone 2, web3는 --zone 3 으로 분산
중요한 점: 가용성 세트는 VM 생성 시에만 지정할 수 있습니다. 이미 만든 VM을 세트에 넣거나 영역을 바꾸려면 재배포가 필요하므로, 설계 단계에서 정해야 합니다.
워크로드별 선택
가용성 세트가 맞는 경우 — 영역을 지원하지 않는 리전, 영역 간 지연조차 허용하기 어려운 초저지연 워크로드, 같은 DC 안에서의 하드웨어·유지 관리 내성만으로 충분한 내부 서비스.
가용성 영역이 맞는 경우 — 데이터센터 단위 장애로도 멈추면 안 되는 프로덕션 웹·API, 높은 SLA가 계약·규제로 요구되는 서비스, 영역 중복 로드 밸런서·게이트웨이와 함께 구성하는 표준적 3계층 아키텍처.
흔한 실수
- VM 1대만 두고 SLA를 기대한다 — 세트든 영역이든 최소 2대 이상을 분산해야 SLA가 적용됩니다. 단일 VM은 어느 쪽도 SLA 대상이 아닙니다.
- 모든 VM을 같은 영역에 몰아 둔다 — 영역을 쓰면서 전부 영역 1에 두면 분산 효과가 없습니다. 서로 다른 영역에 나눠야 합니다.
- 데이터 계층을 빼먹는다 — 웹 계층만 이중화하고 DB를 단일 VM에 두면 거기서 멈춥니다. DB도 영역 중복 옵션(또는 관리형 서비스의 영역 중복)을 씁니다.
- 로드 밸런서를 단일 지점으로 둔다 — 앞단 LB가 특정 영역에만 있으면 그 영역 장애 시 전체가 끊깁니다. 표준 로드 밸런서의 영역 중복 프런트엔드를 씁니다.
- 나중에 바꾸면 된다고 미룬다 — 세트·영역은 생성 시 결정입니다. 초기에 정하지 않으면 재배포 비용을 치르게 됩니다.
관리형 서비스라면 더 간단하다
App Service, SQL Database, AKS 같은 관리형 서비스는 대부분 영역 중복 옵션을 체크 한 번으로 제공합니다. VM을 직접 관리하지 않아도 되는 워크로드라면, IaaS 수준에서 세트/영역을 손으로 짜기보다 관리형 서비스의 영역 중복 기능을 켜는 편이 훨씬 단순하고 안정적입니다.
자주 묻는 질문
- Q. 가용성 세트와 가용성 영역은 무엇이 다른가요?
세트는 한 데이터센터 안에서 랙·전원·업데이트 그룹에 분산해 하드웨어 장애와 유지 관리 재부팅을 견딥니다. 영역은 리전 내 분리된 데이터센터 3곳에 분산해 데이터센터 전체 장애까지 견딥니다. - Q. 어느 쪽 SLA가 높은가요?
다중 VM 기준 가용성 세트는 99.95%, 서로 다른 두 개 이상 영역 분산은 99.99%입니다. 더 높은 가용성이 필요하면 영역 분산이 유리합니다. - Q. 둘을 동시에 쓸 수 있나요?
하나의 VM은 세트나 영역 중 하나에만 속합니다. 대규모 설계에서는 영역별 확장 집합으로 분산과 규모를 함께 얻을 수 있습니다. - Q. 나중에 세트/영역을 바꿀 수 있나요?
둘 다 VM 생성 시 결정이라 이후 변경은 재배포가 필요합니다. 설계 단계에서 확정하세요.
정리하면, “견뎌야 하는 장애의 크기”가 선택을 결정합니다. 랙·재부팅 수준이면 가용성 세트, 데이터센터 전체 장애까지면 가용성 영역. 그리고 어느 쪽이든 웹·앱·데이터 모든 계층을 함께 이중화해야 실제로 끊기지 않는 서비스가 됩니다.