Händelsedriven skalning i Azure Functions
I förbruknings-, flexförbruknings- och Premium-abonnemangen skalar Azure Functions resurser genom att lägga till fler instanser baserat på antalet händelser som utlöser en funktion.
Viktigt!
Flex Consumption-planen är för närvarande i förhandsversion.
Hur din funktionsapp skalar beror på värdplanen:
Förbrukningsplan: Varje instans av Functions-värden i förbrukningsplanen är begränsad, vanligtvis till 1,5 GB minne och en PROCESSOR. En instans av värden stöder hela funktionsappen. Därför skalas alla funktioner i en funktionsappresurs i en instans samtidigt. När funktionsappar delar samma förbrukningsplan skalas de fortfarande oberoende av varandra.
Flex Consumption-plan: Planen använder en deterministisk skalningsstrategi per funktion, där varje funktion skalas separat, med undantag för HTTP-, Blob- och Durable Functions-utlösta funktioner som skalas i sina egna grupper. Mer information finns i Skalning per funktion. Dessa instanser skalas sedan baserat på samtidigheten i dina begäranden.
Premium-plan: Den specifika storleken på Premium-planen avgör det tillgängliga minnet och processorn för alla appar i planen på den instansen. Planen skalar ut sina instanser baserat på skalningsbehoven för apparna i planen och apparna skalas inom planen efter behov.
Funktionskodfiler lagras på Azure Files-resurser på funktionens huvudlagringskonto. När du tar bort funktionsappens huvudlagringskonto tas funktionskodfilerna bort och kan inte återställas.
Körningsskalning
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 skalas ut allokeras fler resurser för att köra flera instanser av Azure Functions-värden. När beräkningsbehovet minskar tar skalningskontrollanten i stället bort instanser av Functions-värden. Antalet instanser "skalas in" när inga funktioner körs i en funktionsapp.
Kall start
Om funktionsappen blir inaktiv i några minuter kan plattformen bestämma sig för att skala antalet instanser där appen körs ned till noll. Nästa begäran har den extra svarstiden för skalning från noll till en. Den här svarstiden kallas för en kallstart. Antalet beroenden som krävs av funktionsappen kan påverka den kalla starttiden. 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 bör du överväga att använda en annan plan än förbrukning. De andra planerna erbjuder dessa strategier för att minimera eller eliminera kallstarter:
Premium-plan: stöder både förvärmda instanser och alltid redo instanser, med minst en instans.
Flex Consumption-plan: stöder ett valfritt antal alltid redo instanser, som kan definieras per instansskalning.
Dedikerad plan: själva planen skalas inte dynamiskt, men du kan köra appen kontinuerligt med inställningen Always on aktiverad.
Förstå skalningsbeteenden
Skalning kan variera beroende på flera faktorer, och appar skalas olika baserat på de utlösare och språk som valts. Det finns några lite speciella skalningsbeteenden som du bör vara medveten om:
- Maximalt antal instanser: En enskild funktionsapp skalas bara ut till ett maximalt antal 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 skalning efter behov.
- Ny instansfrekvens: För HTTP-utlösare allokeras nya instanser högst en gång per sekund. För icke-HTTP-utlösare allokeras 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 en snabb och intuitiv skalningsmodell för kunder och stöds för närvarande för Service Bus-köer och -ämnen, lagringsköer, Event Hubs, 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 alla Durable Functions-utlösare även instanser och skalar tillsammans. Mer information finns i skalning per funktion.
Begränsa utskalning
Du kan välja att begränsa det maximala antalet instanser som en app kan använda för utskalning. Detta ä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.
Flex-förbrukningsplan
Som standard har appar som körs i en Flex Consumption-plan en gräns för 100 övergripande instanser. För närvarande är 40det 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. 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 <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
Förbrukning/Premium-abonnemang
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>
Inskalningsbeteenden
Händelsedriven skalning minskar automatiskt kapaciteten när efterfrågan på dina funktioner minskar. Det gör det 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 körs för närvarande kan sträcka sig upp till 10 minuter för appar för förbrukningsplan och upp till 60 minuter för Premium-planappar. 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 har endast appar som skapats efter maj 2021 funktioner för dräneringslä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
Gäller endast för Flex Consumption-planen (förhandsversion).
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 att en funktionsapp är värd för en Flex Consumption-plan som har följande funktion:
| function1 | function2 | function3 | function4 | function5 | function6 | funktion 7 |
|---|---|---|---|---|---|---|
| HTTP-utlösare | HTTP-utlösare | Orkestreringsutlösare (Durable) | Aktivitetsutlösare (durable) | Service Bus-utlösare | Service Bus-utlösare | Event Hubs-utlösare |
I det här exemplet:
- De två HTTP-utlösta funktionerna (
function1ochfunction2) körs båda tillsammans på sina egna instanser och skalas tillsammans enligt HTTP-samtidighetsinställningar. - De två Durable-funktionerna (
function3ochfunction4) körs båda tillsammans på sina egna instanser och skalas tillsammans baserat på konfigurerade samtidighetsbegränsningar. - Den tjänstbussutlösta funktionen
function5körs i sig och skalas oberoende enligt målbaserade skalningsregler för Service Bus-köer och ämnen. - Den tjänstbussutlösta funktionen
function6kö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
Det finns många aspekter av en funktionsapp som påverkar hur den skalar, inklusive värdkonfiguration, körningsfotavtryck 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 skalar. Mer information finns i Hantera anslutningar i Azure Functions.
Mer information om skalning i Python och Node.js finns i Utvecklarguide för Azure Functions Python – Skalning och samtidighet och Utvecklarguide för Azure Functions Node.js – Skalning och samtidighet.
Nästa steg
Mer information finns i följande artiklar: