Azure App Service의 자동 크기 조정
참고 항목
자동 스케일링은 Windows 및 Linux(코드 및 컨테이너로 배포)용 앱을 비롯한 모든 앱 유형에 사용할 수 있습니다. 배포 슬롯 트래픽에는 자동 크기 조정이 지원되지 않습니다.
자동 스케일 아웃은 웹앱 및 App Service 요금제에 대한 크기 조정 결정을 자동으로 처리하는 새 스케일 아웃 옵션입니다. 일정과 리소스를 기반으로 크기 조정 규칙을 정의할 수 있는 기존의 Azure 자동 크기 조정과 다릅니다. 자동 크기 조정을 사용하면 크기 조정 설정을 조정하여 앱 성능을 개선하고 콜드 부팅 문제를 방지할 수 있습니다. 플랫폼은 스케일 아웃 시 버퍼 역할을 하도록 인스턴스를 미리 준비하여 원활한 성능 전환을 보장합니다. 미리 준비 인스턴스를 포함하여 모든 인스턴스에 대해 초당 요금이 청구됩니다.
App Service에서 사용할 수 있는 스케일 아웃 및 스케일 인 옵션 비교:
| 수동 | Autoscale | 자동 크기 조정 | |
|---|---|---|---|
| 사용 가능한 가격 책정 계층 | 기본 및 위쪽 | 표준 및 위쪽 | 프리미엄 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 요금제)을 선택합니다. 자동을 선택하고 최대 버스트 값을 업데이트한 다음, 저장 단추를 선택합니다.
최소 웹앱 인스턴스 수 설정
항상 준비된 인스턴스는 최소 인스턴스 수를 지정하는 앱 수준 설정입니다. 로드가 항상 준비된 인스턴스가 처리할 수 있는 수준을 초과하는 경우 추가 인스턴스가 추가됩니다(App Service 요금제에 대해 지정된 최대 버스트까지).
최소 웹앱 인스턴스 수를 설정하려면 웹앱의 왼쪽 메뉴로 이동하고 스케일 아웃(App Service 요금제)을 선택합니다. 항상 준비된 인스턴스 값을 업데이트하고 저장 단추를 선택합니다.
최대 웹앱 인스턴스 수 설정
최대 확장 제한은 웹앱이 확장할 수 있는 최대 인스턴스 수를 설정합니다. 최대 크기 제한은 데이터베이스와 같은 다운스트림 구성 요소의 처리량이 제한된 경우에 도움이 됩니다. 앱당 최대값은 1에서 최대 버스트 사이일 수 있습니다.
최대 웹앱 인스턴스 수를 설정하려면 웹앱의 왼쪽 메뉴로 이동하고 스케일 아웃(App Service 요금제)을 선택합니다. 스케일 아웃 제한 적용을 선택하고 최대 확장 제한을 업데이트한 다음, 저장 단추를 선택합니다.
미리 준비된 인스턴스 업데이트
미리 준비된 인스턴스 설정은 HTTP 스케일링 및 활성화 이벤트 중에 준비된 인스턴스를 버퍼로 제공합니다. 미리 준비된 인스턴스는 최대 스케일 아웃 제한에 도달할 때까지 버퍼링됩니다. 기본 미리 준비된 인스턴스 수는 1이며, 대부분의 시나리오에서 이 값은 1로 유지되어야 합니다.
포털에서 미리 준비된 인스턴스 설정을 변경할 수 없으며, 대신 Azure CLI를 사용해야 합니다.
자동 크기 조정 사용 안 함
자동 스케일링을 사용하지 않도록 설정하려면 웹앱의 왼쪽 메뉴로 이동하고 스케일 아웃(App Service 요금제)을 선택합니다. 수동을 선택하고 저장 단추를 선택합니다.
자동 크기 조정이 Azure Function 앱을 지원하나요?
주의
App Service 웹앱 및 Azure 함수 앱이 동일한 App Service 요금제에 있는 경우 자동 스케일링을 사용할 수 없습니다.
아니요, 자동 크기 조정을 사용하도록 설정하려는 App Service 요금제에 Azure App Service 웹앱만 사용할 수 있습니다. Functions의 경우 대신 Azure Functions 프리미엄 요금제를 사용하는 것이 좋습니다.
자동 ㅅ케일링은 백그라운드에서 어떻게 작동하나요?
자동으로 스케일링되도록 설정된 애플리케이션은 지속적으로 모니터링되며 작업자 상태 평가는 몇 초마다 한 번 이상 발생합니다. 시스템에서 애플리케이션의 부하 증가를 감지하면 상태 검사가 더 자주 진행됩니다. 작업자 상태가 악화되고 요청이 느려지는 경우 추가 인스턴스가 요청됩니다. 인스턴스가 추가되는 속도는 개별 애플리케이션의 부하 패턴 및 시작 시간에 따라 달라집니다. 빠르게 시작하고 간헐적인 부하가 발생하는 애플리케이션은 몇 초 또는 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 앱을 선택하고 설정아래에서 구성선택합니다. 다음으로, 일반 설정 탭을 선택합니다. ARR 선호도 에서 끄기 선택한 다음, 저장 단추를 선택합니다.