ASG(Auto Scaling Group)?
실제 웹 사이트나 애플리케이션은 시간이 지남에 따라 로드가 변한다
- 로드❓
- 요청량(RPS, requests per second): 초당 들어오는 HTTP 요청 수
- 동시 연결/동시 사용자(concurrent users): 동시에 처리해야 하는 세션 수
- 리소스 사용량: 인스턴스의 CPU 사용률, 메모리 사용, 네트워크 대역폭, 디스크 I/O
- 지연시간(latency)과 에러율(5xx 등): 로드가 높아지면 응답 시간이 길어지고 에러가 늘어날 수 있음
aws에서는 ec2 인스턴스 생성 api 호출로 아주 빠르게 서버를 생성하고 제거할 수 있다
➡️ 이를 자동화 하기 위해서 ASG(Auto Scaling Group)을 쓰는 것
ASG의 특징
-
늘어난 로드에 맞춰 Scale Out(인스턴스 추가)
-
줄어든 로드에 맞춰 Scale in(인스턴스 제거)
-
전체적으로 매개변수를 정의해서 ASG에서 언제든 실행할 수 있는 최소 및 최대 EC2 인스턴스 수를 정할 수 있음
-
ASG와 로드 밸런서를 연결하면 ASG에 포함된 EC2 인스턴스가 로드 밸런서에 연결
-
어떤 인스턴스가 비정상이라고 여겨지면 이것을 종료하고 새 인스턴스를 만들어 대체
-
ASG는 무료이지만 그 아래 생성되는 EC2와 같은 리소스들에 대해서만 비용을 지불하면 됨
ASG의 동작 방식
- Minimum Capacity => ASG에 필요한 최소 인스턴스 수 설정
- Desired Capacity => 희망 인스턴스 수
- Maximum Capacity => ASG에 필요한 최대 인스턴스 수
로드밸런서 + ASG의 동작방식
ASG에 등록된 인스턴스가 4개면 ELB가 즉시 모든 인스턴스에 트래픽을 분산 => 사용자는 로드 밸런서 웹 사이트에 접속 가능
ELB 상태 확인 기능을 활용해서 EC2 인스턴스 상태도 점검 가능 => 상태 확인 결과는 ASG에 전달될 수 있음
➡️ 로드 밸런서가 EC2 인스턴스를 비정상이라고 여기면 ASG가 인스턴스를 종료할 수 있음
스케일 아웃(인스턴스 추가)을 하면 ELB가 마찬가지로 추가된 인스턴스에도 트래픽을 보내 부하를 분산시킴
ASG 속성 및 구성요소
-
Launch Template(옛 버전: Launch Configurations)
➡️ ASG에서 EC2 인스턴스를 시작하는 방법에 관한 정보가 있음- AMI
- 인스턴스 타입(유형)
- EC2 사용자 데이터
- EBS 볼륨
- 보안 그룹
- IAM 역할
- SSH 키페어
- 네트워크와 서브넷 정보
- 로드 밸런서 정보
등
-
최소 크기 / 최대 크키 / 초기 용량
-
스케일링 정책 정의해야 함
CloudWatch Alarms & Scaling
CloudWatch 경보를 기반으로 ASG에서 스케일 인, 스케일 아웃할 수 있음
클라우드 워치에서 평균 CPU를 관찰하거나, 사용자가 지정해준 지표를 검사하는 방식으로 임계점을 넘기면 알림을 울려 스케일 인, 아웃을 진행할 수 있다
ASG 실습
생성된 MyDemoTemplate 잘 출력되는 것 확인
기존에 만들어놓은 로드밸런서와도 연결
ASG가 EC2 인스턴스를 생성하기로 결정하면 작업 히스토리에 표시됨
Instance management 탭에서도 확인 가능
인스턴스 2개가 생긴 것 확인 가능
ASG 스케일링 정책
-
동적 스케일링(Dynamic Scaling)
-
목표 추적 스케일링(Target Tracking Scaling)
➡️ 설정이 매우 간단함
ex) CPU 사용률과 같은 ASG에 대한 메트릭을 정의하고 40%와 같은 목표값 정의 -
단순(Simple) / 단계(Step) 스케일링
➡️ CloudWatch Alarm이 반드시 필요
ex) CPU > 70% → 인스턴스 2개 추가
-
-
예약 스케일링(Scheduled Scaling)
➡️ 알려진 사용 패턴을 기반으로 스케일링을 예상
ex) 금요일 오후 5시에 매번 새로운 사용자가 발생 => 최소 용량을 10으로 증가 -
예측 스케일링(Predictive Scaling)
➡️ AWS 머신러닝이 지속적으로 트래픽 패턴을 예측해 자동으로 스케일링
반복되는 패턴이 있을 때 좋음
ex) 쇼핑몰, 월말 배치 작업 등
ASG Metrics
-
CPU 사용률(CPU Utilization)
➡️ 인스턴스가 요청을 받을 때마다 일반적으로 일종의 계산을 수행
모든 인스턴스의 평균 CPU 사용률을 살펴본 후 이 비율이 높아지면 인스턴스의 활용도가 더 높다는 의미 -
요청 수(Request Count)
➡️ 인스턴스 별 요청 count에 따라 스케일링을 진행하는 방식 -
네트워크 트래픽(Network In / Out)
➡️ 인스턴스가 보내거나 받는 데이터량을 기준으로 스케일링
ex) 업로드와 다운로드가 너무 많아 EC2 인스턴스에 병목현상이 발생될 것이라 예상된다면,
평균 네트워크 사용량을 기준으로 스케일링을 설정하는 것이 좋다 -
사용자 정의 지표(Custom Metrics)
➡️ CloudWatch에 직접 지표를 만들어서 ASG 스케일링 기준으로 쓸 수 있음
ex) 큐 길이(SQS 메시지 수), 애플리케이션 처리율, DB 연결 수 등
Scaling Cooldowns
➡️ ASG에서 인스턴스를 추가하거나 제거한 후 일정 시간 동안 추가 스케일링을 막는 시간 / 서버를 늘렸는데 바로 다시 늘리는 상황을 막기 위한 “안정화 시간” 같은 개념
➡️ 기본적으로 5분의 쿨다운 시간이 적용됨
💡 서버를 바로 띄울 수 있는 AMI를 쓰면, 서버 세팅 시간을 줄여서 요청을 더 빨리 처리할 수 있고, ASG의 cooldown 시간도 줄일 수 있다
WHY❓
➡️ ASG가 새 EC2를 추가할 때 서버가 준비되는 시간이 길면 cooldown 동안 충분히 효과를 발휘하지 못할 수 있음
이미 설정이 끝난 AMI를 사용하면 서버가 바로 준비되기 때문에
1. 사용자 요청을 빨리 처리 가능
2. ASG가 다음 스케일링을 판단할 때 cooldown 시간도 최소화 가능
Instance Refresh(인스턴스 새로고침)
➡️ ASG 안에 있는 기존 EC2 인스턴스를 순차적으로 종료하고 새 인스턴스로 교체하는 기능
➡️ 새 AMI로 업데이트하거나 설정 변경 후, 모든 인스턴스를 최신 상태로 맞추고 싶을 때 사용
➡️ 새로 생성된 EC2 인스턴스가 실제 트래픽을 처리할 준비가 되는 시간인 Warm-up Time 지정 가능
- 사용 목적
-
AMI 업데이트 반영
기존 인스턴스는 오래된 AMI로 만들어져 있을 수 있음
새 AMI로 교체하여 보안 패치, 소프트웨어 버전 업데이트 등 적용 가능 -
구성 변경 반영
Launch Template이나 Launch Configuration 변경 후, ASG 내 모든 인스턴스를 새 설정으로 맞추고 싶을 때
-
건강한 상태 유지
일부 인스턴스가 오래되거나 문제 있을 때, 점진적으로 교체하면서 서비스 중단 최소화
-
주요 옵션
옵션 설명 MinHealthyPercentage 교체 진행 시 최소 몇 % 인스턴스가 정상이어야 하는지 설정 Instance Warm-up 새 인스턴스가 준비되는 시간(Helth 체크까지 대기) Auto Scaling group selection 특정 ASG만 새로고침 가능
