Azure Storage의 중복성은 Primary Region 안에서 데이터를 어떻게 복제하는지(LRS, ZRS)와 Secondary Region에도 복제하는지(GRS, GZRS)의 조합입니다. 운영 데이터는 ZRS를 기본으로 두고, Region 전체 장애까지 대비해야 하면 GZRS를 고릅니다. 앞에 RA가 붙으면 평소에도 Secondary Region에서 데이터를 읽을 수 있습니다.
1. 중복성 옵션
Azure Storage는 어떤 옵션을 골라도 Primary Region 안에 데이터를 3개 복사해 둡니다. 차이는 그 3개를 한 데이터센터에 두는지, 여러 Availability Zone에 나눠 두는지, 그리고 멀리 떨어진 Secondary Region에 한 벌 더 두는지입니다(Storage Account 자체는 Azure Storage 종류 정리에서 다뤘습니다).

옵션별로 Primary Region의 데이터센터·Zone과 Secondary Region에 복사본이 놓이는 위치
2. 옵션 비교
| 옵션 | 복사본 위치 | 견디는 장애 | 내구성 |
| LRS | 데이터센터 1곳에 3개 | 서버·랙 장애 | 11 nines |
| ZRS | Zone 3곳에 1개씩 | 데이터센터(Zone) 장애 | 12 nines |
| GRS | LRS 3개 + Secondary LRS 3개 |
Region 전체 장애 | 16 nines |
| GZRS | ZRS 3개 + Secondary LRS 3개 |
Zone 장애와 Region 장애 | 16 nines |
Primary Region 안의 복제는 동기 방식이라 쓰기가 끝나면 3개가 모두 저장된 상태입니다. Secondary Region으로는 비동기로 복제되므로 보통 15분 안쪽의 차이가 생길 수 있고, 이 시간에 대한 SLA는 없습니다. Secondary Region은 Region Pair로 정해져 있어서 Korea Central이면 Korea South가 되고 직접 고를 수 없습니다.
3. RA와 Failover
GRS와 GZRS는 평소에 Secondary Region의 데이터를 읽을 수 없고, Failover를 해야 쓸 수 있습니다. RA-GRS, RA-GZRS를 고르면 계정이름-secondary.blob.core.windows.net 주소로 언제든 읽을 수 있어서 읽기 SLA가 99.9%에서 99.99%로 올라갑니다.
| 항목 | GRS·GZRS | RA-GRS·RA-GZRS |
| Secondary 읽기 | Failover 후에만 | 평소에도 가능 |
| 읽기 SLA(Hot) | 99.9% | 99.99% |
| Azure Files | 지원 | 지원 안 함 |
Primary Region에 문제가 생기면 Customer-managed Failover로 Secondary Region을 새 Primary로 바꿀 수 있습니다. 비동기 복제라 마지막 몇 분의 데이터는 잃을 수 있으므로, Failover 전에 Last Sync Time으로 어디까지 복제됐는지 확인합니다.
4. 상황별 선택
| 상황 | 추천 |
| 개발·테스트, 다시 만들 수 있는 데이터 | LRS |
| 운영 서비스 데이터 | ZRS |
| Region 장애에도 데이터를 지켜야 하는 백업·기록 | GRS 또는 GZRS |
| Region 장애 중에도 읽기를 계속해야 하는 서비스 | RA-GZRS |
| Archive Tier로 오래 보관할 데이터 | LRS 또는 GRS(ZRS 계열은 Archive 불가) |
저는 운영 계정은 ZRS로 시작하고, 백업처럼 Region 장애까지 견뎌야 하는 계정만 GZRS로 올리는 편입니다. Premium 계정과 Managed Disk는 LRS와 ZRS만 고를 수 있습니다.
5. 중복성 바꾸기
Secondary Region을 붙이거나 떼는 변경(LRS ↔ GRS, ZRS ↔ GZRS)은 바로 바뀝니다. LRS에서 ZRS로 가는 것처럼 Primary Region의 복제 방식을 바꾸는 변경은 Conversion 요청으로 진행되고, 보통 72시간 안에 시작되며 중단은 없습니다.
RG=rg-storage
NAME=<Storage Account 이름>
# 현재 중복성과 Region Pair 확인
az storage account show --name $NAME --resource-group $RG \
--query "{sku:sku.name, primary:primaryLocation, secondary:secondaryLocation}"
# LRS → RA-GRS: 바로 변경
az storage account update --name $NAME --resource-group $RG --sku Standard_RAGRS
# Secondary Region까지 복제된 시점
az storage account show --name $NAME --resource-group $RG \
--expand geoReplicationStats --query geoReplicationStats.lastSyncTime
# LRS 계정을 ZRS로 바꿀 때: Conversion 요청(GRS 계열이면 먼저 LRS로 되돌림)
az storage account migration start --account-name $NAME --resource-group $RG \
--sku Standard_ZRS --no-wait
6. 운영 시 주의점
| 항목 | 조치 |
| Archive Blob이 있는 계정 | ZRS 계열로 바꾸기 전에 Archive Blob을 Rehydrate하거나 다른 계정으로 옮깁니다. |
| GRS로 변경할 때 비용 | 기존 데이터를 Secondary Region으로 복사하는 데이터 전송 요금이 한 번 붙습니다. |
| RA를 뗀 뒤 요금 | RA-GRS에서 GRS로 바꿔도 30일 동안은 RA-GRS 요금이 나옵니다. |
| 연속 변경 | Conversion이 끝난 뒤 24시간이 지나야 다시 바꿀 수 있습니다. |
7. 정리
- LRS와 ZRS는 Primary Region 안의 복제 방식이고, G가 붙으면 Secondary Region에 비동기로 한 벌 더 복제합니다.
- 운영 데이터는 ZRS, Region 장애 대비는 GZRS, 평소에도 Secondary에서 읽어야 하면 RA-GZRS를 고릅니다.
- Secondary 추가·제거는 바로 바뀌지만 LRS ↔ ZRS는 Conversion이 필요하고, Archive는 ZRS 계열에서 쓸 수 없습니다.
참고
'Cloud > Azure' 카테고리의 다른 글
| [Azure] Azure Storage 종류 정리 (0) | 2026.09.26 |
|---|---|
| [Azure] Private Link Service 정리 (0) | 2026.09.25 |
| [Azure] Azure Firewall 구성 정리 (0) | 2026.09.25 |
| [Azure] Microsoft Foundry 구성 정리 (0) | 2026.09.25 |
| [Azure] AKS Ingress Gateway API 이전 정리 (0) | 2026.09.25 |