[Azure] Virtual Machine Scale Sets 정리

VMSS(Virtual Machine Scale Sets)는 같은 구성의 VM을 한 모델로 묶어 부하에 따라 대수를 늘리고 줄이며, 여러 가용성 영역에 나눠 배치하는 서비스입니다. 지금 새로 만든다면 Flexible 오케스트레이션이 기본이고, 이때는 기본 아웃바운드가 없어 NAT Gateway 같은 아웃바운드 경로를 따로 준비해야 합니다. 운영에서는 자동 크기 조정, 스케일 인 정책, Rolling 업그레이드, 자동 인스턴스 복구를 함께 설정합니다.

1. VMSS가 필요한 이유

웹 서버 VM 몇 대를 직접 만들어 Load Balancer 뒤에 두면 처음에는 문제가 없습니다. 하지만 트래픽이 늘 때 VM을 추가하고, 이미지와 설정을 맞추고, 장애가 난 VM을 교체하는 일이 모두 수작업이 됩니다. VMSS는 이미지, 크기, 네트워크, 확장(extension)으로 이루어진 VM 모델을 한 번 정의하고, 그 모델로 인스턴스를 늘리고 줄입니다.

 

항목	VM 개별 운영	VMSS
대수 조정	직접 만들고 삭제	규칙과 일정에 따라 자동
구성 일관성	VM마다 따로 관리	하나의 모델로 관리
영역 분산	VM마다 영역 지정	영역 1·2·3에 자동 분산
장애 VM 처리	직접 확인 후 교체	자동 인스턴스 복구로 교체
이미지·설정 변경	VM마다 적용	업그레이드 정책으로 일괄 적용

2. Flexible과 Uniform

Flexible 확장 집합이 영역 3개에 VM을 나눠 두고, 인바운드는 Load Balancer, 아웃바운드는 NAT Gateway로 처리하는 구성

 

오케스트레이션 모드는 만들 때 정하고 나중에 바꿀 수 없습니다. Microsoft는 새 배포에 Flexible을 권장합니다. Flexible의 인스턴스는 일반 Azure VM과 같은 리소스라서 az vm 명령, Azure Backup, 일반 VM API를 그대로 쓸 수 있습니다.

 

비교 항목	Flexible	Uniform
권장 여부	새 배포에 권장	기존 구성 호환용
최대 인스턴스	1,000대	100대
인스턴스 형태	일반 VM(az vm으로 관리)	확장 집합 전용 VM
VM 크기·Spot 혼합	가능	불가(모두 같은 구성)
기본 아웃바운드	없음(직접 구성)	있음
상태 확인	Application Health 확장	LB 상태 프로브 또는 Application Health 확장
이미지 기반 자동 OS 업그레이드	지원 안 함	지원
Azure Backup	지원	지원 안 함

Flexible에는 기본 아웃바운드가 없습니다. 또 2026년 3월 31일 이후 API로 만든 새 VNet은 서브넷이 기본으로 비공개 서브넷이라, 모드와 관계없이 명시적인 아웃바운드가 필요한 경우가 많습니다. 새 인스턴스에서 패키지 설치나 업데이트가 안 되면 가장 먼저 서브넷에 NAT Gateway나 Load Balancer 아웃바운드 규칙이 있는지 확인합니다.

3. 자동 크기 조정

평균 CPU에 따라 인스턴스를 늘리고 줄이는 규칙과, 스케일 인 때 삭제할 VM을 고르는 순서

 

Azure Monitor 자동 크기 조정은 최소, 최대, 기본 인스턴스 수를 정하고 그 범위 안에서 규칙에 따라 대수를 바꿉니다. 규칙은 확장 집합마다 최대 20개까지 둘 수 있습니다.

 

방식	동작	쓰는 경우
메트릭 기반	CPU, 네트워크, 디스크, Application Insights 지표가 임계값을 넘으면 늘리거나 줄임	부하를 예측하기 어려운 웹, API
일정 기반	정해 둔 시간에 대수를 바꿈	업무 시간, 이벤트처럼 예측 가능한 피크
예측	과거 CPU 사용 패턴으로 미리 늘림	주기적인 부하 패턴이 뚜렷한 경우

스케일 아웃 규칙과 스케일 인 규칙은 항상 짝으로 만들고, 두 임계값 사이에 충분한 간격을 둡니다. 예를 들어 70% 이상에서 늘리고 30% 이하에서 줄이는 식입니다. 간격이 좁으면 늘렸다 줄였다를 반복합니다. VM이 준비되기까지 오래 걸리는 앱이라면 미리 만들어 둔 VM을 대기시키는 스탠바이 풀(Flexible 전용)도 고려할 수 있습니다.

3.1 스케일 인 정책

정책	먼저 삭제하는 VM
Default	영역 간 균형 → 장애 도메인 간 균형 → 인스턴스 ID가 가장 큰 VM
NewestVM	영역 간 균형을 맞춘 뒤 가장 최근에 만든 VM
OldestVM	영역 간 균형을 맞춘 뒤 가장 오래된 VM

특정 VM이 스케일 인으로 삭제되지 않게 하려면 인스턴스 보호를 켭니다. 보호된 VM은 스케일 인 대상에서 빠지고, 사용자가 직접 삭제해야 합니다.

4. 업그레이드 정책과 자동 복구

이미지, VM 크기, 사용자 지정 데이터 같은 모델을 바꾸면 업그레이드 정책에 따라 기존 인스턴스에 반영됩니다.

 

