Händelsedriven skalning i Azure Functions

Händelsedriven skalning gäller inte för Dedicated (App Service)-planen. Den dedikerade planen skalar inte dynamiskt baserat på händelser. För skalningsalternativ i den dedikerade planen, se Skala upp en app i Azure App Service.

Händelsedriven skalning gäller inte när funktioner körs i Azure Container Apps. När det är hostat på Container Apps hanteras skalningen av Container Apps-miljön. Mer information finns i Ange skalningsregler i Azure Container Apps.

Körningstidsskalning

Azure Functions använder en komponent som kallas skalningskontrollant för att övervaka händelsefrekvensen och avgöra om du vill skala ut eller skala in. Skalningskontrollanten använder heuristik för varje utlösartyp. När du till exempel använder en Azure Queue Storage-utlösare använder den målbaserad skalning.

Skalningsenheten för Azure Functions är funktionsappen. När funktionsappen skalar ut allokerar den fler resurser för att köra flera instanser av Azure Functions-värden. Omvänt, när beräkningsbehovet minskar, tar skalstyrningen bort funktionsvärdinstanser. Antalet instanser skalas så småningom in när inga funktioner körs inom en app för funktioner.

Varje instans av Functions-värden i Consumption-planen är begränsad, vanligtvis till 1,5 GB minne och en CPU. En instans av värden stödjer hela funktionsappen, så alla funktioner i en app delar resurser och skalar samtidigt. När funktionsappar delar samma konsumtionsplan skalar de ändå oberoende.

Den specifika storleken på Premium-planen avgör tillgängligt minne och CPU för alla appar i den planen i den instansen. Planen skalar ut sina instanser baserat på skalningsbehoven för apparna i planen och apparna skalas inom planen efter behov.

Till skillnad från de andra dynamiska planerna använder Flex Consumption-planen en deterministisk skalningsmodell per funktion. I denna modell skalas varje funktion oberoende baserat på antalet händelser och samtidighetsinställningar, förutom HTTP-, Blob- och orkestreringsfunktioner (Durable) som skalar i egna grupper. Mer information finns i Skalning per funktion.

Plattformen hanterar hastigheten med vilken den lägger till instanser (skalkurvan), separat från det maximala antalet instanser. För mer information om hur skalningskurvan fungerar, strypbeteende och bästa praxis för höghastighetsskalning, se Scale-out rate.

Kallstart

Om din funktionsapp står inaktiv i några minuter kan plattformen minska antalet instanser som kör din app till noll. Nästa förfrågan upplever den extra latensen av skalning från noll till ett. Den här svarstiden kallas för en kallstart. Antalet beroenden som din funktionsapp kräver kan påverka kallstartstiden. Kallstart är mer ett problem för synkrona åtgärder, till exempel HTTP-utlösare som måste returnera ett svar. Om kallstarter påverkar dina funktioner, överväg att använda en plan som stödjer åtgärder för att minska åtgärder:

Som du kan se i denna tabell erbjuder både Flex Consumption- och Premium-planer sätt att eliminera kallstarter i dina appar.

Förstå skalningsbeteenden

Skalning kan variera beroende på flera faktorer. Appar skalar olika beroende på vilka triggers och vilket språk som valts. Var medveten om dessa komplexiteter i skalningsbeteenden:

• Maximala antal instanser: En app med en enda funktion skalar ut till ett maximum som tillåts av planen. En enskild instans kan dock bearbeta mer än ett meddelande eller en begäran i taget. Du kan ange ett lägre maxvärde för att begränsa skalningshastigheten efter behov.

• Ny instansfrekvens: För HTTP-triggers allokerar plattformen nya instanser högst en gång per sekund. För icke-HTTP-triggers allokerar plattformen nya instanser högst en gång var 30:e sekund. Skalningen går snabbare när du använder en Premium-plan .

• Målbaserad skalning: Målbaserad skalning ger kunderna en snabb och intuitiv skalningsmodell. För närvarande stöds den här skalningsmetoden för Service Bus-köer och -ämnen, lagringsköer, eventhubbar, Apache Kafka- och Azure Cosmos DB-tillägg. Se till att granska målbaserad skalning för att förstå deras skalningsbeteende.

• Skalning per funktion: Med några viktiga undantag körs funktioner i flexförbrukningsplanens skala på oberoende instanser. Undantagen omfattar HTTP-utlösare och Blob Storage-utlösare (Event Grid). Var och en av dessa utlösartyper skalas tillsammans som en grupp på samma instanser. På samma sätt delar utlösarna för alla Durable Functions även instanser och skalar tillsammans. Mer information finns i skalning per funktion.

• Maximalt övervakade triggers: För närvarande kan skalningskontrollern bara övervaka upp till 100 triggers för att fatta skalningsbeslut. När din app har mer än 100 händelsebaserade triggers baseras skalningsbesluten endast på de första 100 triggers som exekveras. Mer information finns i Metodtips och mönster för skalbara appar.

Begränsa utskalning

Du kan välja att begränsa det maximala antalet instanser som en app kan använda för utskalning. Den här begränsningen är vanligast i fall där en underordnad komponent som en databas har begränsat dataflöde. De maximala skalningsgränserna när du kör de olika värdplanerna finns i Skalningsgränser.

Som standardinställning har appar som körs i en Flex Consumption-plan en gräns för 100 totala antalet instanser. För närvarande är 1det lägsta maximala instansantalet , och det högsta värdet för maximalt antal instanser som stöds är 1000. När du använder az functionapp create kommandot för att skapa en funktionsapp i Flex Consumption-planen använder du parametern --maximum-instance-count för att ange det maximala antalet instanser för din app.

Det maximala antalet instanser gäller för instanser på begäran i varje skalgrupp per funktion (funktionsgrupp) snarare än för appens kombinerade instanser. Alltid redo instanser begränsas inte av det maximala antalet instanser och räknas inte mot det.

Du kan ändra det maximala instansantalet för Flex Consumption-appar upp till 1 000, men kvotgränsen för dina appar nås innan du når det antalet. Granska Regionala minneskvoter för prenumeration för mer information.

I det här exemplet skapas en app med maximalt antal instanser av 200:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

I det az functionapp scale config set här exemplet används kommandot för att ändra det maximala antalet instanser för en befintlig app till 150:

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

I en förbruknings- eller Elastic Premium-plan kan du ange en lägre maxgräns för din app genom att ändra värdet för platskonfigurationsinställningen functionAppScaleLimit . functionAppScaleLimit Kan anges till 0 eller null för obegränsad eller ett giltigt värde mellan 1 och appens maxvärde.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

Skalningshastighet

I Flex Consumption-planen hanterar plattformen också hastigheten med vilken den lägger till instanser (skalkurvan), separat från det maximala antalet instanser. För hur skalningskurvan fungerar, strypbeteende och bästa praxis för höghastighetsskalning, se Scale-out rate.

Skalningshastighet

I Consumption- och Premium-planerna styr skalkontrollern takten med vilken nya instanser läggs till. För HTTP-utlösare allokeras nya instanser högst en gång per sekund. För icke-HTTP-triggers allokeras nya instanser högst en gång var 30:e sekund. Skalningen går snabbare när du använder en Premium-plan .

Inskalningsbeteenden

Händelsedriven skalning minskar automatiskt kapaciteten när efterfrågan på dina funktioner minskar. Det gör den här minskningen genom att tömma instanser av deras aktuella funktionskörningar och sedan ta bort dessa instanser. Det här beteendet loggas som tömningsläge. Respitperioden för funktioner som för närvarande körs kan sträcka sig upp till 10 minuter för appar med Förbrukningsplan och upp till 60 minuter för appar med Flexibel förbrukning och Premiumabonnemang. Händelsedriven skalning och det här beteendet gäller inte för dedikerade planappar.

Följande överväganden gäller för inskalningsbeteenden:

• För appar som körs i Windows i en förbrukningsplan är det bara appar som skapats efter maj 2021 som har funktioner för avtappningsläge aktiverat som standard.
• Använd version 4.2.0 eller en senare version av Service Bus-tillägget för att aktivera en korrekt avstängning för funktioner med hjälp av Service Bus-utlösaren.

Skalning per funktion

Flex Consumption-planen är unik eftersom den implementerar ett skalningsbeteende per funktion. Vid skalning per funktion, förutom HTTP-utlösare, Blobutlösare (Event Grid) och Durable Functions, skalar alla andra funktionsutlösartyper i din app på oberoende instanser. HTTP-utlösare i din app skalas alla tillsammans som en grupp på samma instanser, liksom alla Blob -utlösare (Event Grid) och alla Durable Functions-utlösare som har egna delade instanser.

Överväg en funktionsapp som hanteras av en Flex Consumption-plan som har följande funktioner:

I det här exemplet:

• De två HTTP-utlösta funktionerna (function1 och function2) körs båda tillsammans på sina egna instanser och skalas tillsammans enligt HTTP-samtidighetsinställningar.
• De två Durable-funktionerna (function3 och function4) körs båda tillsammans på sina egna instanser och skalas tillsammans baserat på konfigurerade samtidighetsbegränsningar.
• Den tjänstbussutlösta funktionen function5 körs i sig och skalas oberoende enligt målbaserade skalningsregler för Service Bus-köer och ämnen.
• Den tjänstbussutlösta funktionen function6 körs i sig och skalas oberoende enligt målbaserade skalningsregler för Service Bus-köer och ämnen.
• Event Hubs-utlösaren (function7) körs i sina egna instanser och skalas oberoende enligt målbaserade skalningsregler för Event Hubs.

Metodtips och mönster för skalbara appar

Många aspekter av en funktionsapp påverkar hur den skalar, inklusive värdkonfiguration, körtidsavtryck och resurseffektivitet. Mer information finns i avsnittet om skalbarhet i artikeln om prestandaöverväganden. Du bör också vara medveten om hur anslutningar fungerar när funktionsappen skalas upp. Mer information finns i Hantera anslutningar i Azure Functions.

Om din app har mer än 100 funktioner som använder händelsebaserade triggers, överväg att dela upp appen i en eller flera appar, där varje app har färre än 100 händelsebaserade funktioner.

Mer information om skalning i Python och Node.jsfinns i avsnittet Skalning och prestanda i utvecklarguiden för Azure Functions Python och avsnittet Skalning och samtidighet i utvecklarguiden för Azure Functions Node.js.