이번 주차는 single point of failure를 제거하는 고가용성 설계가 주제다. 멀티 AZ에 인스턴스를 분산하고, ELB로 트래픽을 분배하면서 health check로 장애 인스턴스를 자동 우회시킨다. 콘솔에서 EC2 2개를 서로 다른 AZ에 배포하고, ALB에 붙인 뒤 한 대를 죽여서 failover를 직접 확인하는 흐름까지 다룬다.
1. 고가용성(HA)의 개념
고가용성은 서비스를 중단 없이 지속 제공하는 능력이다. 장애가 나도 빠르게 복구하거나 자동으로 우회해서 서비스 지속성을 유지하는 게 목표다.
핵심은 가용성을 "몇 개의 9"로 측정한다는 점이다. 9가 하나 늘어날 때마다 허용 가능한 연간 다운타임이 한 자릿수씩 줄어든다.
가용성
연간 중단 시간
수준
99%
약 87시간
자주 중단될 수 있음
99.9%
약 8시간 45분
일반 중소 서비스
99.99%
약 52분
AWS 권장 수준
99.999%
약 5분
금융, 헬스케어 등 민감 시스템
고가용성이 깨지면 매출 손실, 브랜드 신뢰 하락, SLA 위반 시 손해배상까지 이어진다. 그래서 단순 기능 구현이 아니라 비용·법적 리스크 관점의 문제다.
고가용성 아키텍처 핵심 원리
SPOF(Single Point of Failure) 제거: 모든 기능을 "장애가 난다"는 가정하에 역방향으로 설계
다중 리전 / 다중 AZ 사용
자동 복구 메커니즘 구축 (health check 실패 시 자동 교체)
트래픽 분산 및 장애 감지 후 우회
인프라 자동화 (Auto Scaling, ELB)
💡 개념에서 느낀 점
"가능한 모든 지점에서 중복성을 구현"이라는 원칙이 핵심인데, 실제로는 비용과의 trade-off다. 99.999%를 위해 5중화하는 건 대부분의 서비스에 과한 설계다. 우리 서비스가 9 몇 개가 필요한지를 먼저 정의하고 거기 맞춰 중복도를 정하는 게 순서다.
"역방향 설계(장애가 난다고 가정)"는 chaos engineering의 출발점과 같은 사고방식이다. 정상 흐름이 아니라 깨지는 지점부터 그린다는 발상이 인상적이었다.
2. AWS 리전과 가용 영역(AZ)의 관계
리전은 전 세계에 배치된 AWS의 지리적 물리 인프라 단위이고, 각 리전은 서로 완전히 격리되어 있다. (예: 서울 ap-northeast-2, 도쿄 ap-northeast-1, 오하이오 us-east-2)
하나의 리전은 3개 이상의 AZ로 구성된다. AZ는 물리적으로 분리된 데이터센터지만 고속·저지연 네트워크로 연결되어 있다.
구성요소
특징
AZ
독립된 전원, 냉각, 보안 시스템 보유
AZ 간 네트워크
짧은 지연 시간 (초고속 저지연)
장애 격리
AZ 하나에 장애가 나도 다른 AZ는 영향 없음
AZ를 나눠 쓰는 이유는 물리적 장애(지진, 정전, 화재) 분산, 고가용성 확보, 무중단 배포·확장이다.
💡 리전/AZ 개념에서 느낀 점
리전이 "완전히 격리"되어 있다는 건 양날의 검이다. 장애 격리에는 좋지만, 리전 간 리소스 복제는 별도 작업(cross-region replication)이 필요하다. EC2 인스턴스가 리전별로 분리되는 것과 같은 맥락이다.
AZ가 "물리적으로 분리됐지만 저지연 연결"이라는 점이 멀티 AZ RDS의 동기 복제(synchronous replication)를 가능하게 하는 전제다. 만약 AZ 간 latency가 컸다면 동기 복제로 인한 write 지연이 심각했을 것이다. 격리와 저지연을 동시에 잡은 설계라는 게 와닿았다.
3. 멀티 AZ 배포
멀티 AZ 배포는 2개 이상의 AZ에 애플리케이션 구성 요소를 복제·이중화해서 장애 시에도 서비스를 유지하는 방식이다.
주요 서비스별 멀티 AZ 동작은 이렇게 갈린다.
서비스
멀티 AZ 기능
설명
RDS
Multi-AZ 배포
자동 failover 지원 (master → standby)
EC2
Auto Scaling + ALB
AZ 간 인스턴스 분산 배포
EFS
AZ 간 고가용성
파일 스토리지 이중화
ELB
트래픽 AZ별 자동 분산
-
전형적인 멀티 AZ 아키텍처는 다음 구조다.
EC2는 각 AZ에 분산 배치
RDS는 master + standby를 다른 AZ에 배치
ELB는 정상 인스턴스로만 트래픽 라우팅
Auto Scaling Group이 CPU 사용량 등을 기준으로 인스턴스 수 자동 조절
고가용성 구성 체크리스트
최소 2개 AZ에 배포했는가?
AZ 장애 시 자동 failover가 구성되었는가?
health check + 트래픽 우회 설정이 되어 있는가?
리소스 확장이 자동화되어 있는가?
💡 멀티 AZ 개념에서 느낀 점
RDS Multi-AZ는 standby가 읽기 트래픽을 받지 않는다는 점을 짚고 넘어가야 한다. standby는 순수하게 failover 대기용이고, read 부하 분산을 원하면 별도로 Read Replica를 둬야 한다. Multi-AZ ≠ Read Replica인데 처음엔 둘을 헷갈렸다.
EC2는 Auto Scaling으로 "분산"하지만 RDS는 "이중화(master/standby)"로 접근한다. stateless한 웹 서버와 stateful한 DB의 HA 전략이 근본적으로 다르다는 게 표에서 명확히 드러난다.
4. ELB와 로드밸런서 개념
로드밸런서는 여러 서버로 들어오는 트래픽을 자동 분산하는 장치/서비스다. 한 서버에 부하가 집중되지 않게 해서 성능을 높이고 서비스 중단을 방지한다.
ELB(Elastic Load Balancing)는 수신 트래픽을 여러 EC2 인스턴스, 컨테이너, IP 주소에 걸쳐 분산하는 완전 관리형 로드밸런싱 서비스다.
로드밸런서가 해결하는 문제는 명확하다.
문제 상황
해결 방법
서버 한 대에 트래픽 집중 → 과부하
트래픽을 여러 서버로 분산
하나의 서버 다운 → 전체 중단
health check + 다른 서버로 전환
트래픽 변동 클 때 수동 확장 어려움
Auto Scaling + ELB 연동
ELB 핵심 기능
HTTP, HTTPS, TCP, UDP, SSL 프로토콜 지원
외부(internet-facing) 또는 내부(internal) 배치 가능
단일/다중 AZ의 여러 대상에 자동 분산
health check로 인스턴스 가용성 주기 확인
VPC 내에서 security group으로 네트워크 보안 제어
SSL termination (인증서 중앙 관리 + 애플리케이션의 CPU 부하 오프로드)
L4 또는 L7 로드밸런싱 선택
ELB와 Auto Scaling 연동
ELB와 ASG는 Target Group을 매개로 연결된다.
Target Group: 로드밸런서가 트래픽을 전달할 대상 그룹 (EC2, Lambda, IP)
ASG 생성 시 Target Group을 지정 → ASG가 인스턴스를 띄울 때 자동으로 Target Group에 등록
ASG 핵심 파라미터는 세 개다.
Desired capacity: 처음 시작되는 인스턴스 개수
Minimum size: scale-in 시에도 유지되는 최소 개수
Maximum size: scale-out 시 늘어나는 최대 개수
조정 정책(예: CPU 60% 이상이면 인스턴스 추가)과 시작 템플릿(Instance Type, AMI, SG, user data, EBS 등)을 함께 정의한다.
💡 ELB 개념에서 느낀 점
ELB가 Target Group을 통해 ASG와 연결된다는 구조가 핵심이다. 직접 인스턴스를 ELB에 등록하는 게 아니라, ASG가 인스턴스를 생성/삭제할 때 Target Group에 자동 등록/해제된다. 즉 scaling과 load balancing의 결합점이 Target Group이다.
SSL termination을 ELB에서 처리하면 인스턴스는 평문 HTTP만 다루면 된다. 인증서 갱신을 ELB 한 곳에서만 관리하면 되니 운영 부담이 확 줄어든다. 다만 ELB→인스턴스 구간이 평문이 되므로, 내부 구간 암호화가 필요한 규제 환경에서는 end-to-end TLS를 따로 고려해야 한다.
5. ELB의 다양한 유형
ELB는 계층과 용도에 따라 세 종류로 나뉜다.
유형
주요 특징
사용 사례
ALB (Application LB)
L7 / 경로·호스트 기반 라우팅
웹 앱 (REST API, 마이크로서비스)
NLB (Network LB)
L4 / 초고속 처리 / 고정 IP
실시간 게임, 금융
CLB (Classic LB)
구형 / EC2 전용
레거시 시스템
ALB 구성 요소는 세 가지다.
Listener: 프로토콜 및 포트 (예: HTTP:80)
Target Group: 대상 EC2 인스턴스 그룹
부하 분산 규칙(Rule): 예) 50:50, URL 경로별 분산
💡 ELB 유형 비교에서 느낀 점
ALB는 L7이라 path/host 기반 라우팅(/api는 A그룹, /static은 B그룹)이 되지만, NLB는 L4라 HTTP 헤더를 못 본다. 마이크로서비스 라우팅을 원하면 ALB, 극한의 throughput과 고정 IP가 필요하면 NLB라는 기준이 명확해졌다.
NLB의 "고정 IP"가 실무에서 의외로 중요하다. 외부 파트너가 IP 화이트리스트로 방화벽을 걸어둔 경우 ALB의 변동 IP는 곤란하다. 금융 서비스에 NLB가 적합한 이유 중 하나다.
CLB는 사실상 deprecated 취급이다. 신규 구축에서 CLB를 고를 일은 없고, 레거시 마이그레이션 시 ALB/NLB로 전환 대상이다.
6. 헬스 체크의 동작 원리
Health check는 ELB가 각 인스턴스 상태를 주기적으로 확인해서 정상 인스턴스에만 트래픽을 보내는 기능이다.
동작 흐름은 이렇다.
ELB가 각 인스턴스에 주기적으로 HTTP 요청 또는 TCP 연결 시도
응답 상태 코드 / 연결 여부 확인
응답 실패가 일정 횟수 이상 지속되면 Unhealthy로 전환
해당 인스턴스는 트래픽 대상에서 제외
회복되면 자동으로 Healthy 복귀
health check 설정 항목 예시는 다음과 같다.
항목
값
경로
/health 또는 /index.html
프로토콜
HTTP / HTTPS / TCP
정상 응답 코드
200, 302 등
간격
30초
실패 허용 횟수(unhealthy threshold)
3회
성공 필요 횟수(healthy threshold)
2회
실무 팁:
애플리케이션 내부에 /health 전용 API를 만든다
health check 실패 시 ASG와 연동해 자동으로 인스턴스 교체
정상 상태만 Target으로 유지 → 장애 격리
💡 헬스 체크에서 느낀 점
/index.html로 health check를 걸면 위험하다. 정적 페이지는 DB가 죽어도 200을 반환하기 때문에, 실제로는 장애인데 Healthy로 잡힐 수 있다. DB 연결, 의존 서비스까지 검사하는 별도 /health 엔드포인트를 두는 게 best practice라는 게 핵심이다.
다만 /health에서 의존성을 너무 깊게 검사하면 반대 문제가 생긴다. 외부 서비스 일시 지연 때문에 멀쩡한 인스턴스가 무더기로 Unhealthy 처리되며 cascading failure가 날 수 있다. shallow check와 deep check를 분리하는 설계도 고민거리다.
간격 30초 × 실패 3회면 장애 감지에 최대 90초가 걸린다. 이 detection lag 동안 일부 요청은 죽은 인스턴스로 가서 실패한다. 빠른 감지를 원하면 간격을 줄이되 false positive가 늘어나는 trade-off를 감수해야 한다.
7. 실습 — EC2 2개를 서로 다른 AZ에 배포
목표는 멀티 AZ 이중화 구성을 직접 체험하고 AZ 단위 인프라를 이해하는 것이다.
데모 절차
EC2 인스턴스 2개 생성 (서울 리전 default VPC, AZ-a / AZ-c 각각 배치)
인스턴스에 Apache 또는 Nginx 설치 → 서버 식별용 페이지 설정 (예: "AZ-a 서버입니다.", "AZ-c 서버입니다.")
서버 식별 페이지를 다르게 둬야 나중에 ELB가 두 인스턴스에 번갈아 라우팅하는 걸 눈으로 확인할 수 있다.
user data 스크립트
인스턴스 생성 시 user data로 LAMP 스택을 자동 구성한다.
#!/bin/sh
# Install a LAMP stack
dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel
dnf install -y mariadb105-server
dnf install -y httpd php-mbstring
# Start the web server
chkconfig httpd on
systemctl start httpd
# Install the web pages for our lab
if [ ! -f /var/www/html/immersion-day-app-php7.zip ]; then
cd /var/www/html
wget -O 'immersion-day-app-php7.zip' 'https://static.us-east-1.prod.workshops.aws/public/9c7201ac-1ceb-4185-b7df-7916c97d9227/assets/immersion-day-app-php7.zip'
unzip immersion-day-app-php7.zip
fi
# Install the AWS SDK for PHP
if [ ! -f /var/www/html/aws.zip ]; then
cd /var/www/html
mkdir vendor
cd vendor
wget https://docs.aws.amazon.com/aws-sdk-php/v3/download/aws.zip
unzip aws.zip
fi
# Update existing packages
dnf update -y
📸 [스크린샷: EC2 인스턴스 2개 생성 - AZ-a, AZ-c로 가용 영역 다르게 지정한 화면]
📸 [스크린샷: 각 인스턴스 퍼블릭 IP로 접속 시 "AZ-a 서버입니다" / "AZ-c 서버입니다" 식별 페이지 확인]
💡 EC2 멀티 AZ 배포 실습에서 느낀 점
인스턴스 생성 시 subnet을 고르면 AZ가 자동으로 따라온다. AZ를 직접 지정하는 게 아니라 subnet이 AZ에 종속되어 있어서, 멀티 AZ를 하려면 애초에 AZ가 다른 subnet 2개가 필요하다. default VPC는 AZ별 subnet이 미리 있어서 편했다.
user data는 인스턴스 최초 부팅 시 1회만 실행된다. 스크립트를 잘못 짜면 인스턴스를 재생성해야 해서, if [ ! -f ... ] 가드로 멱등성(idempotency)을 챙긴 부분이 눈에 띈다. 재실행돼도 중복 다운로드를 막는 패턴이다.
chkconfig httpd on은 Amazon Linux 2023에서는 사실상 systemctl enable httpd로 대체된 레거시 명령이다. 동작은 하지만 deprecated라, 실무라면 systemctl enable --now httpd 한 줄로 정리하는 게 깔끔하다.
8. 실습 — ELB 연결 후 헬스 체크 기반 자동 복구
목표는 ELB를 통한 트래픽 분산 확인, 그리고 한 인스턴스 장애 시 트래픽 자동 우회 확인이다.
데모 절차
1. ALB 생성
Target Group에 두 인스턴스 등록
Listener 설정: 포트 80 → Target Group
2. ELB 도메인 접속
여러 번 새로고침해서 AZ-a, AZ-c 인스턴스가 번갈아 응답하는지 확인
📸 [스크린샷: ALB DNS 주소 접속 후 새로고침 시 AZ-a / AZ-c 응답이 번갈아 나오는 화면]
3. AZ-c 인스턴스 강제 중지
콘솔에서 Stop 또는 Terminate
1~2분 내에 ELB가 해당 인스턴스를 Unhealthy로 판단
📸 [스크린샷: Target Group의 대상 상태가 healthy → unhealthy로 바뀐 화면]
4. ELB 재접속 시 응답 변화 확인
살아있는 AZ-a 인스턴스만 응답
📸 [스크린샷: 인스턴스 중지 후 새로고침해도 AZ-a 서버만 응답하는 화면]
5. 자원 정리
EC2 인스턴스 모두 삭제
로드밸런서 삭제
Target Group 삭제
💡 ELB failover 실습에서 느낀 점
Stop과 Terminate 둘 다 health check를 fail시키지만 의미가 다르다. Stop은 EBS 유지·재시작 가능, Terminate는 완전 삭제다. failover 데모 후 인스턴스를 되살려 Healthy 복귀까지 보려면 Stop을 써야 한다. Terminate하면 인스턴스 자체가 사라져서 복귀 시연이 불가능하다.
"1~2분 내 Unhealthy 판단"이 바로 앞에서 본 간격 30초 × 실패 3회 = 90초의 실제 체감이다. 인스턴스를 죽인 직후 새로고침하면 잠깐 동안은 죽은 서버로 가서 에러가 뜨다가, threshold를 넘기고 나서야 트래픽이 완전히 우회된다. detection lag을 눈으로 확인한 셈이다.
자원 정리 순서가 중요하다. ELB를 먼저 안 지우고 Target Group을 지우려 하면 의존성 때문에 막힌다. 인스턴스 → 로드밸런서 → Target Group 순서, 혹은 ELB 삭제 후 나머지를 정리하는 게 안전하다. 실습 후 ELB를 안 지우면 시간당 과금이 계속 나가므로 정리는 필수다.
학습 정리
고가용성은 "몇 개의 9"로 측정하며, 9가 늘수록 연간 다운타임이 급감한다. 필요한 가용성 수준을 먼저 정하고 중복도를 맞춘다
HA 설계의 출발점은 SPOF 제거 + "장애가 난다"는 가정의 역방향 설계다
멀티 AZ는 물리적 장애를 분산한다. AZ는 격리되어 있지만 저지연 연결이라 RDS 동기 복제가 가능하다
RDS Multi-AZ(failover용 standby)와 Read Replica(읽기 분산)는 다른 개념이다
ELB는 Target Group을 매개로 Auto Scaling Group과 연결된다. scaling과 load balancing의 결합점이 Target Group이다
