Notes

Multi-Zone Region

MZR이 하나의 cloud region 안에서 여러 zone을 통해 failure domain을 분리하는 방식과 application, database, storage, load balancer, Kubernetes, VPC를 zone-aware하게 설계하는 기준을 정리한 DevOps 네트워킹 개념 노트

Published: Jun 2, 2026
Updated: Jun 2, 2026
Area: Computer Networks
Type: concept
Series: Cloud Networking
Category: Notes

mzrmulti-zone-regionavailability-zonehigh-availabilityfault-domainmulti-zonekubernetesvpcload-balancerstoragedisaster-recoveryzone-aware

Region을 여러 Failure Domain으로 나누는 이유

Cloud에서 production workload를 운영할 때 중요한 질문은 단순히 “서버가 켜져 있는가?”가 아니다. 더 중요한 질문은 다음과 같다.

특정 data center 또는 zone에 장애가 발생해도
서비스가 계속 동작할 수 있는가?

MZR(Multi-Zone Region)은 하나의 cloud region 안에 여러 개의 독립적인 zone을 두고, workload를 zone 간에 분산할 수 있게 하는 cloud region 구조다.

MZR = Multi-Zone Region

하나의 region 안에
서로 독립적인 여러 zone을 두고
workload를 zone 간에 분산해
availability와 resiliency를 높이는 cloud region 구조

단일 zone에 모든 resource를 배치하면 그 zone이 전체 서비스의 single point of failure가 된다.

Single-Zone Region
└── Region A
    └── Zone 1
        ├── App Server
        ├── Database
        └── Load Balancer

MZR에서는 같은 region 안의 여러 zone에 workload를 분산한다.

Multi-Zone Region
└── Region A
    ├── Zone 1
    │   ├── App Server
    │   └── Worker Node
    │
    ├── Zone 2
    │   ├── App Server
    │   └── Worker Node
    │
    └── Zone 3
        ├── App Server
        └── Worker Node

MZR의 본질은 같은 region 안에서 latency는 낮게 유지하면서도 physical failure domain을 나누는 것이다.

Region, Zone, Data Center

MZR을 이해하려면 region, zone, data center를 구분해야 한다.

Region

Region은 cloud provider가 특정 geographic area에 구성한 cloud service 제공 단위다. 보통 도시 또는 metropolitan area 이름으로 표현된다.

예시는 다음과 같다.

Dallas region
London region
Tokyo region
Frankfurt region
Sydney region

Region은 사용자가 cloud resource를 배치할 때 선택하는 큰 지리적 단위다.

어느 나라 또는 어느 도시권에 workload를 둘 것인가?

이 질문에 대한 답이 region이다.

Zone

Zone은 region 안에 있는 독립적인 failure domain이다.

즉 zone은 다음 질문과 관련된다.

같은 region 안에서
어느 독립 장애 영역에 workload를 둘 것인가?

예를 들어 하나의 region 안에 세 zone이 있다면 다음과 같이 표현할 수 있다.

Region: us-south

Zone 1: us-south-1
Zone 2: us-south-2
Zone 3: us-south-3

각 zone은 독립적인 장애 영역으로 설계된다.

Zone 1 장애
  ↓
Zone 2, Zone 3은 계속 동작하도록 설계

Data Center

Data center는 실제 서버, storage, network, power, cooling facility가 존재하는 물리적 장소다.

Zone은 하나 이상의 data center 또는 독립 인프라 단위로 구성될 수 있다. Cloud 사용자 관점에서는 보통 물리 data center 자체보다 zone이라는 logical/failure-domain 단위로 resource를 배치한다.

구분	의미	운영 관점
Region	지리적 cloud location	사용자와 가까운 위치, data residency, latency 선택
Zone	region 안의 독립 failure domain	고가용성, 장애 격리, workload 분산
Data Center	실제 물리 facility	power, cooling, networking, physical hardware 위치

MZR이 필요한 이유

Production system은 하나의 VM이 실행되는 것만으로 충분하지 않다.

다음과 같은 구조를 생각해볼 수 있다.

Application server가 하나의 zone에만 있음
Database도 같은 zone에 있음
Load balancer도 같은 zone에 있음

이때 해당 zone에 장애가 발생하면 전체 서비스가 영향을 받는다.

Zone failure
  ↓
