Gebeurtenisgestuurd schalen in Azure Functions

Event-driven scaling is niet van toepassing op het Dedicated (App Service) plan. Het Dedicated Plan schaalt niet dynamisch op basis van gebeurtenissen. Voor schaalopties in het Dedicated plan, zie Scale up an app in Azure App Service.

Event-driven scaling is niet van toepassing bij het uitvoeren van functies op Azure Container Apps. Wanneer het wordt gehost op Container Apps, wordt schaalverdeling beheerd door de Container Apps-omgeving. Zie Schaalregels instellen in Azure Container Apps voor meer informatie.

Schalen van runtime

Azure Functions maakt gebruik van een onderdeel dat de schaalcontroller wordt genoemd om de snelheid van gebeurtenissen te bewaken en te bepalen of u wilt uitschalen of inschalen. De schaalcontroller maakt gebruik van heuristieken voor elk triggertype. Wanneer u bijvoorbeeld een Azure Queue Storage-trigger gebruikt, wordt gebruikgemaakt van schaalaanpassing op basis van doel.

De schaaleenheid voor Azure Functions is de functie-app. Wanneer de Function App schaalt, wijst deze meer middelen toe om meerdere instanties van de Azure Functions-host uit te voeren. Omgekeerd, naarmate de rekenbehoefte afneemt, verwijdert de schaalcontroller functionele hostinstanties. Het aantal instanties wordt uiteindelijk verkleind wanneer er geen functies draaien binnen een function app.

Elke instantie van de Functions-host in het Consumption-plan is meestal beperkt tot 1,5 GB geheugen en één CPU. Een instantie van de host ondersteunt de volledige functie-app, dus alle functies in een app delen tegelijkertijd resources en schalen. Wanneer functionele apps hetzelfde consumptieplan delen, schalen ze nog steeds onafhankelijk.

De specifieke grootte van het Premium-abonnement bepaalt het beschikbare geheugen en de CPU voor alle apps in dat abonnement op die instantie. Het plan schaalt de instanties uit op basis van de schaalbehoeften van de apps in het plan, en de apps schalen zich binnen het plan indien nodig.

In tegenstelling tot de andere dynamische plannen gebruikt het Flex Consumption-plan een deterministisch per-functie schaalmodel. In dit model wordt elke functie onafhankelijk geschaald op basis van het aantal gebeurtenissen en gelijktijdigheidsinstellingen, behalve HTTP-, Blob- en orchestratie-(Durable) getriggerde functies die in hun eigen groepen schalen. Zie Schalen per functie voor meer informatie.

Het platform beheert de snelheid waarmee het instanties toevoegt (de schaalcurve), los van het maximale aantal instanties. Voor meer informatie over hoe de schaalcurve werkt, het beperken van het gedrag en best practices voor hoog-snelheid schaalverdeling, zie Scale-out rate.

Koude start

Als je functie-app een paar minuten inactief blijft, kan het platform het aantal instances dat je app draait terugbrengen tot nul. Het volgende verzoek ervaart de extra latentie van schalen van nul naar één. Deze latentie wordt een koude start genoemd. Het aantal afhankelijkheden dat je functie-app nodig heeft, kan de koude starttijd beïnvloeden. Koude start is meer een probleem voor synchrone bewerkingen, zoals HTTP-triggers die een antwoord moeten retourneren. Als koude starts invloed hebben op uw functies, overweeg dan een plan te gebruiken dat mitigatiestrategieën ondersteunt:

Zoals je in deze tabel kunt zien, bieden zowel Flex Consumption- als Premium-abonnementen manieren om koude starts in je apps te elimineren.

Inzicht in het schaalgedrag

Schaalvergroting kan afhankelijk zijn van verschillende factoren. Apps schalen anders op basis van de triggers en de gekozen taal. Wees je bewust van deze fijne kneepjes van schaalgedrag:

• Maximale instanties: Een single function-app schaalt uit tot een maximum dat het plan toestaat. Eén exemplaar kan echter meerdere berichten of aanvragen tegelijk verwerken. U kunt naar behoefte een lager maximum opgeven om de schaal te beperken.

