참고
자동 스케일링은 Windows 및 Linux(코드 및 컨테이너로 배포)용 앱을 비롯한 모든 앱 유형에 사용할 수 있습니다. 자동 크기 조정은 배포 슬롯 트래픽에 대해 지원되지 않습니다.
자동 크기 조정은 웹앱 및 App Service 계획에 대한 크기 조정 결정을 자동으로 처리하는 스케일 아웃 옵션입니다. 일정 및 리소스에 따라 크기 조정 규칙을 정의할 수 있는 Azure 자동 크기 조정과 다릅니다.
자동 크기 조정을 사용하면 크기 조정 설정을 조정하여 앱 성능을 개선하고 콜드 부팅 문제를 방지할 수 있습니다. 플랫폼은 스케일 아웃 시 버퍼 역할을 하도록 인스턴스를 미리 준비하여 원활한 성능 전환을 보장합니다. 미리 준비 인스턴스를 포함하여 모든 인스턴스에 대해 초당 요금이 청구됩니다.
다음 표에서는 App Service에서 사용할 수 있는 스케일 아웃 및 스케일 인 옵션을 비교합니다.
| 수동 | 자동 크기 조정 | 자동 크기 조정 | |
|---|---|---|---|
| 사용 가능한 가격 책정 계층 | 기본 및 위쪽 | 표준 이상 | 프리미엄 V2(P1V2, P2V2 및 P3V2) 가격 책정 계층. 프리미엄 V3(P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3 및 P5MV3) 가격 책정 계층. |
| 규칙 기반 크기 조정 | 아니오 | 예 | 아니요, 플랫폼은 HTTP 트래픽을 기반으로 스케일 아웃 및 스케일 인을 관리합니다. |
| 일정 기반 크기 조정 | 아니오 | 예 | 아니오 |
| 항상 준비된 인스턴스 | 아니요, 웹앱은 수동으로 크기가 조정된 인스턴스 수에서 실행됩니다. | 아니요, 웹앱은 자동 크기 조정 규칙에 대해 정의된 임계값에 따라 스케일 아웃 작업 중에 사용할 수 있는 다른 인스턴스에서 실행됩니다. | 예(최소 1) |
| 미리 준비된 인스턴스 | 아니오 | 아니오 | 예(기본값 1) |
| 앱별 최대값 | 아니오 | 아니오 | 예 |
자동 크기 조정 작동 방식
App Service 계획에 대해 자동 크기 조정을 사용하도록 설정하고 각 웹앱에 대한 인스턴스 범위를 구성합니다. 웹앱이 HTTP 트래픽을 수신하기 시작하면 App Service는 부하를 모니터링하고 인스턴스를 추가합니다. App Service 계획 내의 여러 웹앱을 동시에 스케일 아웃해야 하는 경우 리소스를 공유할 수 있습니다.
다음은 자동으로 스케일 아웃해야 하는 몇 가지 시나리오입니다.
- 리소스 메트릭을 기반으로 자동 크기 조정 규칙을 설정하지 않으려고 합니다.
- 동일한 App Service 계획 내의 웹앱이 서로 다르게 독립적으로 확장되도록 합니다.
- 웹앱이 데이터베이스 또는 레거시 시스템에 연결되어 있으므로 웹앱만큼 빠르게 확장되지 않을 수 있습니다. 크기를 자동으로 조정하면 App Service 계획이 확장할 수 있는 최대 인스턴스 수를 설정할 수 있습니다. 이 설정은 웹앱이 백 엔드를 압도하지 않도록 하는 데 도움이 됩니다.
자동 크기 조정 사용
최대 버스트 설정은 들어오는 HTTP 요청에 따라 App Service 계획이 늘릴 수 있는 가장 많은 인스턴스 수를 나타냅니다. 프리미엄 v2 및 v3 플랜의 경우 최대 30개의 인스턴스를 지정할 수 있습니다. 최대 버스트 수는 App Service 계획에 지정된 작업자 수보다 크거나 같아야 합니다.
자동 크기 조정을 사용하도록 설정하려면 웹앱의 왼쪽 메뉴로 이동합니다. 설정에서 스케일 아웃(App Service 계획)을 선택합니다. 자동을 선택하고 최대 버스트 값을 업데이트한 다음, 저장 단추를 선택합니다.
최소 웹앱 인스턴스 수 설정
앱 수준 설정 Always ready 인스턴스는 최소 인스턴스 수를 지정합니다. 부하가 Always ready 인스턴스에서 설정된 최소 수를 초과하면 App Service 계획에 대해 지정된 최대 버스트 값까지 추가 인스턴스가 추가됩니다.
최소 웹앱 인스턴스 수를 설정하려면 웹앱의 왼쪽 메뉴로 이동하여 스케일 아웃(App Service 계획)을 선택합니다. 항상 준비된 인스턴스 값을 업데이트하고 저장 단추를 선택합니다.
최대 웹앱 인스턴스 수 설정
최대 크기 조정 제한 값은 웹앱이 확장할 수 있는 최대 인스턴스 수를 설정합니다. 최대 크기 제한은 데이터베이스와 같은 다운스트림 구성 요소의 처리량이 제한된 경우에 유용합니다. 앱당 최대값은 1에서 최대 버스트 값 사이일 수 있습니다.
최대 웹앱 인스턴스 수를 설정하려면 웹앱의 왼쪽 메뉴로 이동하여 스케일 아웃(App Service 계획)을 선택합니다. 스케일 아웃 제한 적용을 선택하고 최대 확장 제한을 업데이트한 다음, 저장 단추를 선택합니다.
미리 준비된 인스턴스 업데이트
사전 준비된 인스턴스 설정은 HTTP 크기 조정 및 활성화 이벤트 중 버퍼로 워밍업된 인스턴스를 제공합니다. 미리 준비된 인스턴스는 최대 스케일 아웃 제한에 도달할 때까지 버퍼링됩니다. 기본 미리 준비된 인스턴스 수는 1 이며, 대부분의 시나리오에서 이 값은 1로 유지되어야 합니다.
포털에서 미리 빌드된 인스턴스 설정을 변경할 수 없습니다. 대신 Azure CLI를 사용해야 합니다.
자동 크기 조정 사용 안 함
자동 크기 조정을 사용하지 않도록 설정하려면 웹앱의 왼쪽 메뉴로 이동하여 스케일 아웃(App Service 계획)을 선택합니다. 수동을 선택하고 저장 단추를 선택합니다.
자주 묻는 질문
자동 크기 조정이 Azure Functions 앱을 지원하나요?
아니요, 자동 크기 조정을 사용하도록 설정하려는 App Service 계획에 Azure App Service 웹앱만 포함할 수 있습니다. Azure Functions 앱의 경우 대신 Azure Functions Premium 계획을 사용하는 것이 좋습니다.
주의
App Service 웹앱 및 Azure Functions 앱이 동일한 App Service 계획에 있는 경우 자동 크기 조정을 사용할 수 없습니다.
자동 스케일링은 배후에서 어떻게 작동하는지 설명합니다.
자동으로 스케일링되도록 설정된 애플리케이션은 지속적으로 모니터링되며 작업자 상태 평가는 몇 초마다 한 번 이상 발생합니다. 시스템에서 애플리케이션의 부하 증가를 감지하면 상태 검사가 더 자주 진행됩니다. 작업자 상태가 악화되고 요청 속도가 느려지면 다른 인스턴스가 요청됩니다. 인스턴스가 추가되는 속도는 개별 애플리케이션의 부하 패턴 및 시작 시간에 따라 달라집니다. 짧은 시작 시간과 간헐적인 부하 버스트가 있는 애플리케이션은 몇 초에서 1분마다 하나의 가상 머신이 추가될 수 있습니다.
부하가 감소하면 플랫폼은 잠재적 스케일 인이 필요한지 검토하기 시작합니다. 이 프로세스는 일반적으로 부하 증가가 중지된 후 약 5-10분 후에 시작됩니다. 스케일 인하는 동안 인스턴스는 몇 초~1분 사이의 최대 속도로 제거됩니다.
동일한 App Service 계획 내에 여러 웹 애플리케이션이 배포된 경우 플랫폼은 사용 가능한 인스턴스 간에 리소스를 할당하려고 시도합니다. 이 할당은 각 개별 웹 애플리케이션의 부하를 기반으로 합니다.
미리 준비된 인스턴스에 대한 요금은 어떻게 청구하나요?
미리 준비된 인스턴스에 대한 요금이 청구되는 방식을 이해하려면 다음 시나리오를 고려합니다. 웹앱에 항상 준비 완료된 5개의 인스턴스와 기본값으로 설정된 하나의 미리 준비된 인스턴스가 있다고 가정해 보겠습니다.
웹앱이 유휴 상태이고 HTTP 요청을 받지 못하는 경우 항상 준비 완료된 5개의 인스턴스로 실행됩니다. 현재는 항상 준비 완료된 인스턴스가 사용되지 않고 미리 준비된 인스턴스가 할당되지 않았으므로 미리 준비된 인스턴스에 대한 요금이 청구되지 않습니다.
그러나 웹앱이 HTTP 요청을 수신하기 시작하고 항상 준비된 5개의 인스턴스가 활성화되는 즉시 미리 준비된 인스턴스가 할당됩니다. 청구는 이 시점에서 시작됩니다.
HTTP 요청 속도가 계속 증가하고 App Service가 초기 5개 인스턴스를 초과하여 확장하기로 결정하면 미리 설치된 인스턴스를 활용하기 시작합니다. 즉, 활성 인스턴스가 6개인 경우 미리 준비된 버퍼를 채우기 위해 7번째 인스턴스가 즉시 프로비전됩니다.
이 스케일링 및 미리 준비 프로세스는 앱의 최대 인스턴스 수에 도달할 때까지 계속됩니다. 최대 인스턴스 수를 초과하여 미리 준비되거나 활성화된 인스턴스는 없다는 점에 유의해야 합니다.
AppServiceHTTPLogs 로그 항목이 404 상태와 유사한 /admin/host/ping 이유는 무엇인가요?
App Service 자동 크기 조정은 플랫폼의 다른 상태 검사 메커니즘과 함께 /admin/host/ping 엔드포인트를 주기적으로 확인합니다. 경우에 따라 기존 플랫폼 구성으로 인해 이러한 ping은 404 오류를 반환할 수 있습니다. 그러나 이러한 404 오류는 앱의 가용성 또는스케일링 성능에 영향을 주지 않아야 합니다.
웹앱이 5xx 상태를 반환하는 경우 이러한 엔드포인트 ping으로 인해 일시적인 다시 시작이 발생할 수 있지만 이 시나리오는 일반적이지 않습니다. 웹앱이 이 엔드포인트에서 5xx 상태를 반환하지 않는지 확인합니다. 이러한 ping 엔드포인트는 사용자 지정할 수 없습니다.
자동 크기 조정 이벤트 중에 스케일 아웃 인스턴스 수를 추적하려면 어떻게 해야 하나요?
메트릭은 AutomaticScalingInstanceCount 앱이 배포된 경우 미리 생성된 인스턴스를 포함하여 앱이 실행 중인 가상 머신의 수를 보고합니다. 이 메트릭을 사용하여 자동 크기 조정 이벤트 중에 웹앱이 확장된 최대 인스턴스 수를 추적할 수도 있습니다. 이 메트릭은 자동 크기 조정 을 사용하도록 설정된 앱에만 사용할 수 있습니다.
ARR 선호도는 자동 크기 조정에 어떤 영향을 주나요?
Azure App Service는 ARR 선호도라고 하는 애플리케이션 요청 라우팅 쿠키를 사용합니다. ARR 선호도 쿠키는 사용 가능한 인스턴스가 아닌 쿠키와 연결된 서버에만 요청을 보내기 때문에 스케일링을 제한합니다. 상태를 저장하는 앱의 경우 스케일 업하는 것이 좋습니다(단일 인스턴스에서 리소스 늘리기). 상태 비저장 앱의 경우스케일 아웃(인스턴스 더 추가)을 통해 유연성과 스케일링 기능이 향상됩니다. ARR 선호도 쿠키는 App Service에서 기본적으로 사용하도록 설정됩니다. 애플리케이션 요구 사항에 따라 자동 크기 조정을 사용할 때 ARR 선호도 쿠키를 사용하지 않도록 선택할 수 있습니다.
ARR 선호도 쿠키를 사용하지 않도록 설정하려면 App Service 앱을 선택하고 설정아래에서 구성선택합니다. 다음으로 일반 설정 탭을 선택합니다. 세션 선호도에서 끄기를 선택한 다음 저장 단추를 선택합니다.