App server unavailable
Database unavailable
Load balancer unavailable
  ↓
Service outage

단일 zone에 모든 resource를 몰아두면 그 zone이 전체 서비스의 single point of failure가 된다.

MZR은 이 문제를 줄이기 위해 region 내부를 여러 zone으로 나누고, workload를 zone 간에 분산할 수 있게 한다.

Zone 1 failure
  ↓
Zone 2 and Zone 3 continue serving traffic
  ↓
Service remains available

MZR의 목표는 다음과 같다.

1. 하나의 zone 장애가 전체 region 장애로 번지지 않게 한다.
2. zone 간 latency를 낮게 유지한다.
3. 같은 region 안에서 high availability architecture를 만들 수 있게 한다.
4. regional service와 zonal resource를 조합해 production workload를 안정적으로 운영한다.

Single-Zone 구조의 한계

Single-zone deployment는 단순하고 비용이 낮을 수 있다.

Region A
└── Zone 1
    ├── Web Server
    ├── App Server
    └── Database

개발 환경, 테스트 환경, 중요도가 낮은 내부 서비스라면 이 구조도 충분할 수 있다. 하지만 production workload에서는 다음 위험이 있다.

위험	설명
Zone 장애	해당 zone 장애가 곧 전체 서비스 장애로 이어질 수 있음
Maintenance 영향	zone-level maintenance 또는 장애에 취약
Capacity 이슈	특정 zone의 resource 부족에 영향을 받음
Network 장애	zone 내부 network 문제에 취약
Storage 장애	zone-local storage만 쓰는 경우 복구 어려움
High availability 제한	active-active 또는 failover 구성이 어려움

Single-zone 구조는 단순하지만, 장애 격리와 고가용성 측면에서 한계가 있다.

MZR의 기본 구조

MZR은 하나의 region 안에 여러 zone을 둔다.

Multi-Zone Region
├── Zone 1
├── Zone 2
└── Zone 3

각 zone은 독립적인 failure domain이다.

Zone 1
├── independent power
├── independent cooling
└── independent network connectivity

Zone 2
├── independent power
├── independent cooling
└── independent network connectivity

Zone 3
├── independent power
├── independent cooling
└── independent network connectivity

이 구조에서 중요한 것은 zone 간 연결도이다. MZR은 같은 region 안에서 zone 간 low latency와 high bandwidth connectivity를 전제로 high availability architecture를 만들 수 있게 한다.

Zone 1
  ↕ low latency network
Zone 2
  ↕ low latency network
Zone 3

Fault Domain

MZR을 이해할 때 가장 중요한 개념이 fault domain이다.

Fault domain은 하나의 장애가 영향을 줄 수 있는 범위다.

하나의 rack에만 서버를 모두 넣으면 rack이 fault domain이다.

Rack failure
  ↓
All servers in rack unavailable

하나의 data center에만 모든 시스템을 넣으면 data center가 fault domain이다.

Data center failure
  ↓
All workloads in that data center unavailable

MZR에서는 zone이 중요한 fault domain이다.

Zone failure
  ↓
Only workloads in that zone affected

따라서 production architecture에서는 workload를 zone 간에 나눠야 한다.

App replicas:
Zone 1 + Zone 2 + Zone 3

Database replicas:
Zone 1 + Zone 2 + Zone 3

Load balancing:
Regional entrypoint across zones

핵심은 zone 하나가 사라져도 서비스가 계속 동작하도록 설계하는 것이다.

MZR이 자동으로 HA를 보장하지는 않는다

MZR이 있다고 해서 자동으로 애플리케이션이 고가용성이 되는 것은 아니다.

MZR은 고가용성 architecture를 만들 수 있는 인프라 조건을 제공한다. 하지만 실제 고가용성은 workload를 어떻게 배치하고, 어떤 서비스가 regional인지, 데이터 복제를 어떻게 하는지에 따라 달라진다.

잘못된 예시는 다음과 같다.

MZR region 사용
하지만 모든 VM을 Zone 1에만 배치

이 경우 이름은 MZR을 쓰지만 실제 구조는 single-zone과 크게 다르지 않다.

MZR
├── Zone 1
│   ├── App Server 1
│   ├── App Server 2
│   └── Database
├── Zone 2
│   └── empty
└── Zone 3
    └── empty

