Building a Fault-Tolerant Web Service (ALB + Auto Scaling)
1. 과제 목표
이 과제에서는 Application Load Balancer (ALB) 와 Auto Scaling Group (ASG) 를 이용해 자동으로 복구(Self-healing)되고, CPU 부하에 따라 확장(Scale-out)되는 웹 애플리케이션을 구축해보기
2. 사전 준비
| 항목 | 설정 |
|---|---|
| Region | ap-northeast-2 (Seoul) |
| Instance Type | t2.micro |
| Storage | 10GB (gp3) |
| Security Groups | web, alb 두 개 생성 |
| Key Pair | 새로 생성 또는 기존 사용 |
| VPC/Subnet | 기본(Default) VPC 사용 가능 |
3. 실습 단계별 수행 절차
Step 1. Security Group 생성
(1) ALB용 Security Group
- AWS Management Console → EC2 → Network & Security → Security Groups → Create security group
- 이름:
alb-cc-sg - 인바운드 규칙 추가:
- Type: HTTP / Port: 80 / Source: 0.0.0.0/0
- 아웃바운드 규칙: 기본값 (모두 허용)
- Create security group
(2) EC2(Web)용 Security Group
- 새 그룹 생성 → 이름:
cc-sg - 인바운드 규칙 추가:
- Type: HTTP / Port: 80 / Source: alb-cc-sg
- Type: SSH / Port: 22 / Source: 0.0.0.0/0
- Create security group
Step 2. Target Group 생성
- EC2 → Target Groups → Create target group
- Target type: Instances
- Name: cc-tgrp
- Protocol: HTTP
- Port: 80
- Health check path:
/ - Success code:
200 - Next → Create target group
Step 3. Application Load Balancer 생성
-
EC2 → Load Balancers → Create Load Balancer
-
Application Load Balancer 선택
-
설정 입력:
- Name:
alb-cc - Scheme: Internet-facing
- IP type: IPv4
- Name:
-
Network mapping:
- Subnets: 서로 다른 두 개의 Public Subnet 선택
-
Security groups:
alb-cc-sg -
Listeners:
- Protocol: HTTP / Port: 80
- Default action: Forward → Target group
cc-tgrp선택
-
Create load balancer
-
생성 후 DNS 이름 복사
예시:
alb-web-123456.ap-northeast-2.elb.amazonaws.com
Step 4. Launch Template 생성
- EC2 → Launch Templates → Create launch template
- Name:
cc-lt - AMI: Amazon Linux 2023 (Kernel 6.1)
- Instance type: t3.micro
- Key pair: 선택 (또는 새로 생성)
- Security group: web-sg
- Storage:
- 8GiB / gp3 / 3000 IOPS
- User data 입력 (Nginx 자동 설치 스크립트):
#!/bin/bash
dnf -y install nginx
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s)
IID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
-s http://169.254.169.254/latest/meta-data/instance-id)
AZ=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" \
-s http://169.254.169.254/latest/meta-data/placement/availability-zone)
echo "<h1>Hello from $IID ($AZ)</h1>" > /usr/share/nginx/html/index.html
systemctl enable nginx
systemctl start nginx
- Create launch template
Step 5. Auto Scaling Group 생성
- EC2 → Auto Scaling Groups → Create Auto Scaling group
- Name:
cc-asg - Launch template:
cc-lt선택 - Network: 기본 VPC 선택
- Subnets: 서로 다른 2개의 Public Subnet 선택
- Load balancing:
- Attach to an existing load balancer
- Choose target group →
cc-tgrp
- Health checks:
- Turn on ELB health checks
- Grace period: 180 seconds
- Group size:
- Desired capacity: 1
- Minimum capacity: 1
- Maximum capacity: 2
- Next → Create Auto Scaling Group
Step 6. Scaling Policy 설정
- Auto Scaling Group → Automatic scaling → Create dynamic scaling policy
- Policy type: Target tracking scaling policy
- Metric type: Average CPU utilization
- Target value: 50%
- Cooldown: 기본값 유지
- Create policy
4. 실험 (Verification Tests)
Test 1: Round-Robin Load Balancing 확인
-
웹 브라우저에서 ALB DNS 이름 입력
http://alb-web-xxxxxxxx.ap-northeast-2.elb.amazonaws.com -
새로고침할 때마다 화면에 표시되는 “Hello from i-xxxx (AZa)” 메시지가 변경되는지 확인
Test 2: Self-Healing 확인
-
EC2 → 인스턴스 목록에서 현재 실행 중인 인스턴스 확인
-
SSH 접속 후 Nginx 중단:
sudo systemctl stop nginx -
Target Group에서 해당 인스턴스 상태가 Unhealthy 로 변경됨 확인
-
Auto Scaling Group이 새 인스턴스 자동 생성
Test 3: CPU 부하로 Scale-Out 확인
-
인스턴스에 SSH 접속
-
아래 명령어로 CPU 부하 발생시킴:
yes > /dev/null & yes > /dev/null & -
CPU 사용률이 50% 이상으로 오르면 Auto Scaling이 새 인스턴스 생성
-
인스턴스 개수가 2개로 증가하면 성공
Test 4: Scale-In 확인
-
부하 중단:
killall yes -
CPU 사용률이 떨어지면 일정 시간 후 인스턴스 수가 다시 1개로 감소
1. 평상시 트래픽 처리 흐름 (사용자 요청 → 웹페이지 응답)
사용자가 웹 브라우저 주소창에 ALB의 DNS 주소를 입력했을 때의 흐름
- [사용자 → ALB]
- 사용자의 웹 브라우저가 ALB의 DNS 주소로 HTTP 요청(웹페이지 보여줘!)을 보냄
- 이 요청은 인터넷을 통해 서울 리전(ap-northeast-2)에 있는 Application Load Balancer (ALB) 로 들어옴
- [ALB → 대상 그룹 → EC2]
- ALB는 HTTP:80 포트로 들어온 요청을 리스너 규칙에 따라 대상 그룹(tgrp-web) 으로 전달
- 대상 그룹은 현재 자신에게 등록된 EC2 인스턴스 중 'Healthy'(정상) 상태인 인스턴스 를 확인
- 정상 인스턴스가 여러 개 있다면, ALB는 트래픽을 라운드-로빈 방식으로 분배하여 그중 한 개의 EC2 인스턴스로 요청을 보냄
- [EC2 → 사용자]
- 요청을 받은 EC2 인스턴스의 Nginx 웹 서버는 "Hello from 인스턴스ID" 내용이 담긴 HTML 페이지를 응답으로 보냄.
- 이 응답은 ALB를 거쳐 최종적으로 사용자의 웹 브라우저에 표시
- 사용자가 새로고침하면 ALB는 다음 정상 인스턴스로 요청을 보내기 때문에, 다른 인스턴스 ID가 화면에 보이게 됌
2. Auto Scaling 작동 흐름 (자가 복구 및 스케일링)
시스템에 문제가 생기거나 부하가 많아졌을 때의 자동화된 흐름
A) 자가 복구 (Self-Healing) 흐름
- [문제 발생]
- 관리자가 SSH로 EC2 인스턴스에 접속해 Nginx 웹 서버를 중지
- [상태 검사 실패]
- ALB의 대상 그룹은 주기적으로 EC2 인스턴스의 '/' 경로로 상태 확인(Health Check)을 보냄
- Nginx가 중지되었으므로 EC2는 정상 응답(HTTP 200)을 보내지 못하고, 대상 그룹은 해당 인스턴스를 'Unhealthy'(비정상) 상태로 판별
- 이제 ALB는 이 비정상 인스턴스로는 더 이상 트래픽을 보내지 않음
- [Auto Scaling의 자동 복구]
- Auto Scaling 그룹(ASG) 은 ELB 상태 확인(Health Check) 기능을 통해 자신의 인스턴스가 비정상 상태가 된 것을 감지
- ASG는 설정된 최소 인스턴스 개수(Min=1)를 유지하기 위해, 비정상 인스턴스를 종료(Terminate)하고 새로운 EC2 인스턴스를 자동으로 시작
- 새로 시작된 인스턴스가 부팅 및 웹 서버 설정을 마치고 정상 상태가 되면, 대상 그룹에 등록되어 다시 트래픽을 받기 시작
- Auto Scaling 그룹(ASG) 은 ELB 상태 확인(Health Check) 기능을 통해 자신의 인스턴스가 비정상 상태가 된 것을 감지
B) 확장 (Scale-Out) 및 축소 (Scale-In) 흐름
- [부하 증가]
- 인스턴스 내에서
yes명령어를 실행하여 CPU 사용률을 50% 이상으로 높이기
- 인스턴스 내에서
- [스케일링 정책 트리거]
- ASG는 "평균 CPU 사용률 > 50%" 라는 스케일링 정책 조건을 계속 감시
- 조건이 충족되면 ASG는 새로운 EC2 인스턴스를 추가로 시작하여 인스턴스 수를 2개로 늘림 (Max=2 설정 때문).
- [서비스 확장]
- 새로 추가된 인스턴스가 정상 상태가 되면 대상 그룹에 포함
- 이제 ALB는 2개의 인스턴스로 트래픽을 분산하여 늘어난 부하를 처리
- [부하 감소 및 축소]
-
killall yes명령어로 CPU 부하를 제거하면 CPU 사용률이 다시 낮아짐
- ASG는 CPU 사용률이 낮아진 것을 감지하고, 정해진 시간이 지나면 인스턴스 수를 다시 원래의 1개로 줄암(Scale-In).
-
흐름 1: 평상시 트래픽 처리 (라운드 로빈)
사용자 요청이 어떻게 2대의 서버로 분산되는지 (Scale-Out 상태 가정)
┌───────────────────────┐
│ Internet User │
│ (브라우저 새로고침 반복) │
└───────────┬───────────┘
│ (HTTP Request)
▼
┌───────────────────────┐
│ Application Load Balancer │
└───────────┬───────────┘
┌────────┴────────┐
│ 요청을 순차적으로 분배 │
▼ ▼
┌───────────────────┐ ┌───────────────────┐
│ EC2 Instance 1 │ │ EC2 Instance 2 │
│ (Availability Zone A) │ │ (Availability Zone B) │
│ 응답: "Hello from i-aaa"│ │ 응답: "Hello from i-bbb"│
└───────────────────┘ └───────────────────┘설명:
- 사용자가 ALB 주소로 접속하면, ALB는 첫 번째 요청을 Instance 1로 보냄
- 사용자가 브라우저를 새로고침하여 다시 요청하면, ALB는 다음 요청을 Instance 2로 보냄
- 이렇게 요청이 두 인스턴스에 번갈아 가며 전달되어 부하가 분산
흐름 2: 자가 복구 (Self-Healing)
한쪽 서버에 문제가 생겼을 때 시스템이 스스로 복구하는 과정
초기 상태 (정상) 문제 발생! 자동 복구 과정
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ EC2 Instance 1 │ │ EC2 Instance 1 │ │ EC2 Instance 1 │
│ [상태: Healthy] │ │ [상태: Unhealthy] │ │ [상태: Terminating] │
│ (Nginx 동작 중) │ ────▶ │ (Nginx 중지됨 ☠️) │ ────▶ │ (ASG가 종료시킴) │
└───────────────────┘ └───────────────────┘ └──────────┬────────┘
│ │
(ALB 헬스 체크 실패 감지) │ (ASG가 새 인스턴스 시작)
│ ▼
└──────────────▶ ┌───────────────────┐
│ EC2 Instance 2 │
│ [상태: Healthy] │
│ (새로 생성된 인스턴스) │
└───────────────────┘설명:
-
문제 발생: 관리자가 EC2 인스턴스의 웹 서버(Nginx)를 중지
-
상태 감지: ALB의 대상 그룹이 주기적인 상태 검사(Health Check)를 통해 해당 인스턴스가 비정상(Unhealthy) 상태가 된 것을 감지
-
자동 복구: Auto Scaling Group(ASG)이 이 비정상 인스턴스를 발견하고, 최소 인스턴스 수(1개)를 유지하기 위해 자동으로 해당 인스턴스를 종료하고 건강한 새 인스턴스를 시작
흐름 3: 자동 확장 (Scale-Out)
서버 부하가 증가했을 때 자동으로 서버 수를 늘리는 과정
평상시 상태 부하 증가! 자동 확장 후
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ EC2 Instance 1 │ │ EC2 Instance 1 │ │ EC2 Instance 1 │ │ EC2 Instance 2 │
│ [CPU: 5%] │ ────▶ │ [CPU: 99% ▲] │ ────▶ │ [CPU: 50%] │ │ [CPU: 50%] │
└───────────────────┘ └──────────┬────────┘ └───────────────────┘ └───────────────────┘
│
(ASG 정책 트리거: CPU > 50%)
│
▼
┌─────────────────────┐
│ Auto Scaling Group │
│ (새 인스턴스 시작) │
└─────────────────────┘설명:
-
부하 증가: 인스턴스의 CPU 사용률이 급증하여 ASG에 설정된 목표 값(50%)을 초과
-
정책 실행: ASG는 CPU 사용률 증가를 감지하고, 설정된 확장 정책(Target Tracking)에 따라 인스턴스 수를 늘리기로 결정
-
확장 완료: ASG는 시작 템플릿을 이용해 새로운 EC2 인스턴스를 시작하고, 이 인스턴스가 정상 상태가 되면 ALB가 트래픽을 분산하기 시작 -> 결과적으로 전체 시스템의 부하가 낮아짐
흐름 4: 자동 축소 (Scale-In)
증가했던 서버 부하가 다시 줄어들었을 때 서버 수를 원래대로 줄이는 과정
확장된 상태 부하 감소 자동 축소 후
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ EC2 Instance 1 │ │ EC2 Instance 2 │ │ EC2 Instance 1 │ │ EC2 Instance 1 │
│ [CPU: 50%] │ │ [CPU: 50%] │ ────▶ │ [CPU: 5% ▼] │ ────▶ │ [CPU: 5%] │
└───────────────────┘ └──────────┬────────┘ └───────────────────┘ └───────────────────┘
│
(ASG가 종료시킴)
│
(ASG 정책 트리거: CPU < 50%)
│
┌─────────────────────┐
│ Auto Scaling Group │
│ (인스턴스 1개 종료) │
└─────────────────────┘설명:
-
부하 감소: CPU 부하를 유발하던 프로세스가 종료되어 인스턴스들의 평균 CPU 사용률이 목표 값(50%)보다 현저히 낮아짐
-
정책 실행: ASG는 일정 시간 동안 낮은 CPU 사용률이 유지되는 것을 확인한 후, 인스턴스 수를 줄이기로 결정
-
축소 완료: ASG는 인스턴스 중 하나를 종료하여 최소 인스턴스 수(1개)로 되돌립니다10. 이를 통해 불필요한 비용을 절감
