자동 확장의 개념은 간단해 보인다. CPU가 높으면 서버를 더 추가하고, 낮으면 줄인다. 그런데 실제로 구현하다 보면 생각지 못한 문제들이 생긴다. 새 인스턴스가 뜨는 2분 동안 CPU가 100%로 치솟아 다시 스케일아웃이 트리거된다. 종료되는 인스턴스에서 처리 중이던 주문이 사라진다. 매일 오전 9시에 사용자가 몰리는데 Target Tracking은 이미 CPU가 높아진 후에야 반응한다.
이 글은 AWS Auto Scaling Group(ASG)이 이런 문제들을 어떻게 해결하는지, 그 내부 설계 원리와 제어 이론적 배경까지 다룬다. 스케일링 정책 4종의 수학적 차이, Lifecycle Hook의 활용 패턴, Warm Pool의 경제학, Predictive Scaling의 ML 모델까지 이해하면 시험 시나리오뿐 아니라 실제 프로덕션 설계에도 바로 쓸 수 있다.
2008년 이전 웹 서비스는 피크 부하를 감당하기 위해 항상 최대 용량의 서버를 켜두어야 했다. Netflix가 DVD 대여 웹사이트였을 때, 금요일 저녁 트래픽을 위해 평일 낮에도 같은 수의 서버를 유지했다. 이것은 낭비였다.
2009년 AWS Auto Scaling 출시로 이 패러다임이 바뀌었다. 트래픽에 따라 인스턴스 수를 자동 조절할 수 있게 됐다