Dela via

Händelsedriven skalning i Azure Functions

  • Artikel

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.

Skala kontrollantens övervakningshändelser och skapa instanser

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.
  • Maximalt antal övervakade utlösare: För närvarande kan skalningsstyrenheten bara övervaka upp till 100 utlösare för att fatta skalningsbeslut. När appen har fler än 100 händelsebaserade utlösare fattas skalningsbeslut baserat på endast de första 100 utlösarna som körs. 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. 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.

Observera att även om du kan ändra det maximala instansantalet för Flex Consumption-appar upp till 1 000, når dina appar en kvotgräns innan de når det antalet. Mer information finns i Regionala minneskvoter för prenumeration.

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 appar med Flex Consumption och Premium-abonnemang. Händelsedriven skalning och det här beteendet gäller inte för dedikerade planappar.

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

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:

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.

Om din app har fler än 100 funktioner som använder händelsebaserade utlösare kan du överväga 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.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: