12주차 - 고가용성 및 장애 복구 설계

- 고가용성(High Availability, HA)
서비스를 가능한 오랫동안 중단 없이 지속적으로 제공하는 능력

장애가 발생해도 빠르게 복구하거나 자동으로 우회해 서비스 지속성을 유지하는 것이 핵심 목표

가용성	연간 허용 중단 시간	비고
99%	약 87시간	내부 직원용 시스템 수준
99.9%	약 8시간 45분	일반 중소 서비스 수준
99.99%	약 52분	AWS 권장 수준
99.999%	약 5분	금융·헬스케어 등 민감 시스템

고가용성이 중요한 이유는 서비스 중단이 단순히 시스템 문제로 그치지 않고 비즈니스에 직접 영향을 주기 때문> 매출 손실, 브랜드 신뢰 하락, SLA(서비스 수준 계약) 위반 시 손해배상까지 이어질 수 있다.


- 고가용성 아키텍처 핵심 원리

"언젠가는 장애가 발생한다"는 가정에서 출발

- 단일 장애점(SPOF) 제거: 특정 서버나 장비를 하나만 두지 않음, 이중화·다중화로 단일 장애로 인한 전체 중단을 방지
- 다중 AZ / 다중 리전 사용: 서울 리전 + 도쿄 리전처럼 멀티 리전으로 이중화할 수 있고, 같은 리전 내 가용 영역을 달리해 이중화할 수도 있다. 가용성은 멀티 리전이 높지만 관리 복잡도도 높으므로, AWS에서는 멀티 AZ 이중화를 권장
- 자동 복구 메커니즘 구축: 시스템이 자동으로 모니터링 → 장애 감지 → 자동 복구까지 수행하도록 설계
- 트래픽 분산 및 자동 우회: 로드밸런서(ELB)나 라우트53으로 트래픽을 분산하고, 장애 발생 인스턴스로는 트래픽이 가지 않도록 자동 우회
- 인프라 자동화: Auto Scaling과 IaC(Infrastructure as a Code, AWS CloudFormation)를 활용함. Auto Scaling은 트래픽 급증 시 인스턴스를 자동으로 늘리고 감소 시 줄임. 최소 인스턴스 수를 설정해 두면 인스턴스가 장애로 종료됐을 때 자동으로 새 인스턴스가 생성

- ELB(Elastic Load Balancing)

여러 서버로 들어오는 트래픽을 자동으로 분산시켜 주는 장치 또는 서비스

한 서버에 부하가 집중되지 않도록 해 성능을 향상시키고 서비스 중단을 방지한다.

 

ELB(Elastic Load Balancing)는 수신되는 트래픽을 EC2 인스턴스, 컨테이너, IP 주소 등에 걸쳐 분산하는 AWS의 완전 관리형 로드 밸런싱 서비스로, 단일 웹 앱부터 마이크로서비스, 하이브리드 환경까지 유연하게 지원한다.

- 고가용성: 트래픽을 단일 또는 여러 AZ에 있는 다수 대상에 자동으로 분산
- 상태 확인(Health Check): 주기적으로 핑을 보내거나 TCP 연결을 시도해 EC2 인스턴스의 가용성을 테스트함
- 보안 기능: VPC 내 ELB에 보안 그룹 적용 가능
- SSL 오프로드: HTTPS 복호화를 ELB가 대신 처리해 뒤쪽 서버의 CPU 부하를 줄임. SSL 설정을 ELB 한 곳에서 중앙 집중 관리할 수 있음
- 계층별 로드밸런싱: L7(HTTP/HTTPS) 또는 L4(TCP/UDP) 기반 로드밸런싱 지원

- ELB 유형

유형	계층	주요 특징	사용 사례
ALB (Application Load Balancer)	L7	HTTP/HTTPS 기반, URL·호스트 기반 라우팅 가능	웹 애플리케이션, REST API, 마이크로서비스
NLB (Network Load Balancer)	L4	TCP/UDP 기반, 초고속 처리, 고정 IP	실시간 게임, 금융 서비스
CLB (Classic Load Balancer)	L4/L7	구형, EC2 전용. 현재 사용 비권장	레거시 시스템 유지

