들어가며: 장애는 '예외'가 아니라 '기본값'이다
클라우드 인프라를 설계할 때 가장 흔한 착각 중 하나가 "이 정도면 장애 안 나겠지"라는 안일함입니다. 하지만 실제 운영 환경에서는 하드웨어 결함, 유지보수 윈도우, 존(Zone) 장애, 리전 전체 장애까지 다양한 수준의 중단이 발생합니다.
핵심은 장애가 발생하지 않게 막는 것이 아니라, 장애가 발생해도 서비스가 계속 동작하도록 설계하는 것입니다. Azure IaaS는 이러한 리질리언시(Resiliency, 복원력)를 플랫폼 차원에서 지원하지만, 최종 결과는 고객이 이 기능들을 어떻게 조합하고 운영하느냐에 달려 있습니다.
이 글에서는 Azure IaaS 환경에서 컴퓨팅, 스토리지, 네트워킹 각 영역의 리질리언시 설계 패턴을 실무 관점에서 정리합니다.
근거 자료: 본 내용은 Microsoft 공식 블로그 시리즈 'Azure IaaS'의 두 번째 포스트를 기반으로 재구성했습니다. 원문은 Azure IaaS - Keep critical applications running with built-in resiliency at scale에서 확인할 수 있습니다.
1. 컴퓨트 리질리언시: VM 배치와 격리의 기술
가용성 영역(Availability Zones)의 진짜 의미
가용성 영역은 단순히 'VM을 여러 개 띄우라'는 개념이 아닙니다. 데이터센터 단위의 물리적 격리를 제공합니다. 각 영역은 독립된 전력, 냉각, 네트워크를 갖추고 있어, 한 영역이 다운되어도 다른 영역의 VM은 정상 동작합니다.
# 예시: Azure SDK for Python을 사용해 가용성 영역에 VM 배포
from azure.identity import DefaultAzureCredential
from azure.mgmt.compute import ComputeManagementClient
credential = DefaultAzureCredential()
compute_client = ComputeManagementClient(credential, subscription_id)
# 가용성 영역 1, 2, 3에 각각 VM 생성
zones = ["1", "2", "3"]
for zone in zones:
vm_params = {
"location": "koreacentral",
"zones": [zone], # 영역 지정
"hardware_profile": {
"vm_size": "Standard_D2s_v3"
},
"storage_profile": { ... },
"network_profile": { ... }
}
compute_client.virtual_machines.begin_create_or_update(
resource_group_name,
vm_name + "-" + zone,
vm_params
)
실무 팁:
- 모든 VM을 단일 영역에 두면 로컬 장애에 전체가 영향받습니다. 최소 2개, 가급적 3개 영역에 분산하세요.
- VMSS(Virtual Machine Scale Sets)를 사용하면 영역 간 자동 분산과 오토스케일링을 함께 적용할 수 있어 운영 부담이 줄어듭니다.
VMSS로 자동 복구 기반 마련
VMSS는 인스턴스 장애 시 자동으로 새 인스턴스를 생성합니다. 여기에 가용성 영역을 결합하면 단일 존 장애에도 다른 존의 인스턴스가 트래픽을 계속 처리합니다.
# VMSS 생성 시 zone_balance=True로 설정하면 영역 간 균등 분배
vmss_params = {
"location": "koreacentral",
"sku": {"name": "Standard_D2s_v3", "capacity": 6},
"zones": ["1", "2", "3"],
"properties": {
"single_placement_group": False,
"zone_balance": True, # 영역 간 인스턴스 균등 배치
"upgrade_policy": {"mode": "Automatic"},
"virtual_machine_profile": { ... }
}
}
2. 스토리지 리질리언시: 데이터 복구의 마지노선
스토리지 중복 옵션은 단순한 '백업'이 아니라 RPO(복구 시점 목표)와 RTO(복구 시간 목표)를 결정짓는 핵심 요소입니다.
| 중복 모델 | 복제 범위 | 보호 수준 | 사용 사례 |
|---|---|---|---|
| LRS (로컬 중복) | 단일 데이터센터 내 3개 복제본 | 낮음 (데이터센터 장애 시 손실) | 개발/테스트, 재현 가능한 데이터 |
| ZRS (영역 중복) | 리전 내 3개 가용성 영역 | 중간 (영역 장애 보호) | 프로덕션 워크로드 |
| GRS (지역 중복) | 보조 리전에 비동기 복제 | 높음 (리전 장애 보호) | 규제 준수, 재해 복구 필수 |
| RA-GRS | GRS + 보조 리전 읽기 액세스 | 높음 + 읽기 가용성 | 글로벌 서비스, 재해 시 읽기 가능 |
실무 적용 맥락 (국내 SI 환경):
- 국내 금융권이나 공공기관은 리전 단위 재해 복구를 요구하는 경우가 많습니다. 이때 GRS나 RA-GRS가 기본이 됩니다.
- 하지만 비용이 증가하므로, 워크로드 중요도에 따라 차등 적용하는 전략이 필요합니다. 모든 스토리지를 GRS로 설정하면 예산이 순식간에 소진됩니다.
Azure Backup + Site Recovery 연계:
- Azure Backup은 정기적인 VM 스냅샷과 파일 복구를 제공합니다.
- Azure Site Recovery는 리전 간 전체 VM 복제와 장애 조치(Failover)를 자동화합니다.
- 이 둘을 함께 사용하면 RPO 15분, RTO 수 시간 이내의 재해 복구가 가능합니다.
# Azure Site Recovery 복제 정책 예시 (ARM 템플릿 발췌)
{
"type": "Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicationProtectedItems",
"properties": {
"policyId": "[parameters('replicationPolicyId')]",
"protectedItemType": "Microsoft.Compute/virtualMachines",
"sourceSiteId": "[parameters('primaryFabricId')]",
"recoverySiteId": "[parameters('recoveryFabricId')]",
"providerSpecificDetails": {
"instanceType": "HyperVReplicaAzure",
"targetStorageAccountId": "[parameters('recoveryStorageAccountId')]",
"targetNetworkId": "[parameters('recoveryNetworkId')]",
"recoveryResourceGroupId": "[parameters('recoveryResourceGroupId')]"
}
}
}
3. 네트워크 리질리언시: 트래픽이 멈추면 서비스도 멈춘다
아무리 컴퓨트와 스토리지가 건강해도, 사용자 트래픽이 도달하지 못하면 장애나 다름없습니다. Azure는 여러 계층의 로드 밸런서를 제공합니다.
| 서비스 | 계층 | 주요 기능 |
|---|---|---|
| Azure Load Balancer | L4 | VIP 기반 트래픽 분산, 가용성 영역 인식 |
| Application Gateway | L7 | SSL 종료, URL 기반 라우팅, WAF |
| Traffic Manager | DNS | 글로벌 DNS 라우팅, 엔드포인트 상태 확인 |
| Azure Front Door | 글로벌 L7 | CDN + WAF + 가속, 글로벌 장애 조치 |
실무 꿀팁:
- 단일 VM에만 트래픽을 보내지 마세요. 최소 2개 이상의 인스턴스를 로드 밸런서 뒤에 두고, 각각 다른 가용성 영역에 배치하세요.
- Traffic Manager는 DNS 기반이므로 TTL을 짧게(예: 30초) 설정해야 장애 조치가 빠릅니다. 너무 길면 장애가 발생해도 사용자가 이전 IP를 계속 호출하게 됩니다.
4. IaC로 리질리언시를 코드화하라
수동으로 VM을 만들고 설정하는 시대는 끝났습니다. Terraform, Bicep, ARM 템플릿으로 인프라를 코드화하면 재현 가능하고 일관된 리질리언시 아키텍처를 유지할 수 있습니다.
Carne Group 사례: Azure Site Recovery와 Terraform 기반 랜딩존을 결합하여 "최악의 시나리오에서도 당일 내에 복구 가능"한 환경을 구축했습니다. (원문 인용)
5. 주의사항 및 한계
- 리질리언시에는 비용이 따릅니다. 가용성 영역, GRS, Site Recovery 모두 추가 비용이 발생합니다. 모든 워크로드에 동일한 수준을 적용하는 것은 비효율적입니다.
- 복잡성 증가: 영역 간 통신 지연, 데이터 일관성 문제, 장애 조치 테스트의 어려움 등 트레이드오프가 있습니다.
- 운영 성숙도 필요: 아무리 좋은 설계도 주기적인 장애 조치 훈련(Drill)이 없으면 실제 장애 때 제대로 동작하지 않을 수 있습니다.
다음 단계 학습 방향
- Cloudflare Sandboxes 정식 출시 AI 에이전트를 위한 완전한 개발 환경 – 인프라 리질리언시와 함께 개발 환경 자동화를 고민해보세요.
- NVIDIA DLSS 4.5 공개 초해상도 강화와 동적 멀티 프레임 생성으로 게임 그래픽의 다음 지평을 열다 – 최신 그래픽 기술 트렌드도 놓치지 마세요.
- 실제로 Azure Site Recovery를 이용한 DR Drill을 분기 1회 이상 수행해보세요. 초기에는 예상치 못한 문제가 많이 발생합니다.
결론: 장애는 언젠가 옵니다. 중요한 것은 그때 당황하지 않고, 설계된 대로 복구되는지입니다. Azure IaaS의 리질리언시 기능을 제대로 이해하고 조합한다면, 장애는 단순한 '이벤트'로 축소될 수 있습니다. 지금부터라도 IaC로 인프라를 코드화하고, 주기적인 훈련을 통해 팀의 대응력을 키워보세요.