AWS Certified Solutions Architect - Associate (SAA-C03) #6 Domain 2-1 회복력 있는 아키텍처: Multi-AZ,Auto Scaling,ELB
#5로 보안 도메인(30%)을 마쳤습니다. 이제 두 번째 도메인인 **회복력(Resilience, 26%)**으로 들어갑니다. 회복력의 첫 질문은 단순합니다. “인스턴스 하나가, 또는 데이터센터 하나가 죽어도 서비스가 계속되는가.” 그 답의 토대가 Multi-AZ 배치, Auto Scaling, 그리고 로드 밸런서입니다.
가용 영역(AZ)과 고가용성 #
리전(Region)은 여러 개의 **가용 영역(Availability Zone, AZ)**으로 구성됩니다. 각 AZ는 물리적으로 분리된 하나 이상의 데이터센터이며, 전력,냉각,네트워크가 독립적입니다. 한 AZ에 장애가 나도 다른 AZ는 영향을 받지 않습니다.
고가용성 설계의 기본 원칙은 **“리소스를 여러 AZ에 분산”**하는 것입니다. 단일 AZ에만 인스턴스를 두면 그 AZ 장애 시 서비스가 멈춥니다. 시험에서 “고가용성"이라는 단어가 나오면 거의 항상 Multi-AZ 배치가 답의 일부입니다.
Multi-AZ(여러 AZ)와 Multi-Region(여러 리전)을 구분하세요. 대부분의 고가용성은 Multi-AZ로 충분하며, Multi-Region은 리전 전체 장애 대비나 글로벌 지연 시간 개선을 위한 별도 주제입니다(#7 DR에서 다룹니다).
Auto Scaling 그룹(ASG) #
Auto Scaling 그룹은 EC2 인스턴스 수를 수요에 맞춰 자동으로 늘리고 줄이는 단위입니다. 회복력과 비용 효율을 동시에 잡는 핵심 구성요소입니다.
구성 #
- 시작 템플릿(Launch Template). 어떤 AMI,인스턴스 타입,보안 그룹으로 인스턴스를 띄울지 정의
- 용량 설정. 최소(min) / 최대(max) / 희망(desired) 인스턴스 수
- 여러 AZ에 분산. ASG는 지정한 서브넷(AZ)에 인스턴스를 고르게 분산하고, 불균형이 생기면 재조정합니다
스케일링 정책 #
| 정책 | 동작 | 대표 용도 |
|---|---|---|
| Target Tracking | 지표를 목표값으로 유지(예: CPU 50%) | 가장 일반적,권장 |
| Step Scaling | 지표 구간별로 단계적 증감 | 세밀한 제어 |
| Simple Scaling | 임계치 초과 시 정해진 수만큼 | 단순 케이스 |
| Scheduled Scaling | 정해진 시각에 미리 조정 | 예측 가능한 트래픽(업무 시간) |
| Predictive Scaling | 과거 패턴으로 미래 수요 예측 | 주기적 패턴 |
“트래픽이 늘면 자동으로 인스턴스를 추가하라"는 가장 흔한 요구사항은 Target Tracking으로 답합니다. “매일 오전 9시에 트래픽이 급증한다"처럼 시간을 알 수 있으면 Scheduled Scaling입니다.
헬스 체크로 장애 인스턴스 교체 #
ASG는 헬스 체크로 비정상 인스턴스를 감지해 종료하고 새 인스턴스로 교체합니다. 헬스 체크 종류는 두 가지입니다.
- EC2 헬스 체크. 인스턴스 상태(시스템/인스턴스 status check)만 봅니다.
- ELB 헬스 체크. 로드 밸런서가 애플리케이션 레벨(예: HTTP 200)로 검사합니다. 인스턴스는 살아 있어도 앱이 죽은 경우를 잡으려면 ELB 헬스 체크를 켜야 합니다.
Elastic Load Balancing(ELB) #
ELB는 트래픽을 여러 인스턴스(또는 컨테이너,Lambda)에 분산하고, 헬스 체크로 정상 대상에만 보냅니다. 세 종류가 있으며 계층과 용도로 구분합니다.
| 종류 | 계층 | 프로토콜 | 특징 |
|---|---|---|---|
| ALB (Application) | L7 | HTTP/HTTPS | 경로,호스트 기반 라우팅, 컨테이너,Lambda 대상, WebSocket |
| NLB (Network) | L4 | TCP/UDP/TLS | 초고성능,초저지연, 고정 IP(Elastic IP) |
| GLB (Gateway) | L3 | IP | 서드파티 가상 어플라이언스(방화벽,IDS) 배포,확장 |
- ALB. HTTP 경로(
/api,/img)나 호스트 헤더로 다른 대상 그룹에 라우팅해야 하면 ALB입니다. 마이크로서비스,컨테이너 환경의 기본 선택입니다. - NLB. 수백만 RPS, 초저지연, TCP/UDP, 또는 고정 IP가 필요하면 NLB입니다. ALB는 고정 IP가 없고 DNS 이름으로만 노출됩니다.
- GLB. 트래픽을 방화벽 같은 서드파티 어플라이언스로 통과시켜야 할 때 씁니다.
알아둘 ELB 기능 #
- SSL/TLS 종료. 로드 밸런서에서 인증서를 처리(ACM 연동)
- 스티키 세션. 같은 클라이언트를 같은 대상으로 고정
- 교차 영역 부하 분산(Cross-Zone). 모든 AZ의 대상에 고르게 분산. ALB는 기본 활성, NLB는 기본 비활성
- 연결 드레이닝(Deregistration Delay). 대상을 빼기 전 진행 중 요청을 마치도록 대기
함께 동작하는 그림 #
전형적인 고가용성 웹 계층은 이렇게 묶입니다.
- 여러 AZ에 걸친 서브넷
- 앞단에 ALB(트래픽 분산 + 헬스 체크)
- 그 뒤에 Auto Scaling 그룹(수요에 따라 증감, 장애 인스턴스 교체)
이 조합이면 인스턴스 장애는 ASG가, AZ 장애는 다중 AZ 분산이, 트래픽 급증은 스케일링이 흡수합니다.
시험 출제 패턴 #
- “HTTP 경로/호스트 기반 라우팅.” → ALB
- “초고성능 TCP 또는 고정 IP 필요.” → NLB
- “서드파티 방화벽 어플라이언스 삽입.” → GLB
- “트래픽에 따라 EC2 자동 증감.” → ASG + Target Tracking
- “매일 특정 시각 트래픽 급증 대비.” → Scheduled Scaling
- “인스턴스는 살아 있지만 앱이 죽은 경우 교체.” → ELB 헬스 체크 사용
- “고가용성이 요구된다.” → 여러 AZ 분산 + ELB + ASG
자주 만나는 함정 #
1) ALB에 고정 IP가 있다고 생각 #
고정 IP(Elastic IP)는 NLB의 특징입니다. ALB는 DNS 이름으로만 노출됩니다.
2) Auto Scaling을 수직 확장으로 오해 #
ASG는 수평 확장(인스턴스 수 증감)입니다. 인스턴스를 더 큰 타입으로 바꾸는 수직 확장과 다릅니다.
3) EC2 헬스 체크로 앱 장애를 잡으려 한다 #
EC2 헬스 체크는 인스턴스 상태만 봅니다. 애플리케이션 레벨 장애는 ELB 헬스 체크로 감지합니다.
4) 고가용성과 Multi-Region을 혼동 #
대부분의 고가용성은 Multi-AZ로 해결합니다. Multi-Region은 리전 장애 대비,글로벌 지연 개선용으로 비용이 큽니다.
정리 #
이번 글에서 잡은 것:
- 고가용성의 토대는 여러 AZ 분산. Multi-AZ와 Multi-Region을 구분
- Auto Scaling. 수평 증감. Target Tracking이 기본, 시간 예측은 Scheduled. 헬스 체크로 장애 인스턴스 교체
- ELB. ALB(L7 경로 라우팅) , NLB(L4 초고성능,고정 IP) , GLB(어플라이언스)
- 앱 장애 감지는 ELB 헬스 체크. 교차 영역 분산은 ALB 기본 활성/NLB 기본 비활성
- 표준 패턴. 다중 AZ + ALB + ASG의 조합
다음: Domain 2-2 DR 패턴 #
단일 리전 안의 회복력을 잡았으니, 다음은 리전 단위 재해에 대비하는 DR 전략입니다.
#7 Domain 2-2 DR 패턴에서는 RTO와 RPO의 의미, 네 가지 DR 전략(Backup & Restore , Pilot Light , Warm Standby , Multi-Site Active/Active)의 비용,복구 시간 트레이드오프, 그리고 Route 53 failover와 교차 리전 복제로 구현하는 방법을 정리하겠습니다.