When to use
CPU 사용량, 네트워크 I/O Bytes, Integration Latency 등이 급증했을 때 서비스가 죽지않고 자동 스케일 아웃 되게 하고싶을 때
CloudWatch Alarm 으로 알람으로 상황을 알림받고 EC2 Auto Scaling 으로 인스턴스를 늘려 자동으로 대비할 수 있다.
Scaling Policy
Simple scaling
1. ChangeInCapacity
CloudWatch 알람이 울리면 지정한 갯수만큼 (용량 단위, 2개) 원하는 용량을 늘린다.
아래 정책에 따르면 알람이 울렸을 때 1->3 으로 증가한다.
2. ExactInCapcity
이제 안쓴다고 보면된다.
무조건 알람울리면 Desired Capacity 를 N으로 변경하도록 하는 방식
3. PercentInCapacity
현재 Desired Capacity 값을 고려하여 몇 % 증량 혹은 감소 할 것인지다.
변경 전 원하는 용량이 4고, 그룹 백분율이 50%인 경우
알람이 울렸을 때 4*50% 인 2만큼 원하는 용량이 증가한다.
| Index | 변경 전 | 변경 후 |
|---|---|---|
| 최소 용량 | 1 | 1 |
| 원하는 용량 | 4 | 6 |
| 최대용량 | 10 | 10 |
📝 쿨타임 동안에는 알람이 울려도 스케일이 되지 않는다.
📝 Maximum Capacity (최대 용량) 내에서만 증량가능하다.
Step scaling
마찬가지로 증감 갯수 또는 백분율 지정이 가능하다.
최소값과 최대값을 포함한 경계값을 여러개 지정할 수 있고 구간별로 몇개씩 증감할 것인지 설정할 수 있다.
Warming up time 의 기본값은 0으로 따로 쿨타임이 없다. 경계값을 넘나들 때 스케일 인-아웃을 일정 시간 쉬게하고 싶다면 이 값을 설정해야한다.
Target tracking scaling
다음과 같은 항목에 따라 자동으로 스케일 인/아웃된다.
- 평균 CPU 사용률
- 평균 네트워크 I/O Bytes
- 대상당 ALB 요청 수
알아서 지표의 평균값, 요청 수 값을 조절할 정도로만 스케일링한다.
Step Scaling 보다 간단하다.
간단한 만큼 Step scaling 처럼 여러 구간을 나눠 세심한 컨트롤을 할 수 없다는게 단점이다.
🔗 Reference
