테마
08. AWS Auto Scaling - 트래픽에 따라 서버를 자동으로 늘리고 줄이기
1. Auto Scaling이 필요한 상황
현실 세계의 문제
온라인 쇼핑몰을 운영한다고 가정해보자.
- 평소: 하루 방문자 약 100만 명 -> 서버 1대로 충분
- 블랙프라이데이/연말 세일: 방문자 1,000만 명으로 폭증 -> 서버 10대 필요
- 이벤트 종료 후: 다시 100만 명으로 복귀 -> 서버 1대로 충분
수동 관리의 한계
이벤트 전: "트래픽 폭증 대비해서 서버 9대 추가 증설해야지!"
이벤트 중: "잘 버티고 있군, 다행이다."
이벤트 후: "서버 10대 중 9대가 놀고 있다... 시간당 비용은 계속 나가는데..."수동 관리의 문제점:
| 문제 | 설명 |
|---|---|
| 비용 낭비 | 이벤트 후에도 불필요한 서버가 계속 돌아감 |
| 대응 지연 | 갑작스러운 트래픽 폭증에 사람이 즉시 대응 불가 |
| 과잉 프로비저닝 | "혹시 몰라서" 필요 이상으로 서버를 미리 확보 |
| 과소 프로비저닝 | 예상보다 트래픽이 많으면 서비스 장애 발생 |
Auto Scaling의 해결
평소: 서버 1대 운영 중 (비용 최소)
트래픽 증가: CloudWatch가 CPU 사용률 급증 감지!
-> Auto Scaling이 자동으로 서버 2대, 3대... 추가
트래픽 감소: CloudWatch가 CPU 사용률 안정 감지!
-> Auto Scaling이 자동으로 불필요한 서버 제거결론: 사람이 개입하지 않아도 트래픽에 따라 서버가 자동으로 늘었다 줄었다 한다!
2. Auto Scaling이란?
정의
Auto Scaling은 트래픽(부하)에 따라 EC2 인스턴스(Instance) 수를 자동으로 조절하는 AWS 서비스이다.
- 부하가 높아지면 -> 인스턴스를 추가 (스케일 아웃, Scale Out)
- 부하가 낮아지면 -> 인스턴스를 제거 (스케일 인, Scale In)
쉬운 비유: 놀이공원 매표소
놀이공원 매표소를 상상해보자.
[평일 - 손님 적음]
창구 1개만 열어도 충분
-> 직원 1명 배치
[주말 - 손님 많음]
줄이 길어지기 시작!
-> 관리자가 창구 2개, 3개 추가 오픈
-> 직원 3명 배치
[다시 평일]
손님이 줄어들었다
-> 추가 창구 닫음
-> 직원 1명으로 복귀
Auto Scaling = 이 "관리자"를 자동화한 것!왜 중요한가?
Auto Scaling은 클라우드 서비스의 핵심 장점을 100% 활용하는 기능이다.
| 온프레미스(On-Premise) | 클라우드 + Auto Scaling |
|---|---|
| 서버를 미리 구매해야 함 | 필요할 때만 서버 생성 |
| 최대 트래픽 기준으로 구매 | 현재 트래픽 기준으로 운영 |
| 남는 서버 = 비용 낭비 | 필요 없으면 자동 제거 |
| 부족하면 추가 구매에 수주~수개월 | 몇 분 만에 자동 추가 |
실제 사례: 아마존(Amazon) 자체도 블랙프라이데이(Black Friday) 시즌에 Auto Scaling을 활용하여 폭증하는 트래픽을 처리한다. 전 세계 최대 규모의 트래픽 변동을 Auto Scaling으로 대응하는 것이다.
3. Auto Scaling 전체 동작 흐름
아래 다이어그램은 Auto Scaling이 트래픽 변화에 대응하는 전체 흐름을 보여준다.
흐름 요약:
- CloudWatch가 EC2 인스턴스의 상태를 지속적으로 모니터링한다.
- 설정한 **임계값(Threshold)**을 초과하면 Auto Scaling이 인스턴스를 추가한다.
- **ELB(Elastic Load Balancer)**가 새로 추가된 인스턴스에도 트래픽을 분배한다.
- 부하가 안정되면 다시 모니터링을 계속한다.
- 부하가 충분히 낮아지면 불필요한 인스턴스를 제거한다.
4. 핵심 구성 요소
4-1. AMI (Amazon Machine Image)
AMI는 Auto Scaling이 새 인스턴스를 생성할 때 사용하는 **서버의 스냅샷(이미지)**이다.
AMI = 운영체제 + 설치된 프로그램 + 설정 파일을 통째로 복사한 것
예시:
Amazon Linux 2
+ Apache 웹서버 설치됨
+ 웹 애플리케이션 배포됨
+ 필요한 설정 완료됨
= 이 상태를 AMI로 저장!
-> Auto Scaling이 이 AMI를 사용하여 동일한 서버를 빠르게 복제핵심 포인트: AMI에 서버 프로그램이 이미 설치되어 있어야 Auto Scaling으로 새 서버가 생성되었을 때 바로 서비스가 가능하다!
4-2. 시작 템플릿 (Launch Template)
시작 템플릿은 "새 인스턴스를 어떤 사양으로 만들 것인가"를 정의하는 설계도이다.
시작 템플릿에 포함되는 정보:
| 항목 | 설명 | 예시 |
|---|---|---|
| AMI | 어떤 이미지를 사용할지 | 내가 만든 Apache AMI |
| 인스턴스 유형(Instance Type) | 서버 사양 | t2.micro (1 vCPU, 1GB RAM) |
| 보안 그룹(Security Group) | 방화벽 규칙 | HTTP(80), SSH(22) 허용 |
| 키 페어(Key Pair) | SSH 접속용 키 | my-key.pem |
| 사용자 데이터(User Data) | 부팅 시 자동 실행 스크립트 | 웹서버 시작 명령 |
4-3. 사용자 데이터 (User Data)
사용자 데이터는 인스턴스가 처음 부팅될 때 자동으로 실행되는 스크립트이다.
bash
#!/bin/bash
# 인스턴스가 부팅되면 이 스크립트가 자동 실행된다
# Apache 웹서버 시작
sudo service httpd start
# 부팅 시마다 Apache가 자동 시작되도록 설정
sudo chkconfig httpd on
# 간단한 테스트 페이지 생성
echo "<h1>Auto Scaling Instance $(hostname)</h1>" > /var/www/html/index.html왜 필요한가?
AMI에 Apache가 설치되어 있더라도, 인스턴스가 부팅된 후 Apache 서비스를 시작해야 실제로 웹 요청을 처리할 수 있다. 사용자 데이터가 이 시작 과정을 자동화해준다.
4-4. Auto Scaling 그룹 (Auto Scaling Group, ASG)
Auto Scaling 그룹은 "인스턴스를 몇 대 유지할 것인가"를 관리하는 핵심 단위이다.
| 설정 | 의미 | 예시 |
|---|---|---|
| 최소 용량(Minimum Capacity) | 항상 유지할 최소 인스턴스 수 | 1대 |
| 최대 용량(Maximum Capacity) | 최대로 늘릴 수 있는 인스턴스 수 | 3대 |
| 권장 용량(Desired Capacity) | 평상시 유지할 인스턴스 수 | 1대 |
| 스케일링 정책(Scaling Policy) | 언제 늘리고 줄일지의 조건 | CPU 사용률 기준 |
4-5. ELB 연동
Auto Scaling으로 인스턴스가 늘어나면, **ELB(Elastic Load Balancer)**가 새 인스턴스에도 트래픽을 자동으로 분배한다.
[사용자 요청]
|
v
[ ELB ] ----------- Health Check
/ | \
/ | \
v v v
EC2 EC2 EC2 <-- Auto Scaling이 관리하는 인스턴스들
#1 #2 #3 (늘었다 줄었다 자동 조절)ELB와 Auto Scaling의 연동 포인트:
- Auto Scaling이 새 인스턴스를 생성하면 -> 자동으로 ELB의 대상 그룹(Target Group)에 등록
- Auto Scaling이 인스턴스를 제거하면 -> 자동으로 ELB의 대상 그룹에서 해제
- ELB의 상태 확인(Health Check) 결과를 Auto Scaling이 참고하여 비정상 인스턴스 교체
5. Auto Scaling 구성 요소 관계도
아래 다이어그램은 Auto Scaling을 구성하는 요소들이 어떻게 연결되는지 보여준다.
관계 요약:
- AMI + 사용자 데이터 + 보안 그룹 + 키 페어 -> 시작 템플릿에 합쳐진다.
- 시작 템플릿 -> Auto Scaling 그룹에서 사용한다.
- CloudWatch -> 모니터링 결과에 따라 Auto Scaling 그룹에 알람을 보낸다.
- Auto Scaling 그룹 -> EC2 인스턴스를 생성하거나 제거한다.
- ELB -> Auto Scaling 그룹이 관리하는 인스턴스들에 트래픽을 분배한다.
6. 스케일링 정책 (Scaling Policy) 상세
6-1. 스케일링 기준 지표
Auto Scaling은 **CloudWatch 지표(Metric)**를 기준으로 스케일링을 결정한다.
| 지표 | 설명 | 일반적 임계값 |
|---|---|---|
| 평균 CPU 사용률(Average CPU Utilization) | 그룹 내 인스턴스들의 평균 CPU 사용률 | 50~70% |
| 네트워크 입출력(Network In/Out) | 네트워크 트래픽 양 | 서비스마다 다름 |
| 요청 수(Request Count) | ELB가 받는 요청 수 | 서비스마다 다름 |
| 사용자 정의 지표(Custom Metric) | 직접 CloudWatch에 보내는 지표 | 자유 설정 |
6-2. 스케일링 유형
| 유형 | 설명 | 예시 |
|---|---|---|
| 대상 추적 스케일링(Target Tracking Scaling) | 목표 지표 값을 유지하도록 자동 조절 | "평균 CPU 50% 유지" |
| 단계 스케일링(Step Scaling) | 알람 심각도에 따라 다른 수의 인스턴스 추가 | CPU 70% -> +1대, CPU 90% -> +3대 |
| 단순 스케일링(Simple Scaling) | 알람 발생 시 정해진 수만큼 추가/제거 | CPU 70% 초과 -> +1대 |
| 예약 스케일링(Scheduled Scaling) | 미리 정해진 시간에 용량 변경 | "매주 월요일 09시에 5대로 확장" |
6-3. 용량 설정 예시
[실습 기준 설정]
최소 용량(Minimum): 1대
-> 트래픽이 아무리 줄어도 최소 1대는 항상 유지
-> 서비스가 완전히 중단되는 것을 방지
권장 용량(Desired): 1대
-> 평상시에 유지하고 싶은 인스턴스 수
-> Auto Scaling 그룹 생성 직후 이 수만큼 인스턴스가 생성됨
최대 용량(Maximum): 3대
-> 아무리 트래픽이 폭증해도 3대를 초과하지 않음
-> 비용 폭증을 방지하는 안전장치
스케일링 조건: 평균 CPU 사용률 10% 초과
-> 실습에서는 빠른 확인을 위해 낮은 값(10%)으로 설정
-> 실제 운영 환경에서는 50~70%가 일반적7. 스케일 아웃/인 타임라인
아래 다이어그램은 시간에 따른 인스턴스 수의 변화를 보여준다.
타임라인 설명:
| 시점 | 상태 | 인스턴스 수 | 설명 |
|---|---|---|---|
| 00:00 | 평상시 | 1대 | 최소 용량으로 안정 운영 |
| 00:15 | 부하 시작 | 1대 | yes > /dev/null 명령으로 CPU 100% 사용 |
| 00:20 | 스케일 아웃 1차 | 2대 | CloudWatch 알람 -> 인스턴스 1대 추가 |
| 00:30 | 스케일 아웃 2차 | 3대 | 여전히 CPU 높음 -> 인스턴스 1대 더 추가 (최대 도달) |
| 00:50 | 부하 제거 | 3대 | Ctrl+C로 부하 중단, CPU 급격히 하락 |
| 00:55~01:20 | 쿨다운(Cooldown) | 3대 | 안정화 확인 기간 (성급한 축소 방지) |
| 01:20 | 스케일 인 1차 | 2대 | 불필요한 인스턴스 1대 제거 |
| 01:30 | 스케일 인 완료 | 1대 | 최소 용량으로 복귀 |
참고: 스케일 아웃(확장)은 수 분 내로 빠르게 이루어지지만, 스케일 인(축소)은 쿨다운 기간(Cooldown Period) 때문에 약 15~30분 이상 걸린다. 이는 섣부른 축소로 인한 서비스 불안정을 방지하기 위한 안전장치이다.
8. 실습 흐름
실습 아키텍처
Step 1: AMI 생성
기존 EC2 인스턴스에 Apache 웹서버를 설치하고, 해당 상태를 AMI로 저장한다.
bash
# 1. EC2 인스턴스에 접속 (SSH)
ssh -i my-key.pem ec2-user@<인스턴스-퍼블릭-IP>
# 2. Apache 웹서버 설치
sudo yum install -y httpd
# 3. Apache 시작
sudo service httpd start
# 4. 부팅 시 자동 시작 설정
sudo chkconfig httpd on
# 5. 웹 브라우저에서 확인
# http://<인스턴스-퍼블릭-IP> 접속 -> Apache 테스트 페이지 표시AWS 콘솔에서 AMI 생성:
EC2 대시보드 -> 인스턴스 선택 -> 작업(Actions) -> 이미지 및 템플릿(Image and templates)
-> 이미지 생성(Create image)
- 이미지 이름: "my-apache-ami"
- 설명: "Apache 웹서버 설치됨"
-> [이미지 생성] 클릭Step 2: 시작 템플릿 생성
EC2 대시보드 -> 시작 템플릿(Launch Templates) -> 시작 템플릿 생성
설정:
- 템플릿 이름: "my-asg-template"
- AMI: 위에서 만든 "my-apache-ami" 선택
- 인스턴스 유형: t2.micro
- 키 페어: 기존 키 페어 선택
- 보안 그룹: HTTP(80), SSH(22) 허용된 보안 그룹
- 고급 세부 정보 -> 사용자 데이터(User Data):사용자 데이터에 입력할 스크립트:
bash
#!/bin/bash
sudo service httpd startStep 3: Auto Scaling 그룹 생성
EC2 대시보드 -> Auto Scaling 그룹 -> Auto Scaling 그룹 생성
1단계 - 시작 템플릿 선택:
- 그룹 이름: "my-asg"
- 시작 템플릿: "my-asg-template" 선택
2단계 - 네트워크 설정:
- VPC: 기본 VPC
- 가용 영역(AZ): 2개 이상 선택 (고가용성)
3단계 - 로드 밸런싱:
- "기존 로드 밸런서에 연결" 또는 "새 로드 밸런서 연결"
- Application Load Balancer 선택
- 대상 그룹 연결
4단계 - 그룹 크기 및 스케일링 정책:
- 최소 용량: 1
- 최대 용량: 3
- 권장 용량: 1
- 스케일링 정책: 대상 추적 스케일링
- 지표: 평균 CPU 사용률
- 대상 값: 10 (실습용으로 낮게 설정)
5단계 - 검토 후 생성Step 4: ELB 연동 확인
Auto Scaling 그룹 생성 시 ELB를 연결했다면, 자동으로 인스턴스가 대상 그룹에 등록된다.
확인 방법:
EC2 대시보드 -> 대상 그룹(Target Groups)
-> 대상(Targets) 탭에서 등록된 인스턴스 확인
-> 상태가 "healthy"인지 확인Step 5: CPU 부하 유발 -> 스케일 아웃 확인
Auto Scaling 그룹이 관리하는 EC2 인스턴스에 접속하여 CPU 부하를 인위적으로 발생시킨다.
bash
# EC2 인스턴스에 SSH 접속
ssh -i my-key.pem ec2-user@<인스턴스-퍼블릭-IP>
# CPU 100% 부하 유발 (yes 명령)
# yes는 끊임없이 "y"를 출력하는 명령어 -> CPU를 최대로 사용
yes > /dev/null &관찰:
1. CloudWatch에서 CPU 사용률이 급격히 상승하는 것을 확인
2. 약 3~5분 후 Auto Scaling 활동(Activity) 탭에서 새 인스턴스 시작 확인
3. EC2 대시보드에서 인스턴스가 2대 -> 3대로 늘어나는 것 확인
4. 대상 그룹에서 새 인스턴스가 자동 등록되는 것 확인Step 6: CPU 부하 제거 -> 스케일 인 확인
bash
# 부하를 유발한 EC2에서 yes 프로세스 종료
# 방법 1: 포그라운드라면
Ctrl+C
# 방법 2: 백그라운드라면
kill %1
# 또는
killall yes관찰:
1. CPU 사용률이 급격히 하락하는 것을 확인
2. 약 15~30분 후(쿨다운 기간) Auto Scaling이 인스턴스 축소 시작
3. 3대 -> 2대 -> 1대로 점진적으로 줄어드는 것 확인
4. 최종적으로 최소 용량(1대)만 남음주의: 스케일 인은 쿨다운 기간 때문에 스케일 아웃보다 훨씬 오래 걸린다. 실습 시 약 30분 정도 기다려야 완전히 1대로 복귀한다.
9. Auto Scaling 그룹 삭제
실습이 끝나면 반드시 Auto Scaling 그룹을 삭제해야 한다. 삭제하지 않으면 Auto Scaling이 관리하는 인스턴스가 계속 실행되어 비용이 발생한다.
삭제 순서
1. Auto Scaling 그룹 삭제
EC2 대시보드 -> Auto Scaling 그룹 -> "my-asg" 선택 -> 삭제
-> "내 Auto Scaling 그룹을 삭제하겠습니다" 확인
-> Auto Scaling이 관리하던 모든 인스턴스가 자동으로 종료(Terminate)됨!
2. 시작 템플릿 삭제 (선택)
EC2 대시보드 -> 시작 템플릿 -> "my-asg-template" -> 삭제
3. AMI 등록 취소 (선택)
EC2 대시보드 -> AMI -> "my-apache-ami" -> 등록 취소(Deregister)
4. ELB 삭제 (실습용으로 만들었다면)
EC2 대시보드 -> 로드 밸런서 -> 선택 -> 삭제
5. 대상 그룹 삭제 (실습용으로 만들었다면)
EC2 대시보드 -> 대상 그룹 -> 선택 -> 삭제가장 중요한 것은 1번(Auto Scaling 그룹 삭제)이다. Auto Scaling 그룹을 삭제하면 해당 그룹이 관리하는 모든 EC2 인스턴스가 자동으로 종료되므로, 이것만 삭제해도 비용 발생을 막을 수 있다.
10. 비용 관련 주의사항
비용 발생 구조
Auto Scaling 서비스 자체: 무료!
-> Auto Scaling 기능 사용에 대한 비용은 없다.
실제 비용이 발생하는 것:
-> Auto Scaling이 생성한 EC2 인스턴스의 시간당 요금
-> ELB 사용 요금
-> 데이터 전송 요금| 항목 | 비용 | 비고 |
|---|---|---|
| Auto Scaling 서비스 | 무료 | 기능 자체는 비용 없음 |
| EC2 인스턴스 (t2.micro) | 시간당 약 $0.0116 | 프리 티어: 월 750시간 무료 |
| Application Load Balancer | 시간당 약 $0.0225 | + LCU 사용량 |
| CloudWatch 기본 모니터링 | 무료 | 5분 간격, 기본 지표 |
주의할 점
감지/실행 지연: CloudWatch 알람이 발동하고 실제로 인스턴스가 추가되기까지 수 분이 걸린다. 갑작스러운 트래픽 급증(스파이크)에는 즉각 대응이 어렵다.
쿨다운 기간: 스케일링 활동 후 일정 시간(기본 300초) 동안 추가 스케일링을 하지 않는다. 이 기간 동안 불필요한 인스턴스가 유지될 수 있다.
최소 용량 비용: 최소 용량으로 설정한 인스턴스는 항상 실행되므로 항상 비용이 발생한다.
실습 후 삭제 필수: 실습이 끝나면 Auto Scaling 그룹을 반드시 삭제해야 한다. 삭제하지 않으면 최소 용량(1대)이 24시간 계속 실행된다.
11. 정리
핵심 요약
| 개념 | 한 줄 정리 |
|---|---|
| Auto Scaling | 트래픽에 따라 EC2 수를 자동으로 늘리고 줄이는 서비스 |
| AMI | Auto Scaling이 복제할 서버의 원본 이미지 |
| 시작 템플릿 | 새 인스턴스의 사양을 정의하는 설계도 |
| 사용자 데이터 | 인스턴스 부팅 시 자동 실행되는 스크립트 |
| Auto Scaling 그룹 | 최소/최대/권장 용량과 스케일링 정책을 관리하는 단위 |
| 스케일 아웃 | 인스턴스 추가 (부하 증가 시) |
| 스케일 인 | 인스턴스 제거 (부하 감소 시) |
| 쿨다운 | 성급한 스케일링 방지를 위한 대기 시간 |
기억해야 할 포인트
Auto Scaling = 클라우드의 핵심 장점. 필요할 때만 서버를 사용하고, 필요 없으면 자동으로 제거하여 비용을 최적화한다.
AMI가 핵심. AMI에 서비스에 필요한 모든 소프트웨어가 설치되어 있어야 Auto Scaling으로 생성된 새 인스턴스가 즉시 서비스에 투입될 수 있다.
ELB와 반드시 함께 사용. Auto Scaling으로 인스턴스가 늘어나도 ELB가 없으면 트래픽을 분배할 수 없다.
스케일 아웃은 빠르고, 스케일 인은 느리다. 확장은 수 분이면 되지만, 축소는 쿨다운 기간 때문에 15~30분 이상 걸린다.
실습 후에는 반드시 삭제! Auto Scaling 그룹을 삭제하면 관리 인스턴스도 함께 종료된다.