좋은 방향은 다음과 같다.

MZR
├── Zone 1
│   ├── App Server 1
│   └── DB Replica 1
├── Zone 2
│   ├── App Server 2
│   └── DB Replica 2
└── Zone 3
    ├── App Server 3
    └── DB Replica 3

즉 MZR은 설계 가능성을 제공하고, 실제 HA는 architecture가 완성한다.

MZR과 Availability Zone

Cloud provider마다 용어는 조금 다르지만, MZR에서 말하는 zone은 다른 cloud에서 흔히 Availability Zone이라고 부르는 개념과 비슷하다.

Availability Zone:
region 안의 독립적인 failure domain

Availability Zone의 핵심은 다음과 같다.

같은 region 안에 있음
하지만 power/cooling/network 장애가 독립적으로 격리되도록 설계됨
zone 간에는 low latency network로 연결됨

HA 설계에서는 다음 원칙을 사용한다.

Replica를 서로 다른 zone에 배치한다.
Load balancer를 regional하게 구성한다.
Database는 zone 간 replication을 사용한다.
Storage는 replication scope를 명확히 이해한다.
Monitoring과 alerting도 zone별로 본다.

MZR과 Latency

MZR은 여러 zone으로 나누어져 있지만, 같은 region 안에 있기 때문에 zone 간 latency가 낮아야 한다.

이 점이 multi-region과 다르다.

Multi-zone:
같은 region 안의 여러 zone
낮은 latency
고가용성 중심

Multi-region:
서로 다른 geographic region
latency가 더 큼
재해 복구, global service, data residency 중심

MZR은 다음 요구사항에 적합하다.

같은 도시권 또는 region 안에서
zone failure를 견디고 싶다.
하지만 latency는 낮게 유지하고 싶다.

MZR과 Multi-Region의 차이

MZR과 multi-region은 모두 resiliency를 높이는 방법이지만 목적과 trade-off가 다르다.

구분	MZR	Multi-Region
범위	하나의 region 안의 여러 zone	서로 다른 geographic region
주요 목적	zone-level high availability	regional disaster recovery, global service
latency	낮음	region 간 거리에 따라 높음
data consistency	상대적으로 강한 consistency 설계 가능	replication lag, consistency trade-off 커짐
운영 복잡도	중간	높음
장애 대응	zone 장애 대응	region 전체 장애 대응
대표 구조	active-active across zones	active-active 또는 active-passive across regions

MZR은 zone 장애에 대비하는 구조다.

Zone 1 down
  ↓
Zone 2, Zone 3 continue

Multi-region은 region 전체 장애에 대비한다.

Region A down
  ↓
Region B serves traffic

Production architecture에서는 계층적으로 생각할 수 있다.

기본 HA:
MZR 안에서 multi-zone deployment

DR 강화:
다른 region에 standby 또는 active-active 구성

MZR과 Disaster Recovery

DR(Disaster Recovery)은 더 큰 장애에 대비하는 계획이다.

MZR은 zone 장애에 강한 구조를 만드는 데 좋다. 하지만 하나의 region 전체에 문제가 생기는 경우에는 multi-region DR이 필요할 수 있다.

MZR:
zone failure 대응

Multi-region DR:
region failure 대응

예를 들어 다음과 같이 설계할 수 있다.

Primary Region: MZR
├── Zone 1
├── Zone 2
└── Zone 3

Secondary Region: MZR or SZR
└── standby workload

DR 설계에서는 다음 지표가 중요하다.

지표	의미
RTO	Recovery Time Objective. 장애 후 복구까지 허용되는 시간
RPO	Recovery Point Objective. 장애 시 손실 가능한 데이터 시간
Active-Active	여러 region 또는 zone이 동시에 traffic 처리
Active-Passive	primary 장애 시 standby로 failover
Backup/Restore	backup에서 복구하는 방식
Replication	데이터와 상태를 다른 위치로 지속 복제

MZR은 RTO/RPO를 줄이는 데 도움이 될 수 있지만, region 전체 장애까지 모두 해결하는 것은 아니다.

Zonal Resource와 Regional Resource

MZR 설계에서 중요한 구분은 zonal resource와 regional resource다.

Zonal Resource

Zonal resource는 특정 zone에 종속된 resource다.

예시는 다음과 같다.

