[클라우드 활용] 12주차

1. 고가용성(High Availability)이란?

**고가용성(HA)**은 서비스를 가능한 한 오랫동안 중단 없이 지속적으로 제공하는 능력이다.

• 장애가 발생해도 빠르게 복구하거나 자동으로 우회하여 서비스 지속성을 유지하는 것이 목표
• 단순히 "서버가 켜져 있다"는 의미가 아니라, 장애 상황에서도 서비스가 살아있는 상태를 뜻함

가용성 수준별 중단 시간 (1년 기준)

가용성 연간 중단 시간 비고

99%	약 87시간	다소 자주 중단될 수 있음
99.9%	약 8시간 45분	일반 중소 서비스 수준
99.99%	약 52분	AWS 권장 수준
99.999%	약 5분	금융, 헬스케어 등 민감 시스템

---

2. AWS 리전과 가용 영역(AZ)의 관계

구성 요소

구성요소 특징

AZ (Availability Zone)	독립된 전원, 냉각, 보안 시스템 보유
AZ 간 네트워크	짧은 지연 시간(초고속 저지연)
장애 격리	AZ 하나에 장애가 나도 다른 AZ는 영향 없음

• 리전(Region): 지리적으로 분리된 데이터센터 클러스터 (예: ap-northeast-2 = 서울 리전)
• AZ: 리전 내 물리적으로 분리된 데이터센터 (서울 리전에는 4개의 AZ 존재)
• AZ 간에는 물리적으로 분리되어 있어 한 AZ에 화재나 전력 장애가 발생해도 다른 AZ는 정상 운영

---

3. 멀티 AZ 배포

멀티 AZ 배포란 두 개 이상의 가용 영역에 애플리케이션 구성 요소를 복제·이중화하여, 장애 시에도 서비스를 유지하도록 설계하는 방식이다.

주요 서비스별 멀티 AZ 지원

서비스 멀티 AZ 기능 설명

RDS Multi-AZ	자동 장애 조치(Failover) 지원	주 인스턴스 장애 시 대기 인스턴스 자동 승격
EC2 + Auto Scaling + ALB	AZ 간 인스턴스 분산 배포	부하에 따라 자동 확장·축소
EFS	AZ 간 고가용성 파일 스토리지	파일 시스템의 이중화
Elastic Load Balancer	트래픽을 AZ별로 자동 분산	헬스 체크 기반 라우팅

멀티 AZ 아키텍처 예시

AWS Cloud (ap-northeast-2)
├── VPC (10.10.0.0/16)
│   ├── Public Subnet 1 (AZ-a)  ── Internet Gateway
│   ├── Public Subnet 2 (AZ-c)  ── NAT Gateway
│   ├── Private Subnet 1 (10.10.21.0/24, AZ-a)
│   │     └── EC2 Instance (Web/App Server)
│   └── Private Subnet 2 (10.10.22.0/24, AZ-c)
│         └── EC2 Instance (Web/App Server)
│
├── Application Load Balancer (AZ 간 트래픽 분산)
├── Auto Scaling Group (CPU 기준 자동 확장)
├── RDS DB (Master, AZ-a) ↔ RDS DB (Standby, AZ-c)

멀티 AZ 설계 체크리스트

• [ ] 최소 2개 AZ에 배포했는가?
• [ ] AZ 장애 시 자동 장애 조치(Failover)가 구성되었는가?
• [ ] 상태 확인(Health Check)과 트래픽 우회 설정이 되어 있는가?
• [ ] 리소스 확장이 자동화되어 있는가?

---

4. ELB(Elastic Load Balancer) 개요

ELB는 들어오는 트래픽을 여러 서버로 자동 분산하는 AWS 관리형 로드밸런서 서비스다.

ELB가 해결하는 문제

문제 상황 해결 방법