• Nieuwe instantiefrequentie: Voor HTTP-triggers wijst het platform nieuwe instanties maximaal één keer per seconde toe. Voor niet-HTTP-triggers wijst het platform maximaal elke 30 seconden nieuwe instanties toe. Schalen gaat sneller wanneer het op een Premium-abonnement uitgevoerd wordt.

• Schaalaanpassing op basis van doel: Op doel gebaseerde schaalaanpassing biedt een snel en intuïtief schaalmodel voor klanten. Op dit moment wordt deze schaalmethode ondersteund voor Service Bus-wachtrijen en -onderwerpen, opslagwachtrijen, Event Hubs, Apache Kafka en Azure Cosmos DB-extensies. Zorg ervoor dat u schaalaanpassing op basis van doel bekijkt om inzicht te hebben in het gedrag van de schaalaanpassing.

• Schaalaanpassing per functie: Met enkele opvallende uitzonderingen worden functies die worden uitgevoerd in het Flex Consumption-plan geschaald over onafhankelijke instanties. De uitzonderingen zijn HTTP-triggers en Event Grid-triggers (Blob Storage). Elk van deze triggertypen wordt samen geschaald als een groep op dezelfde exemplaren. Op dezelfde manier delen de triggers van alle Durable Functions ook instanties en schalen ze samen. Zie Schalen per functie voor meer informatie.

• Maximaal gemonitorde triggers: Momenteel kan de schaalcontroller slechts tot 100 triggers monitoren om schaalbeslissingen te nemen. Wanneer je app meer dan 100 event-based triggers heeft, zijn schaalbeslissingen gebaseerd op alleen de eerste 100 triggers die worden uitgevoerd. Zie Best practices en patronen voor schaalbare apps voor meer informatie.

Uitschalen beperken

U kunt besluiten om het maximum aantal exemplaren te beperken dat een app kan gebruiken voor uitschalen. Deze beperking komt het meest voor in gevallen waarin een downstreamonderdeel zoals een database een beperkte doorvoer heeft. Zie Schaallimieten voor de maximale schaallimieten bij het uitvoeren van de verschillende hostingabonnementen.

Standaard hebben apps die worden uitgevoerd in een flexibele consumptieplan een limiet van 100 totaal aantal instanties. Momenteel is 1de laagste waarde voor het maximumaantal exemplaren en de hoogste ondersteunde maximumaantal exemplaren is 1000. Wanneer u de az functionapp create opdracht gebruikt om een functie-app te maken in het Flex Consumption-abonnement, gebruikt u de --maximum-instance-count parameter om dit maximumaantal exemplaren voor uw app in te stellen.

Het maximale aantal instanties geldt voor on-demand instanties in elke per-functie schaalgroep (functiegroep) in plaats van voor de gecombineerde instanties van de app. Always ready-instanties worden niet beperkt door het maximale aantal instances en tellen daar niet voor.

Hoewel u het maximumaantal exemplaren van Flex Consumption-apps tot 1000 kunt wijzigen, wordt de quotumlimiet voor uw apps bereikt voordat u dat aantal bereikt. Bekijk quota voor regionaal abonnementsgeheugen voor meer informatie.

In dit voorbeeld wordt een app gemaakt met een maximumaantal exemplaren van 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

In dit voorbeeld wordt de az functionapp scale config set opdracht gebruikt om het maximumaantal exemplaren voor een bestaande app te wijzigen in 150:

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

In een Consumption- of Elastic Premium-abonnement kunt u een lagere maximumlimiet voor uw app opgeven door de waarde van de functionAppScaleLimit siteconfiguratie-instelling te wijzigen. De functionAppScaleLimit waarde kan worden ingesteld op 0 of null voor onbeperkt gebruik, of een geldige waarde tussen 1 en het maximum van de app.

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

Schaalsnelheid

In het Flex Consumption-plan beheert het platform ook het tempo waarmee het instanties toevoegt (de schaalcurve), los van het maximale aantal instances. Voor hoe de schaalcurve werkt, het beperken van het gedrag en best practices voor hoog-rate scaling, zie Scale-out rate.

Schaalsnelheid