VM instance in Zone 1
Zone-local disk
Subnet bound to Zone 1
Node pool in Zone 2

Zonal resource는 해당 zone 장애의 영향을 받을 수 있다.

Zone 1 down
  ↓
Zone 1 VM unavailable
Zone 1 disk unavailable

Regional Resource

Regional resource는 여러 zone을 포괄하거나 region 단위로 제공되는 resource다.

예시는 다음과 같다.

Regional Load Balancer
Regional Object Storage
Regional Managed Database
Regional DNS or traffic entrypoint

Regional resource는 내부적으로 multi-zone redundancy를 제공할 수 있다. 다만 provider와 service별로 실제 HA 보장 방식은 다를 수 있으므로 확인이 필요하다.

구분	의미	장애 영향
Zonal resource	특정 zone에 배치됨	해당 zone 장애에 영향
Regional resource	region 단위로 제공됨	내부적으로 multi-zone redundancy 가능
Global resource	여러 region 또는 global scope	provider 서비스 설계에 따라 다름

MZR을 제대로 쓰려면 application replica는 zone별로 분산하고, entrypoint나 managed service는 regional capability를 활용하는 방식으로 설계해야 한다.

Application 배치

가장 기본적인 web application을 MZR에 배치한다고 하자.

Web Application
├── Load Balancer
├── App Servers
└── Database

Single-zone 구조는 다음과 같다.

Zone 1
├── Load Balancer
├── App Server 1
├── App Server 2
└── Database

MZR 구조에서는 다음처럼 나눌 수 있다.

MZR
├── Zone 1
│   └── App Server 1
├── Zone 2
│   └── App Server 2
└── Zone 3
    └── App Server 3

Regional Load Balancer
└── Routes traffic to healthy app servers across zones

Traffic 흐름은 다음과 같다.

User
  ↓
DNS
  ↓
Regional Load Balancer
  ↓
Healthy App Server in Zone 1/2/3

Zone 1이 장애가 나면 load balancer는 Zone 2와 Zone 3의 healthy target으로 traffic을 보낼 수 있다.

Zone 1 failure
  ↓
App Server 1 unhealthy
  ↓
Load Balancer removes Zone 1 target
  ↓
Traffic goes to Zone 2 and Zone 3

Database 설계

Application server는 stateless하게 만들면 zone 간 분산이 비교적 쉽다. 하지만 database는 더 어렵다. 데이터는 state를 가지기 때문이다.

Database를 single-zone에만 두면 다음 문제가 생긴다.

App servers across zones
  ↓
Single DB in Zone 1
  ↓
Zone 1 failure
  ↓
Entire application unavailable

따라서 database는 다음 중 하나로 설계해야 한다.

1. Managed regional database 사용
2. Database cluster를 zone 간 replication
3. Primary-standby across zones
4. Quorum-based distributed database
5. Backup/restore 기반 DR

각 방식은 trade-off가 있다.

방식	장점	주의점
Managed regional DB	운영 부담 감소	provider의 HA 모델 확인 필요
Primary-standby	구조가 비교적 명확	failover 시간과 데이터 손실 가능성 확인
Multi-primary	active-active 가능	conflict resolution과 consistency 복잡도
Quorum DB	zone 장애에 강함	latency, quorum, 운영 복잡도
Backup/restore	비용 낮음	RTO/RPO가 길 수 있음

MZR에서 database를 설계할 때는 다음 질문이 중요하다.

Zone 하나가 사라져도 write가 가능한가?
read replica는 어느 zone에 있는가?
failover는 자동인가 수동인가?
RPO는 얼마인가?
RTO는 얼마인가?
application connection string은 failover를 따라가는가?

Kubernetes와 MZR

Kubernetes cluster를 MZR에 배치할 때도 zone 분산이 중요하다.

기본 구조는 다음과 같다.

MZR
├── Zone 1
│   └── Worker Node Pool A
├── Zone 2
│   └── Worker Node Pool B
└── Zone 3
    └── Worker Node Pool C

Pod replica는 zone 간에 분산해야 한다.

Deployment replicas: 3

Pod 1 → Zone 1
Pod 2 → Zone 2
Pod 3 → Zone 3

이를 위해 Kubernetes에서는 다음 개념이 중요하다.