서버 한 대에 트래픽 집중 → 과부하	트래픽을 여러 서버로 나눔
하나의 서버 다운 → 전체 중단	헬스 체크 + 다른 서버로 트래픽 전환
트래픽 변동이 클 때 수동 확장 어려움	Auto Scaling + ELB 연동

Target Group

ELB는 Target Group을 통해 트래픽을 전달할 대상(EC2, Lambda 등)을 관리한다.

• EC2 Auto Scaling Group(ASG) 생성 시 Target Group 지정
• ASG가 인스턴스를 생성할 때 해당 인스턴스를 Target Group에 자동 등록
• ELB는 Target Group 내 인스턴스의 헬스 체크 결과에 따라 트래픽 라우팅

---

5. ELB 유형 비교

유형 계층 주요 특징 사용 사례

ALB (Application LB)	L7 (애플리케이션)	경로·호스트 기반 라우팅, HTTP/HTTPS 지원	웹 앱, REST API, 마이크로서비스
NLB (Network LB)	L4 (전송)	초고속 처리, 고정 IP 지원, TCP/UDP	실시간 게임, 금융 서비스
CLB (Classic LB)	L4/L7 (구형)	EC2-Classic 전용, 레거시	기존 레거시 시스템 유지

• ALB: URL 경로(/api/*, /static/*)나 호스트 헤더(api.example.com, web.example.com)로 다른 Target Group에 라우팅 가능
• NLB: 극히 낮은 지연 시간과 수백만 RPS 처리 능력, 고정 IP 주소 제공

---

6. 헬스 체크(Health Check) 동작 원리

헬스 체크는 ELB가 각 인스턴스의 상태를 주기적으로 확인하여, 정상적인 인스턴스에만 트래픽을 전달하도록 하는 기능이다.

동작 흐름

1. ELB가 각 인스턴스에 주기적으로 HTTP 요청 또는 TCP 연결 시도
2. 응답 상태 코드나 연결 여부 확인
3. 응답 실패가 일정 횟수 이상 지속되면 "Unhealthy" 상태로 전환
4. 해당 인스턴스는 트래픽 대상에서 자동 제외
5. 다시 회복되면 자동으로 "Healthy"로 복귀

헬스 체크 설정 예시

항목 설정값

경로	/health 또는 /index.html
프로토콜	HTTP / HTTPS / TCP
정상 응답 코드	200, 302 등
확인 간격	30초
실패 허용 횟수	3회
성공 필요 횟수	2회

헬스 체크 모범 사례

• 애플리케이션 내부에 /health 전용 API 엔드포인트 구현
• 헬스 체크 실패 시 Auto Scaling 그룹과 연동하여 자동으로 인스턴스 교체
• 정상 상태만 "트래픽 대상(Target)"으로 유지 → 장애 격리 효과

---

7. 고가용성 아키텍처 실습 시나리오

장애 복구 흐름 확인

1. AZ-a의 EC2 인스턴스를 강제로 중단
2. ELB의 헬스 체크가 해당 인스턴스를 Unhealthy로 감지
3. 트래픽이 AZ-c의 EC2 인스턴스로 자동 전환
4. 서비스 중단 없이 요청 처리 지속
5. AZ-a 인스턴스 복구 후 자동으로 Healthy 상태 복귀 및 트래픽 재분산

---

8. 학습 정리

• 멀티 AZ 구성은 서비스의 중단 가능성을 줄이기 위한 핵심 전략이다.
• 여러 가용 영역에 리소스를 분산해두면, 하나가 장애 나더라도 서비스가 지속된다.
• ELB는 ALB(L7)·NLB(L4)·CLB 세 가지 유형이 있으며, 서비스 특성에 맞게 선택해야 한다.
• 헬스 체크와 자동 장애 복구 흐름을 이해하면 고가용성 설계가 실무에서도 자연스럽게 적용된다.

---

다음 주차 예고: 13주차에서는 AWS 클라우드 보안 실무 사례를 분석한다.