Automatisk skalning i Azure App Service
Kommentar
Automatisk skalning är tillgänglig för alla apptyper: Windows och Linux (distribuera som kod och container). Automatisk skalning stöds inte för distributionsfacktrafik.
Automatisk skalning är ett nytt skalningsalternativ som automatiskt hanterar skalningsbeslut för dina webbappar och App Service-planer. Det skiljer sig från den befintliga autoskalningen i Azure, där du kan definiera skalningsregler baserat på scheman och resurser. Med automatisk skalning kan du justera skalningsinställningarna för att förbättra appens prestanda och undvika problem med kallstart. Plattformen förinstallerar instanser för att fungera som en buffert vid utskalning, vilket säkerställer smidiga prestandaövergångar. Du debiteras per sekund för varje instans, inklusive förvärmade instanser.
En jämförelse av utskalning och skalning av tillgängliga alternativ i App Service:
| Manuell | Automatisk skalning | Automatisk skalning | |
|---|---|---|---|
| Tillgängliga prisnivåer | Grundläggande och uppåt | Standard och Upp | Prisnivåer för Premium V2 (P1V2, P2V2, P3V2) och Premium V3 (P0V3, P1V3, P2V3, P3V3, P1MV3, P2MV3, P3MV3, P4MV3, P5MV3) |
| Regelbaserad skalning | Nej | Ja | Nej, plattformen hanterar utskalningen och in baserat på HTTP-trafik. |
| Schemabaserad skalning | Nej | Ja | Nej |
| Alltid redo instanser | Nej, webbappen körs på antalet manuellt skalbara instanser. | Nej, webbappen körs på andra instanser som är tillgängliga under utskalningsåtgärden, baserat på tröskelvärdet som definierats för regler för autoskalning. | Ja (minst 1) |
| Förinställda instanser | Nej | Nej | Ja (standard 1) |
| Maximalt per app | Nej | Nej | Ja |
Så här fungerar automatisk skalning
Du aktiverar automatisk skalning för en App Service-plan och konfigurerar ett antal instanser för var och en av webbapparna. När webbappen börjar ta emot HTTP-trafik övervakar App Service belastningen och lägger till instanser. Resurser kan delas när flera webbappar i en App Service-plan krävs för att skala ut samtidigt.
Här följer några scenarier där du bör skala ut automatiskt:
- Du vill inte konfigurera regler för autoskalning baserat på resursmått.
- Du vill att dina webbappar inom samma App Service-plan ska skalas olika och oberoende av varandra.
- Webbappen är ansluten till en databas eller ett äldre system som kanske inte skalas lika snabbt som webbappen. Med skalning kan du automatiskt ange det maximala antalet instanser som apptjänstplanen kan skala till. Den här inställningen hjälper webbappen att inte överbelasta serverdelen.
Aktivera automatisk skalning
Maximal burst är det högsta antalet instanser som apptjänstplanen kan öka till baserat på inkommande HTTP-begäranden. För Premium v2- och v3-abonnemang kan du ange en maximal burst på upp till 30 instanser. Den maximala bursten måste vara lika med eller större än det antal arbetare som angetts för App Service-planen.
Om du vill aktivera automatisk skalning navigerar du till webbappens vänstra meny och väljer utskalning (App Service-plan). Välj Automatisk, uppdatera högsta burst-värde och välj knappen Spara .
Ange minsta antal webbappsinstanser
Always Ready-instanser är en inställning på appnivå för att ange det minsta antalet instanser. Om belastningen överskrider vad de alltid redo instanserna kan hantera läggs ytterligare instanser till (upp till den angivna maximala bursten för App Service-planen).
Om du vill ange det minsta antalet webbappsinstanser går du till webbappens vänstra meny och väljer skala ut (App Service-plan). Uppdatera värdet Always ready instances (Alltid redo instanser) och välj knappen Spara.
Ange maximalt antal webbappsinstanser
Den maximala skalningsgränsen anger det maximala antalet instanser som en webbapp kan skala till. Den maximala skalningsgränsen hjälper när en underordnad komponent som en databas har begränsat dataflöde. Maxvärdet per app kan vara mellan 1 och den maximala bursten.
Om du vill ange det maximala antalet webbappsinstanser går du till webbappens vänstra meny och väljer skala ut (App Service-plan). Välj Framtvinga utskalningsgräns, uppdatera gränsen för maximal skalning och välj knappen Spara.
Uppdatera förinställda instanser
Den förvärmda instansinställningen tillhandahåller varma instanser som en buffert under HTTP-skalnings- och aktiveringshändelser. Förinställda instanser fortsätter att buffrar tills den maximala utskalningsgränsen har nåtts. Standardantalet för förvärmd instans är 1 och för de flesta scenarier bör det här värdet förbli som 1.
Du kan inte ändra den förvärmde instansinställningen i portalen. Du måste i stället använda Azure CLI.
Inaktivera automatisk skalning
Om du vill inaktivera automatisk skalning går du till webbappens vänstra meny och väljer utskalning (App Service-plan). Välj Manuell och välj knappen Spara .
Har automatisk skalning stöd för Azure-funktionsappar?
Varning
Automatisk skalning inaktiveras när App Service-webbappar och Azure Function-appar finns i samma App Service-plan.
Nej, du kan bara ha Azure App Service-webbappar i App Service-planen där du vill aktivera automatisk skalning. För Functions rekommenderar vi att du använder Azure Functions Premium-planen i stället.
Hur fungerar automatisk skalning i bakgrunden?
Program som är inställda på automatisk skalning övervakas kontinuerligt, och arbetshälsobedömningar görs minst en gång med några sekunders mellanrum. Om systemet upptäcker ökad belastning på programmet blir hälsokontroller vanligare. I händelse av försämrad arbetshälsa och långsammare begäranden begärs ytterligare instanser. Den hastighet med vilken instanser läggs till varierar beroende på det enskilda programmets belastningsmönster och starttid. Program med korta starttider och tillfälliga belastningstoppar kan se en virtuell dator läggas till med några sekunders mellanrum till en minut.
När belastningen har minskat initierar plattformen en granskning för potentiell skalning. Den här processen börjar vanligtvis cirka 5–10 minuter efter att belastningen slutar öka. Under inskalningen tas instanser bort med en maximal hastighet på en med några sekunders mellanrum till en minut.
Om flera webbprogram distribueras inom samma App Service-plan försöker plattformen dessutom allokera resurser mellan tillgängliga instanser baserat på belastningen på varje enskild webbapp.
Hur gör jag för att debiteras för förvärmda instanser?
För att förstå hur du debiteras för förvärmda instanser bör du tänka på det här scenariot: Anta att din webbapp har fem instanser som alltid är redo, tillsammans med en förinstans som är inställd som standard.
När webbappen är inaktiv och inte tar emot några HTTP-begäranden körs den med de fem alltid redo instanserna. Under den här tiden debiteras du inte för en förvärmd instans eftersom de alltid redo-instanserna inte används och därför allokeras ingen förvärmd instans.
Men så snart webbappen börjar ta emot HTTP-begäranden och de fem alltid redo instanserna blir aktiva allokeras en förinstans och faktureringen för den börjar.
Om andelen HTTP-begäranden fortsätter att öka och App Service bestämmer sig för att skala utöver de fem första instanserna börjar den använda den förvärmde instansen. Det innebär att när det finns sex aktiva instanser etableras en sjunde instans omedelbart för att fylla den förvärmda bufferten.
Den här processen för skalning och förvarning fortsätter tills det maximala instansantalet för appen har nåtts. Det är viktigt att observera att inga instanser är förvärmade eller aktiverade utöver det maximala antalet instanser.
Varför har AppServiceHTTPLogs loggposter som liknar "/admin/host/ping" med statusen 404?
Automatisk skalning i App Service kontrollerar /admin/host/ping regelbundet slutpunkten tillsammans med andra mekanismer för hälsokontroll som är inbyggda i plattformen. Dessa kontroller är specifikt implementerade funktioner. Ibland kan 404-fel returneras av dessa pingar på grund av befintliga plattformskonfigurationer. Observera dock att dessa 404-fel inte bör påverka appens tillgänglighet eller skalningsprestanda.
Om webbappen returnerar en 5xx-status kan dessa slutpunkts pingar resultera i tillfälliga omstarter, även om detta är ovanligt. Vi implementerar för närvarande förbättringar för att åtgärda dessa tillfälliga omstarter. Tills dess kontrollerar du att webbappen inte returnerar statusen 5xx på den här slutpunkten. Tänk på att dessa pingslutpunkter inte kan anpassas.
Hur gör jag för att spåra antalet utskalade instanser under händelsen Automatisk skalning?
Måttet AutomaticScalingInstanceCount rapporterar antalet virtuella datorer som appen körs på, inklusive den förvärmda instansen om den distribueras. Det här måttet kan också användas för att spåra det maximala antalet instanser som din webbapp skalar ut under en automatisk skalningshändelse. Det här måttet är endast tillgängligt för appar som har automatisk skalning aktiverat.
Hur påverkar ARR-tillhörighet automatisk skalning?
Azure App Service använder routningscookies för programbegäran som kallas arr-tillhörighet. ARR-tillhörighetscookies begränsar skalningen eftersom de endast skickar begäranden till servrar som är associerade med cookien, i stället för någon tillgänglig instans. För appar som lagrar tillstånd är det bättre att skala upp (öka resurserna på en enda instans). För tillståndslösa appar ger utskalning (lägga till fler instanser) mer flexibilitet och skalbarhet. ARR-tillhörighetscookies är aktiverade som standard i App Service. Beroende på dina programbehov kan du välja att inaktivera ARR-tillhörighetscookies när du använder automatisk skalning.
Inaktivera ARR-tillhörighetscookies: välj din App Service-app och under Inställningar väljer du Konfiguration. Välj sedan fliken Allmänna inställningar . Under ARR-tillhörighet väljer du Av och sedan knappen Spara .