node affinity
pod anti-affinity
topology spread constraints
PodDisruptionBudget
multi-zone node pool
Service type LoadBalancer
Ingress controller
storage class topology

좋은 방향은 다음과 같다.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule

이런 설정은 Pod가 특정 zone에 몰리지 않도록 도와준다.

반대로 모든 replica가 같은 zone에 배치되면 MZR의 이점을 거의 얻지 못한다.

MZR 사용
하지만 모든 pod가 Zone 1에 있음
  ↓
Zone 1 장애 시 서비스 장애

VPC Subnet 설계

VPC 환경에서는 subnet이 zone과 연결되는 경우가 많다. Multi-zone VPC를 설계하려면 zone별 subnet을 나누어야 한다.

VPC: 10.0.0.0/16

Zone 1
├── public-subnet-z1: 10.0.1.0/24
└── app-subnet-z1:    10.0.11.0/24

Zone 2
├── public-subnet-z2: 10.0.2.0/24
└── app-subnet-z2:    10.0.12.0/24

Zone 3
├── public-subnet-z3: 10.0.3.0/24
└── app-subnet-z3:    10.0.13.0/24

이런 구조를 사용하면 각 zone에 동일한 tier를 배치할 수 있다.

Zone 1:
public + app + db subnet

Zone 2:
public + app + db subnet

Zone 3:
public + app + db subnet

주의할 점은 subnet 이름만 다르고 실제 workload가 하나의 zone에 몰려 있으면 안 된다는 것이다.

Load Balancer 설계

MZR에서는 load balancer가 zone 간 traffic을 분산하는 핵심 entrypoint가 된다.

User
  ↓
Regional Load Balancer
  ↓
Zone 1 App Server
Zone 2 App Server
Zone 3 App Server

Load balancer는 보통 health check를 통해 각 zone의 backend 상태를 확인한다.

Health check:
Zone 1 app → unhealthy
Zone 2 app → healthy
Zone 3 app → healthy

이 경우 Zone 1 backend를 제외하고 나머지 zone으로 traffic을 보낼 수 있다.

Traffic
  ↓
Zone 2 + Zone 3

MZR에서 load balancer 설계 시 확인할 점은 다음이다.

확인 항목	질문
Scope	load balancer가 zonal인가 regional인가?
Health check	zone별 backend health를 감지하는가?
Failover	unhealthy zone을 자동 제외하는가?
Session	session persistence가 zone 장애 시 문제를 만들지 않는가?
Backend 분산	backend가 실제로 zone 간 분산되어 있는가?
TLS	certificate와 termination 위치가 적절한가?

Storage 설계

MZR 설계에서 storage는 매우 중요하다.

Compute는 쉽게 다른 zone에 replica를 둘 수 있지만, storage는 데이터 일관성과 복제 방식이 중요하다.

예를 들어 VM에 붙은 disk가 zone-local이면 해당 zone 장애 시 disk도 사용할 수 없을 수 있다.

Zone 1 VM
└── Zone-local disk

Zone 1 failure
  ↓
VM unavailable
Disk unavailable

Production workload에서는 storage의 replication scope를 확인해야 한다.

Zonal disk인가?
Regional replicated storage인가?
Object storage는 regional resilience를 제공하는가?
Database storage는 multi-zone replication을 지원하는가?
Backup은 다른 zone 또는 region에 있는가?

Storage 관련 설계 질문은 다음과 같다.

질문	이유
이 storage는 zonal인가 regional인가?	zone 장애 영향 범위 확인
synchronous replication인가 asynchronous replication인가?	RPO와 latency에 영향
failover는 자동인가?	장애 대응 시간에 영향
backup은 어디에 저장되는가?	region/zone 장애 시 복구 가능성
application이 storage failover를 감당하는가?	connection retry, consistency 문제

MZR을 사용해도 storage가 single-zone이면 전체 application availability가 그 storage에 묶일 수 있다.

Network 설계

MZR의 zone들은 low latency network로 연결된다. 하지만 zone 간 통신은 여전히 network를 사용한다.

따라서 다음을 고려해야 한다.

App → DB cross-zone latency
Service-to-service traffic path
Inter-zone bandwidth
Network ACL / Security Group
Routing table
Firewall policy
Load balancer path
DNS resolution

예를 들어 app server는 Zone 2에 있고 database primary는 Zone 1에만 있다면 모든 write traffic이 zone 간 이동한다.

Zone 2 App
  ↓ cross-zone traffic
Zone 1 DB

이 구조는 latency와 bandwidth 비용, 장애 영향을 고려해야 한다.

가능한 설계는 다음과 같다.

Read replica를 각 zone에 둔다.
Write primary failover를 지원한다.
Stateless app은 모든 zone에 둔다.
Stateful service는 replication topology를 명확히 설계한다.

Active-Active Architecture

MZR의 장점을 잘 활용하는 대표 구조는 active-active across zones다.

Zone 1: active
Zone 2: active
Zone 3: active

모든 zone이 평상시에도 traffic을 처리한다.

User traffic
  ↓
Regional Load Balancer
  ↓
Zone 1 / Zone 2 / Zone 3

장점	설명
Resource utilization	모든 zone resource를 평상시에도 사용
Fast failover	장애 zone만 제외하고 나머지 zone이 계속 처리
Capacity 분산	traffic을 zone별로 나눔
운영 검증	standby가 아니라 평상시 active이므로 항상 검증됨

단점도 있다.

단점	설명
데이터 일관성	stateful service 설계가 어려움
비용	여러 zone에 resource 배치 필요
운영 복잡도	deployment, monitoring, networking 복잡도 증가
장애 전파	shared dependency가 있으면 zone 분산 효과 감소

Active-active는 stateless service에는 적합하지만, database나 message queue 같은 stateful component는 더 신중하게 설계해야 한다.

Active-Passive Architecture

다른 방식은 active-passive다.

Zone 1: active
Zone 2: standby
Zone 3: standby or quorum

평상시에는 하나의 zone 또는 일부 zone이 traffic을 처리하고, 장애 시 standby zone으로 failover한다.

Zone 1 failure
  ↓
Zone 2 becomes active

장점은 구조가 비교적 단순하다는 것이다.

단점은 다음과 같다.

standby resource가 평상시에 덜 사용될 수 있음
failover 시간이 필요함
failover 절차를 자주 검증하지 않으면 실제 장애 때 실패할 수 있음
DNS, load balancer, database promotion이 맞물려야 함

MZR 안에서는 보통 stateless application은 active-active, database는 primary-standby 또는 quorum-based 구조로 가는 경우가 많다.

Quorum 기반 시스템

3-zone MZR이 중요한 이유 중 하나는 quorum 기반 시스템을 구성하기 좋다는 점이다.

분산 시스템에서 quorum은 과반수 동의를 의미한다.

3 nodes
  ↓
majority = 2

3개의 zone에 각각 하나씩 replica를 두면 한 zone이 장애 나도 나머지 두 zone이 quorum을 유지할 수 있다.

Zone 1: node A
Zone 2: node B
Zone 3: node C

Zone 1 failure
  ↓
Zone 2 + Zone 3 = quorum 유지

이 구조는 다음 시스템에서 중요하다.

distributed database
etcd
consensus system
message queue metadata
control plane
lock manager
configuration store

하지만 quorum system은 latency에도 민감하다. zone 간 latency가 너무 크면 write latency가 증가할 수 있다. MZR은 같은 region 안에서 zone 간 latency를 낮게 유지하도록 설계되기 때문에 quorum-based system에 적합한 기반이 될 수 있다.

Kubernetes Control Plane

Kubernetes control plane도 HA가 필요하다.

Control plane 구성 요소는 다음과 같다.

kube-apiserver
etcd
kube-controller-manager
kube-scheduler
cloud-controller-manager

특히 etcd는 quorum이 중요하다.

3-zone MZR에서는 control plane node 또는 etcd member를 zone 간 분산하는 구조를 생각할 수 있다.

Zone 1: etcd member 1
Zone 2: etcd member 2
Zone 3: etcd member 3

한 zone이 장애 나도 2개 member가 남아 quorum을 유지할 수 있다.

3-member etcd
  ↓
1 failure tolerated

단, 실제 managed Kubernetes에서는 provider가 control plane HA를 어떻게 제공하는지 확인해야 한다. 사용자가 worker node만 zone 분산하고 control plane은 provider-managed인 경우도 많다.

Cost Trade-off

MZR을 사용하면 availability는 높아지지만 비용과 복잡도도 증가한다.

