서버, DB, 로드밸런서를 모두 같은 가용영역(AZ)에 띄워 두면, 그 데이터센터 한 곳에 정전이나 네트워크 장애가 나는 순간 서비스 전체가 함께 죽습니다. 클라우드를 쓴다고 자동으로 고가용성이 되는 게 아니라, 여러 AZ에 자원을 나눠 배치해야 비로소 한 곳의 장애를 견딥니다. 가용영역 설계는 이 장애 격리 경계를 어떻게 그을지 정하는 일입니다.
리전과 AZ, 무엇이 다른가
| 개념 | 범위 | 격리 수준 | 지연 |
|---|---|---|---|
| 리전(Region) | 지리적 권역(서울, 도쿄 등) | 완전 독립 | 리전 간 수십 ms |
| 가용영역(AZ) | 리전 내 물리적으로 분리된 데이터센터 묶음 | 전력·냉각·네트워크 독립 | AZ 간 1ms 안팎 |
한 리전은 보통 2개 이상의 AZ로 구성됩니다. AZ끼리는 전력·냉각·네트워크가 물리적으로 분리돼 한 AZ가 죽어도 다른 AZ는 영향받지 않으면서, 서로 가까워 지연이 매우 낮아 동기 복제가 가능합니다. 리전 간은 지연이 커서 평소 운영보다 재해 복구(DR) 용도로 씁니다.
멀티 AZ 적용 단계
- 컴퓨트를 여러 AZ에 분산합니다. 오토스케일링 그룹을 두 개 이상의 AZ 서브넷에 걸쳐 두고, 로드밸런서가 AZ 전반으로 트래픽을 분배하게 합니다.
로컬 터미널
# 오토스케일링 그룹을 두 AZ 서브넷에 걸침
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name shop-asg \
--vpc-zone-identifier "subnet-aaa-2a,subnet-bbb-2c"
- DB를 멀티 AZ로 둡니다. RDS는 다른 AZ에 동기 복제 대기(standby)를 두고, 주 인스턴스 장애 시 자동으로 failover합니다.
- 로드밸런서는 기본적으로 여러 AZ에 걸쳐 동작하므로, 대상 그룹에 각 AZ의 인스턴스가 모두 등록됐는지 확인합니다.
- AZ 하나를 의도적으로 내려 보는 장애 주입으로 실제로 살아남는지 검증합니다. 설정만 해두고 시험하지 않으면 정작 장애 때 동작을 보장할 수 없습니다.
흔한 함정
겉으론 멀티 AZ인데 상태가 한 AZ에 묶여 있어 무의미한 경우가 많습니다. 예를 들어 웹 서버는 두 AZ에 분산했지만 세션을 특정 AZ의 단일 캐시 노드에 저장하면, 그 AZ가 죽을 때 전원이 로그아웃됩니다. 데이터·세션·캐시도 함께 다중화하거나 외부 관리형 저장소에 두어야 합니다.
또 한 가지, AZ 간 데이터 전송에는 비용이 붙습니다. 무조건 모든 트래픽을 교차시키기보다, 지연·비용·가용성의 균형을 보고 같은 AZ 내 통신을 우선하는 설정을 검토합니다.
요점 정리
- AZ는 리전 내 물리적으로 분리된 장애 격리 경계, 리전은 지리적 권역이다.
- 컴퓨트·DB·세션을 모두 여러 AZ에 분산해야 한 곳의 장애를 견딘다.
- 멀티 AZ는 장애 주입으로 실제 failover를 검증해야 의미가 있다.
- 상태가 단일 AZ에 묶이지 않게 하고, AZ 간 전송 비용도 함께 본다.
멀티 AZ 구성과 failover를 직접 띄워 검증해 보는 실습은 클라우드 트랙에서 회원가입 없이 무료로 해볼 수 있습니다.