EC2 인스턴스 한 대를 껐는데 잠시 후 새 인스턴스가 생겼다면, Auto Scaling이 말을 안 듣는 게 아니다. 그룹이 유지하려는 **원하는 용량(desired capacity)**이 여전히 1이기 때문이다. 현재 보이는 대수와 그룹이 목표로 하는 대수를 구분하면 이 동작이 이해된다.
Auto Scaling의 최소·원하는·최대 용량은 어떻게 다른가?
Auto Scaling 그룹은 시작 템플릿으로 인스턴스를 만들고, 그룹의 크기를 설정된 범위 안에서 조절한다. 세 숫자는 각자 역할이 다르다.
| 설정 | 예시 | 뜻 |
|---|---|---|
| 최소 용량 | 1 | 축소해도 남길 하한 |
| 원하는 용량 | 1 | 지금 유지하려는 목표 |
| 최대 용량 | 2 | 확장할 수 있는 상한 |
최소 ≤ 원하는 ≤ 최대여야 한다. 처음에는 한 대가 정상이다. 부하에 따라 확장 정책이 목표를 2로 바꾸면 새 인스턴스를 시작할 수 있지만, 최대 용량이 2이므로 그 이상은 늘리지 않는다. 최대 용량은 ‘평소 대수’가 아니라 넘지 않을 경계다.
아래 그림도 처음 목표인 1대를 가운데에 놓고, 아래·위 경계가 어디인지 보여 준다.
인스턴스를 직접 종료했는데 왜 다시 생길까?
위 설정에서 실행 중인 한 대를 직접 종료해 보자. 그룹은 원하는 1대와 실제 0대의 차이를 보고 다시 한 대를 채우려 한다. 인스턴스 종료와 그룹의 원하는 용량 변경은 다른 작업이다. 이 예시는 동작을 설명하기 위한 것이며 실제 계정에서 종료 실험을 권하는 절차는 아니다.
| 순서 | 실제 대수 | 원하는 대수 | 확인할 곳 |
|---|---|---|---|
| 시작 | 1 | 1 | 그룹 용량 |
| 인스턴스 종료 직후 | 0 | 1 | 그룹 활동 기록 |
| 대체 인스턴스 시작 후 | 1 | 1 | 인스턴스 상태·대상 그룹 상태 |
인스턴스가 다시 보인다고 요청을 곧바로 받을 수 있는 것은 아니다. 시작 템플릿과 AMI가 올바른지, 로드 밸런서의 대상 그룹에 연결됐는지, 상태 검사를 통과했는지까지 확인해야 한다. 그룹 활동 기록은 ‘왜 새로 만들었는지’를, 대상 그룹 상태는 ‘트래픽을 받을 준비가 됐는지’를 나눠 보여 준다.
CPU가 높아도 확장되지 않을 때 무엇을 볼까?
먼저 실제 대수와 최소·원하는·최대 용량을 함께 본다. 이미 2대라면 이 예시의 최대 용량 때문에 추가 확장이 막힌다. 1대라면 크기 조정 정책이 붙어 있는지, 정책이 보는 지표가 예상한 지표인지, 그룹 활동 기록에 실패 이유가 있는지 확인한다. CPU 그래프 한 장만 보고 Auto Scaling이 고장 났다고 결론 내리기에는 이르다.
확장에 성공한 다음에도 서비스가 일관된지는 별도 문제다. 두 인스턴스가 각각 로컬 데이터베이스에 글을 저장하면, 로드 밸런서가 어느 쪽으로 보냈는지에 따라 새 글이 보였다 안 보였다 할 수 있다. 인스턴스 수를 늘리는 설정만으로 데이터가 공유되지는 않는다. 공유 저장소나 외부 데이터베이스를 쓰는지 먼저 확인해야 한다.
운영 용량은 어떻게 정할까?
최소 용량은 평소 필요한 처리 여유와 연결되고, 최대 용량은 부하 대응 범위와 비용 상한에 연결된다. 이 예시처럼 최소 1대라면 그 한 대에 장애가 난 뒤 대체 인스턴스가 준비될 때까지 처리 여유가 없다. 최대값을 높이기 전에 새 인스턴스가 실제로 준비되는 시간, 대상 그룹의 상태 검사, 데이터 저장 위치를 함께 점검하자. 반대로 점검 중 대수를 줄이려면 인스턴스만 종료하지 말고 그룹의 목표와 트래픽 전환 계획을 같이 바꿔야 한다.
핵심 요약
최소 용량은 하한, 원하는 용량은 현재 목표, 최대 용량은 상한이다. 인스턴스를 직접 종료해도 원하는 용량이 그대로면 그룹은 대체 인스턴스를 만들려고 한다. 문제가 생기면 세 용량 → 그룹 활동 기록 → 인스턴스·대상 그룹 상태 → 애플리케이션 데이터 순서로 확인하자.