- ELB와 Auto Scaling 연동
EC2 Auto Scaling은 EC2 용량을 자동으로 조정하는 서비스임. 수요 급증 시 인스턴스 수를 늘리고 수요 감소 시 줄여 성능 유지와 비용 낭비 제거를 동시에 달성함. ELB와 연결해 사용함

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

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

ELB가 인스턴스에 HTTP 요청 또는 TCP 연결 시도 →
응답 상태 코드(200 등) 또는 연결 여부 확인 →
실패가 설정 횟수(예: 3회) 이상 지속되면 Unhealthy 상태로 전환 →
해당 인스턴스는 트래픽 대상에서 제외 →
회복 시 설정 성공 횟수(예: 2회) 연속 성공 후 Healthy로 자동 복귀

실무에서는 애플리케이션 내부에 /health 전용 API를 만들어 두는 방식을 많이 사용한다.

- 실습: 멀티 AZ EC2 배포 + ALB 연결 후 장애 복구 확인

1 - EC2 인스턴스 2개 생성 (서로 다른 AZ에 배포)

1. AWS 콘솔 → EC2 → 인스턴스 시작
2. 서울 리전(ap-northeast-2) 디폴트 VPC 사용
3. 첫 번째 인스턴스: 서브넷을 AZ-a(ap-northeast-2a)로 선택
4. 두 번째 인스턴스: 서브넷을 AZ-c(ap-northeast-2c)로 선택
5. 아래 사용자 데이터(User Data)를 각 인스턴스에 입력해 Apache 설치 및 웹페이지 자동 설정

myserver-az-a (편의를 위해 가용영역을 서버 이름에 적음)

키 페어 없이 계속 진행 / ap-northeast-2a로 지정

 

HTTP/HTPS 보안 규칙 그룹 추가

#!/bin/sh

#Install a LAMP stack (install Apache web server)
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

사용자 데이터에 pdf에 있던 내용 입력 후 생성

같은 방식으로 myserver-az-c도 생성

 

(이 아래로부터는 사용자 데이터 파일이 잘못되었는지 it works만 뜨고 실행이 되지 않아 강의 영상 캡처를 사용했습니다.)

 

2 - ALB 생성 및 Target Group 구성

1. EC2 콘솔 → 로드 밸런서 → 로드 밸런서 생성 → Application Load Balancer 선택
2. 이름 입력, Scheme: Internet-facing, IP 주소 유형: IPv4
3. 네트워크 매핑에서 AZ-a, AZ-c 서브넷 모두 선택
4. 보안 그룹: HTTP(80포트) 허용 보안 그룹 지정
5. Target Group 생성 → 인스턴스 유형, HTTP, 포트 80으로 설정
6. 헬스 체크 경로: /index.html (또는 /health)
7. 두 EC2 인스턴스를 Target Group에 등록
8. 리스너: HTTP 80 → 생성한 Target Group으로 포워딩 설정
9. ALB 생성 완료

퍼블릭 DNS로 접속하여 보면 위와 같이 접속되는 것을 확인할 수 있다.

a와 c 를 사용하고 있으므로 두 가용 영역 체크

보안 그룹 새로 생성하고 할당

3 - 트래픽 분산 확인

1. ALB DNS 이름 복사 (예: my-alb-1234567890.ap-northeast-2.elb.amazonaws.com)
2. 브라우저에서 여러 번 새로고침하며 AZ-a 서버와 AZ-c 서버가 번갈아 응답하는지 확인

새로고침하면 a와 c가 번갈아가며 나온다 (로드밸런서 적용)

 

4 - AZ-c 인스턴스 장애 시뮬레이션 및 자동 우회 확인

1. EC2 콘솔에서 AZ-c 인스턴스 선택 → 인스턴스 상태 → 중지(Stop) 또는 종료(Terminate)
2. 1~2분 대기 (ELB가 헬스 체크 실패를 감지해 Unhealthy로 전환하는 시간)
3. Target Group → 대상 탭에서 AZ-c 인스턴스가 Unhealthy 상태로 바뀐 것 확인
4. ALB DNS로 다시 접속해 AZ-a 인스턴스만 응답하는지 확인

둘 중 하나를 중단시켜(c) Unhealthy 상태로 바뀐 것을 확인

새로고침해도 a만 나오는 것을 확인할 수 있다