AWS Auto Scaling Groups - 스케일링 정책

동적 스케일링 정책

• Target Tracking Scaling
  • CPU 사용률이 40%에 머무를 수 있도록 할때 사용한다
  • 기본 기준선을 세워 상시 가용을 유지
• Simple / Step Scaling
  • CloudWatch를 설정하고 CPU 사용률 > 70%라면 유닛 하나 추가
  • CloudWatch를 설정하고 CPU 사용률 < 40%라면 유닛 하나 제거
  • CloudWatch 경보를 설정할 때는 한 번에 추가/제거할 유닛의 수를 단계별로 설정해야한다
• Scheduled Actions
  • 정해진 사용 패턴을 바탕으로 스케일링을 예상
  • 시간이나 특정 일같이 스케일링이 필요함을 미리 알 때에 예정된 작업을 설정하면 된다
• Predictive Scaling
  • AWS 내 오토 스케일링 서비스를 활용하여 로드를 보고서 다음 스케줄링을 예측
  • 머신러닝을 통해 사전에 스케일링 작업을 진행

스케일 조절할 때 대표적으로 좋은 지표

1. CPU 사용률
2. 대상별 요청수 (RequestCountPerTarget) → 한 번에 대상별로 1,000개의 요청까지만 최적으로 작동하므로 스케일링에 활용 가능

3개로 분산되기 때문에 RequestCountPerTarget은 3이다

3. Average Network In / Out

업로드와 다운로드가 많아 해당 네트워크에서 병목 현상이 발생할 것으로 판단되면 평균 네트워크 입출력량에 따라 스케일 가능

4. Any Custom metric - 사용자가 마음대로 커스텀 할 수 있다

Scaling Cooldowns

• 한번 스케일링 작업이 발생하면 설정에 따라 (기본 5분) 추가 인스턴스를 실행 또는 종료 불가
• 지표를 활용하여 새로운 인스턴스가 안정화 될 수 있도록 한다
• AMI 등으로 인스턴스 구성 요청을 빠르게 처리하는게 좋다
  • 활성화 시간을 빠르게 해야 휴지기간또한 줄어들어 더 많은 동적 스케일링이 가능

ASG 실습

동적 스케일링 / 예측 스케일링 / 예약 스케일링

예약 스케일링

예측 스케일링 - 기준에 따라 예측치 설정하여 스케일링

어느정도 돌린 후에 사용해야함

단순 스케일링

스텝 스케일링

타겟 트레킹 스케일링

sudo amazon-linux-extras install epel -y
sudo yum install stress -y

스트레스를 설정하여 실제로 스케일링이 잘 일어나는지 확인

원인을 보면 CloudWatch 알람이 울려서 새로운 EC2 인스턴스가 시작된다

CloudWatch

실제 CPU 사용률이 올라 실행되는 것까지 확인할 수 있다.

이후 사용률이 다시 안정화되면 인스턴스가 삭제되는데 실수로 정책을 삭제해버려서 동작까지 확인하지 못했다..

깨알 복습 - EC2 Connection Draining

종료가 안되길래 보니까 로드밸런서의 Connection Draining을 기다리고 있는것을 봤다.

Connection Draining은 이전글에 있으니 참고