항목	비용 또는 복잡도
Compute	각 zone에 replica 배치 필요
Storage	multi-zone replication 비용 발생 가능
Network	zone 간 traffic 비용 또는 bandwidth 고려
Load Balancer	regional LB, health check 비용
Database	HA cluster 또는 managed DB 비용
Monitoring	zone별 metric과 alerting 필요
Deployment	zone-aware rollout 필요
Testing	failover test와 chaos test 필요

모든 workload를 MZR active-active로 구성할 필요는 없다.

Workload	권장 구조
개인 개발 환경	single zone 가능
내부 테스트 서비스	single zone 또는 최소 HA
중요도가 낮은 batch job	single zone + retry 가능
사용자-facing web service	multi-zone 권장
결제, 인증, core API	multi-zone HA 강하게 권장
mission-critical workload	multi-zone + multi-region DR 검토

MZR 도입 시 설계 질문

MZR을 사용하려면 단순히 region을 선택하는 것에서 끝나면 안 된다. 다음 질문을 해야 한다.

1. 어떤 resource가 zonal이고 어떤 resource가 regional인가?
2. app replica는 zone 간에 분산되는가?
3. database는 zone 장애를 견디는가?
4. storage replication scope는 무엇인가?
5. load balancer는 regional하게 동작하는가?
6. health check는 zone failure를 감지하는가?
7. Kubernetes pod는 특정 zone에 몰리지 않는가?
8. deployment 중 한 zone씩 rollout할 수 있는가?
9. monitoring은 zone별로 분리되어 있는가?
10. 한 zone을 의도적으로 차단해도 service가 유지되는가?

이 질문에 답하지 못하면 MZR을 쓰고 있어도 실제로는 HA가 아닐 수 있다.

Troubleshooting 관점

MZR 환경에서 장애가 발생하면 “전체 장애인가, 특정 zone 장애인가?”를 먼저 구분해야 한다.

특정 zone에서만 서비스가 느린 경우

가능한 원인은 다음과 같다.

해당 zone의 app instance CPU saturation
zone-local network congestion
zone-specific storage latency
zone의 backend만 unhealthy
zone 간 DB traffic 증가
load balancer가 한 zone에 traffic을 과도하게 보냄

확인할 지표는 다음과 같다.

zone별 latency
zone별 5xx rate
zone별 pod restart count
zone별 node pressure
zone별 DB connection count
zone별 network throughput
load balancer target health

Zone 하나가 장애인데 전체 서비스가 죽는 경우

이 경우 MZR을 제대로 활용하지 못했을 가능성이 크다.

가능한 원인은 다음과 같다.

모든 pod가 같은 zone에 있었음
database primary가 장애 zone에만 있었음
storage가 single-zone이었음
load balancer가 다른 zone backend를 가지고 있지 않았음
DNS가 zonal endpoint만 가리켰음
shared dependency가 single-zone이었음
control plane dependency가 장애 zone에 있었음

확인할 항목은 다음과 같다.

workload placement
storage topology
database HA
load balancer target distribution
dependency map
DNS endpoint
zone-aware policy

Multi-zone인데 latency가 높아진 경우

가능한 원인은 다음과 같다.

app과 DB가 서로 다른 zone에만 배치됨
cross-zone traffic이 증가함
zone-local cache hit ratio가 낮음
database leader가 특정 zone에 집중됨
service mesh routing이 zone locality를 고려하지 않음

개선 방향은 다음과 같다.

zone-local routing 우선
read replica zone 분산
cache를 zone별로 warm
leader placement 검토
cross-zone call 최소화

DevOps 관점에서 보는 MZR

MZR은 단순한 cloud location 개념이 아니라 deployment와 operation 전략에 직접 영향을 준다.

DevOps 관점에서는 다음이 중요하다.

zone-aware deployment
topology-aware scheduling
rolling update by zone
blue-green 또는 canary by zone
zone-level monitoring
failover automation
chaos engineering
infrastructure as code
disaster recovery runbook

예를 들어 deployment를 할 때 모든 zone에 동시에 새 버전을 배포하면 문제가 생겼을 때 전체 서비스가 영향을 받을 수 있다.

더 안전한 방식은 다음과 같다.

1. Zone 1에 canary 배포
2. metric 확인
3. Zone 2로 확대
4. metric 확인
5. Zone 3까지 rollout