정책	동작	권장 환경
Automatic	순서 보장 없이 모든 인스턴스를 한꺼번에 업데이트할 수 있음	개발, 테스트
Manual	사용자가 직접 업데이트, 새 인스턴스만 최신 모델	적용 시점을 직접 관리할 때
Rolling	배치 단위로 나눠 업데이트하며 정상 비율 유지	운영

Rolling은 인스턴스가 정상인지 알아야 하므로 Flexible에서는 Application Health 확장이 필요합니다. 같은 상태 정보로 자동 인스턴스 복구도 켤 수 있습니다. 상태 확인에 실패한 인스턴스는 유예 시간(10~90분, 기본 10분)이 지난 뒤 교체(기본), 재이미지, 재시작 중 하나로 복구되고, 한 번에 전체의 5%까지만 복구됩니다.

5. Azure CLI로 만들어 보기

5.1 네트워크와 NAT Gateway

RG=rg-vmss
az group create --name $RG --location koreacentral
az network vnet create --resource-group $RG --name vnet-app \
  --address-prefixes 10.1.0.0/16 --subnet-name snet-web --subnet-prefixes 10.1.1.0/24

# 아웃바운드: NAT Gateway를 서브넷에 연결
az network public-ip create --resource-group $RG --name pip-nat --sku Standard
az network nat gateway create --resource-group $RG --name nat-web \
  --public-ip-addresses pip-nat --idle-timeout 4
az network vnet subnet update --resource-group $RG --vnet-name vnet-app \
  --name snet-web --nat-gateway nat-web

5.2 Flexible 확장 집합

# cloud-init.yaml: nginx 설치와 상태 확인 경로
cat > cloud-init.yaml <<'EOF'
#cloud-config
packages: [nginx]
runcmd:
  - echo ok > /var/www/html/health
EOF

# 인스턴스 0대로 만들고, 확장과 정책을 먼저 설정한 뒤 늘림
az vmss create --resource-group $RG --name vmss-web \
  --orchestration-mode Flexible --platform-fault-domain-count 1 \
  --zones 1 2 3 --instance-count 0 \
  --image Ubuntu2404 --vm-sku Standard_D2s_v5 \
  --vnet-name vnet-app --subnet snet-web \
  --lb lb-web --lb-sku Standard --backend-pool-name bepool-web \
  --scale-in-policy OldestVM \
  --admin-username azureuser --generate-ssh-keys \
  --custom-data cloud-init.yaml

Load Balancer의 80 포트 규칙과 트래픽 분산용 상태 프로브는 Azure Load Balancer 정리의 명령으로 추가합니다.

5.3 상태 확장, Rolling, 자동 복구

az vmss extension set --resource-group $RG --vmss-name vmss-web \
  --name ApplicationHealthLinux --publisher Microsoft.ManagedServices --version 1.0 \
  --settings '{"protocol": "http", "port": 80, "requestPath": "/health"}'

az vmss update --resource-group $RG --name vmss-web \
  --set upgradePolicy.mode=Rolling \
  --enable-automatic-repairs true --automatic-repairs-grace-period 30

az vmss scale --resource-group $RG --name vmss-web --new-capacity 3

5.4 자동 크기 조정

az monitor autoscale create --resource-group $RG --resource vmss-web \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name as-web --min-count 3 --max-count 10 --count 3

az monitor autoscale rule create --resource-group $RG --autoscale-name as-web \
  --condition "Percentage CPU > 70 avg 5m" --scale out 2
az monitor autoscale rule create --resource-group $RG --autoscale-name as-web \
  --condition "Percentage CPU < 30 avg 10m" --scale in 1

부하 테스트 도구로 CPU를 올리면 5분 정도 뒤에 인스턴스가 늘어나고, 부하를 멈추면 10분 평균이 30% 아래로 내려간 뒤 한 대씩 줄어듭니다. az vmss list-instances로 영역별 인스턴스 수를 확인할 수 있습니다.

6. 운영 시 주의점

증상·항목	확인할 것
새 인스턴스에서 패키지 설치 실패	서브넷에 NAT Gateway나 LB 아웃바운드 규칙이 있는지 확인합니다. Flexible과 비공개 서브넷에는 기본 아웃바운드가 없습니다.
Rolling 업그레이드가 진행되지 않음	Application Health 확장이 모든 인스턴스에 있고 /health가 200을 반환하는지 확인합니다.
늘었다 줄었다를 반복	스케일 아웃과 인의 임계값 간격, 평가 시간을 넓힙니다.
필요한 VM이 스케일 인으로 삭제됨	인스턴스 보호를 켜거나 스케일 인 정책을 바꿉니다.
LB 상태 프로브	Flexible에서는 업그레이드와 복구 판단에 LB 프로브를 쓰지 않습니다. 분산용 프로브와 Application Health 확장을 따로 둡니다.
로컬에 저장한 데이터	인스턴스는 언제든 교체되거나 삭제될 수 있으므로 세션과 파일은 Redis, Storage 같은 외부 저장소에 둡니다.

7. 정리

• VMSS는 VM 모델 하나로 인스턴스를 늘리고 줄이며 영역에 나눠 배치하고, 새 배포는 Flexible이 기본입니다.
• Flexible은 기본 아웃바운드가 없으므로 NAT Gateway를 함께 구성하고, 상태 확인은 Application Health 확장으로 합니다.
• 자동 크기 조정 규칙은 짝으로 만들고 간격을 두며, 운영에서는 Rolling 업그레이드와 자동 인스턴스 복구를 켭니다.

참고

• Microsoft Learn - 확장 집합의 오케스트레이션 모드
• Microsoft Learn - 자동 크기 조정 개요
• 다이어그램 아이콘: Azure Architecture Icons