In de Consumption- en Premium-plannen beheert de schaalcontroller het tempo waarmee nieuwe instanties worden toegevoegd. Voor HTTP-triggers worden nieuwe exemplaren maximaal één keer per seconde toegewezen. Voor niet-HTTP-triggers worden nieuwe instanties maximaal eens per 30 seconden toegewezen. Schalen gaat sneller wanneer het op een Premium-abonnement uitgevoerd wordt.

Gedrag van inschalen

Gebeurtenisgestuurd schalen vermindert automatisch de capaciteit wanneer de vraag naar uw functies wordt verminderd. Hierdoor wordt deze vermindering verminderd door exemplaren van hun huidige functie-uitvoeringen leeg te maken en vervolgens deze exemplaren te verwijderen. Dit gedrag wordt geregistreerd als afvoermodus. De respijtperiode voor functies die momenteel worden uitgevoerd, kan worden verlengd tot 10 minuten voor apps voor verbruiksabonnementen en maximaal 60 minuten voor Flex Consumption- en Premium-abonnements-apps. Gebeurtenisgestuurde schaalvergroting en dit soort gedrag zijn niet van toepassing op apps in een dedicated plan.

De volgende overwegingen zijn van toepassing op inschaalgedrag:

• Voor apps die worden uitgevoerd op Windows binnen een consumptie-abonnement, hebben alleen apps die zijn gemaakt na mei 2021 de standaardafvoermodus-gedragingen ingeschakeld.
• Gebruik versie 4.2.0 of een nieuwere versie van de Service Bus-extensie om een probleemloos afsluiten in te schakelen voor functies met behulp van de Service Bus-trigger.

Schaalaanpassing per functie

Het Flex Consumption-abonnement is uniek omdat hiermee een schaalgedrag per functie wordt geïmplementeerd. Bij schalen per functie, met uitzondering van HTTP-triggers, Blob-triggers (Event Grid) en Durable Functions, worden alle andere typen functietriggers in uw app geschaald op onafhankelijke instanties. HTTP-triggers in uw app schalen allemaal samen als een groep op dezelfde exemplaren, net als alle Blob -triggers (Event Grid) en alle Durable Functions-triggers, die hun eigen gedeelde exemplaren hebben.

Overweeg een functie-app die wordt gehost door een Flex Consumption-abonnement met de volgende functies:

In dit voorbeeld:

• De twee HTTP-geactiveerde functies (function1 en function2) worden samen op hun eigen exemplaren uitgevoerd en samen geschaald volgens de HTTP-gelijktijdigheidsinstellingen.
• De twee Durable-functies (function3 en function4) worden gelijktijdig uitgevoerd op hun eigen exemplaren en schalen samen op basis van geconfigureerde gelijktijdigheidsbeperkingen.
• De door Service Bus geactiveerde functie function5 wordt zelfstandig uitgevoerd en wordt onafhankelijk geschaald volgens de op doel gebaseerde schaalregels voor Service Bus-wachtrijen en -onderwerpen.
• De door Service Bus geactiveerde functie function6 wordt zelfstandig uitgevoerd en wordt onafhankelijk geschaald volgens de op doel gebaseerde schaalregels voor Service Bus-wachtrijen en -onderwerpen.
• De Event Hubs-trigger (function7) wordt uitgevoerd in zijn eigen instanties en wordt onafhankelijk geschaald volgens de doelgerichte schaalregels voor Event Hubs.

Aanbevolen procedures en patronen voor schaalbare apps

Veel aspecten van een functionele app beïnvloeden hoe deze schaalt, waaronder hostconfiguratie, runtime-footprint en resource-efficiëntie. Zie de sectie schaalbaarheid van het artikel over prestatieoverwegingen voor meer informatie. Je moet ook weten hoe verbindingen zich gedragen wanneer je functie-app schaalt. Raadpleeg Verbindingen beheren in Azure Functions voor meer informatie.

Als je app meer dan 100 functies heeft die gebruikmaken van gebeurtenisgebaseerde triggers, overweeg dan om de app op te splitsen in één of meer apps, waarbij elke app minder dan 100 gebeurtenisgebaseerde functies heeft.

Zie voor meer informatie over schalen in Python en Node.jsde sectie Schalen en prestaties van de Ontwikkelaarshandleiding voor Azure Functions Python en de sectie Schalen en gelijktijdigheid van de Azure Functions Node.js ontwikkelaarshandleiding.