이렇게 하면 zone을 rollout boundary로 사용할 수 있다.

앞선 네트워킹 개념들과의 연결

VPC

VPC는 MZR 안에서 zone별 subnet을 구성할 수 있다.

VPC
├── Zone 1 subnet
├── Zone 2 subnet
└── Zone 3 subnet

MZR을 제대로 활용하려면 VPC subnet, route table, security group, ACL을 zone-aware하게 설계해야 한다.

Load Balancer

Load balancer는 MZR 안에서 zone 간 traffic 분산과 failover의 중심이 된다.

Regional Load Balancer
  ↓
Zone 1 backend
Zone 2 backend
Zone 3 backend

DNS

DNS는 사용자를 regional endpoint 또는 global traffic manager로 안내한다.

app.example.com
  ↓
regional endpoint
  ↓
MZR load balancer

Multi-region DR까지 고려하면 DNS 또는 global traffic manager가 region-level failover를 담당할 수 있다.

CDN

CDN은 user-facing edge 계층이고, MZR은 origin region 내부의 availability 계층이다.

User
  ↓
CDN Edge
  ↓
MZR Load Balancer
  ↓
Multi-zone App

CDN은 edge delivery를 빠르게 하고, MZR은 origin workload의 zone failure를 견디게 한다.

NAT와 Firewall

Zone별 subnet이 있으면 NAT gateway, firewall, public gateway 같은 egress/ingress 구성도 zone-aware하게 봐야 한다.

Zone 1 app → Zone 1 egress path
Zone 2 app → Zone 2 egress path
Zone 3 app → Zone 3 egress path

하나의 zone에만 NAT gateway가 있으면 해당 zone 장애 시 egress가 끊길 수 있다.

Kubernetes

Kubernetes에서 MZR은 topology.kubernetes.io/zone 같은 label과 연결된다.

Pod spread
Node pool per zone
Persistent volume topology
Ingress/LB target distribution
PodDisruptionBudget

MZR을 제대로 활용하려면 Kubernetes scheduler와 storage class가 zone topology를 반영해야 한다.

자칫 실수하기 쉬운 부분

실수	문제
MZR region만 선택하면 자동으로 HA라고 생각	workload를 zone 간 분산하지 않으면 single-zone과 큰 차이 없음
모든 replica가 같은 zone에 배치됨	해당 zone 장애 시 전체 service outage
database를 single-zone에 둠	app이 multi-zone이어도 DB 장애로 전체 장애 발생
storage replication scope 미확인	zone-local disk가 SPOF가 될 수 있음
regional LB가 아닌 zonal endpoint만 사용	zone 장애 시 entrypoint가 사라질 수 있음
NAT/egress를 한 zone에만 구성	특정 zone 장애가 전체 outbound 장애로 이어질 수 있음
Kubernetes topology spread 미설정	pod가 특정 zone에 몰릴 수 있음
zone별 monitoring 부재	특정 zone 장애를 전체 장애처럼 오해하거나 늦게 감지
failover test를 하지 않음	실제 장애 때 runbook이나 automation이 실패할 수 있음

정리

MZR은 하나의 cloud region 안에 여러 독립적인 zone을 구성해 단일 zone 장애가 전체 서비스 장애로 번지지 않도록 하는 high availability architecture의 기반이다.

항목	정리
MZR	하나의 region 안에 여러 zone을 둔 구조
Region	큰 지리적 cloud location
Zone	region 안의 독립 failure domain
Data Center	실제 물리 facility
핵심 목적	zone failure를 견디는 high availability
MZR vs Multi-region	MZR은 zone-level HA, multi-region은 region-level DR
Zonal resource	특정 zone에 종속된 resource
Regional resource	region 단위로 제공되는 resource
Application 설계	replica를 zone 간 분산
Database 설계	zone 간 replication, failover, quorum 고려
Kubernetes 설계	topology spread, node pool, storage topology 고려
운영 핵심	zone-aware monitoring, rollout, failover test

MZR의 실제 효과를 얻으려면 application, database, storage, load balancer, Kubernetes scheduling, network egress까지 모두 zone-aware하게 설계해야 한다. MZR은 고가용성을 위한 인프라 기반을 제공하지만, 실제 availability는 그 위에 올라가는 architecture와 운영 절차가 결정한다.