Share via

Gebeurtenisgestuurd schalen in Azure Functions

  • Artikel

In de abonnementen Consumption, Flex Consumption en Premium schaalt Azure Functions resources op door meer exemplaren toe te voegen op basis van het aantal gebeurtenissen dat een functie activeert.

Belangrijk

Het Flex Consumption-abonnement is momenteel beschikbaar als preview-versie.

De manier waarop uw functie-app wordt geschaald, is afhankelijk van het hostingabonnement:

  • Verbruiksabonnement: elk exemplaar van de Functions-host in het verbruiksabonnement is beperkt, meestal tot 1,5 GB geheugen en één CPU. Een exemplaar van de host ondersteunt de hele functie-app. Als zodanig worden alle functies binnen een functie-app-shareresource in een exemplaar op hetzelfde moment geschaald. Wanneer functie-apps hetzelfde verbruiksabonnement delen, worden ze nog steeds onafhankelijk geschaald.

  • Flex Consumption-plan: Het plan maakt gebruik van een deterministische strategie voor schalen per functie, waarbij elke functie onafhankelijk wordt geschaald, met uitzondering van door HTTP, Blob en Durable Functions geactiveerde functies die in hun eigen groepen worden geschaald. Zie Schalen per functie voor meer informatie. Deze exemplaren worden vervolgens geschaald op basis van de gelijktijdigheid van uw aanvragen.

  • Premium-abonnement: De specifieke grootte van het Premium-abonnement bepaalt het beschikbare geheugen en de CPU voor alle apps in dat abonnement op dat exemplaar. Het plan schaalt de exemplaren uit op basis van de schaalbehoeften van de apps in het plan en de apps worden zo nodig in het plan geschaald.

Functiecodebestanden worden opgeslagen op Azure Files-shares in het hoofdopslagaccount van de functie. Wanneer u het hoofdopslagaccount van de functie-app verwijdert, worden de functiecodebestanden verwijderd en kunnen ze niet worden hersteld.

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 functie-app wordt uitgeschaald, worden er meer resources toegewezen om meerdere exemplaren van de Azure Functions-host uit te voeren. Als de rekenvraag daarentegen afneemt, verwijdert de schaalcontroller functiehostexemplaren. Het aantal exemplaren wordt uiteindelijk 'ingeschaald' wanneer er geen functies worden uitgevoerd binnen een functie-app.

Bewakingsactiviteiten van controller schalen en exemplaren maken

Koude begindatum

Als uw functie-app enkele minuten inactief wordt, kan het platform besluiten om het aantal exemplaren te schalen waarop uw app wordt uitgevoerd tot nul. De volgende aanvraag heeft de toegevoegde latentie van schalen van nul naar één. Deze latentie wordt een koude start genoemd. Het aantal afhankelijkheden dat door uw functie-app is vereist, kan van invloed zijn op de koude begintijd. Koude start is meer een probleem voor synchrone bewerkingen, zoals HTTP-triggers die een antwoord moeten retourneren. Als koude start van invloed is op uw functies, kunt u overwegen een ander abonnement dan het verbruik te gebruiken. De andere plannen bieden deze strategieën om koude start te beperken of te elimineren:

  • Premium-abonnement: ondersteunt zowel voorbewarmde exemplaren als altijd gereede exemplaren, met minimaal één exemplaar.

  • Flex Consumption-abonnement: ondersteunt een optioneel aantal altijd gereede exemplaren, dat per instantie kan worden gedefinieerd.

  • Toegewezen plan: het plan zelf wordt niet dynamisch geschaald, maar u kunt uw app continu uitvoeren met de alwayson-instelling is ingeschakeld.

Inzicht in schaalgedrag

Schalen kan variëren op basis van verschillende factoren en apps worden anders geschaald op basis van de triggers en de geselecteerde taal. Er zijn enkele complexiteiten van schaalgedrag waar u rekening mee moet houden:

  • Maximumaantal exemplaren: Een app met één functie wordt alleen uitgeschaald naar een maximum dat door het plan is toegestaan. 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 instantiesnelheid: voor HTTP-triggers worden nieuwe exemplaren maximaal één keer per seconde toegewezen. Voor niet-HTTP-triggers worden nieuwe exemplaren maximaal één keer per 30 seconden toegewezen. Schalen gaat sneller wanneer u uitvoert in een Premium-plan.
  • Op doel gebaseerde schaalaanpassing: op doel gebaseerde schaalaanpassing biedt een snel en intuïtief schaalmodel voor klanten en wordt momenteel 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 de schaal van het Flex Consumption-abonnement op 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 alle Durable Functions-triggers ook exemplaren en schalen. Zie Schalen per functie voor meer informatie.
  • Maximaal bewaakte triggers: momenteel kan de schaalcontroller maximaal 100 triggers bewaken om schaalbeslissingen te nemen. Wanneer uw app meer dan 100 triggers op basis van gebeurtenissen heeft, worden schaalbeslissingen genomen op basis van 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. Dit is het meest gebruikelijk voor gevallen waarin een downstreamonderdeel, zoals een database, beperkte doorvoer heeft. Zie Schaallimieten voor de maximale schaallimieten bij het uitvoeren van de verschillende hostingabonnementen.

Flex Consumption-abonnement

Standaard hebben apps die worden uitgevoerd in een Flex Consumption-abonnement een limiet van 100 algemene exemplaren. Momenteel is 40de 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.

Houd er rekening mee dat terwijl u het maximumaantal flexverbruik-apps tot 1000 kunt wijzigen, uw apps een quotumlimiet bereiken voordat dit aantal wordt 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 <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

Verbruiks-/Premium-abonnementen

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, of een geldige waarde tussen en het maximum van 1 de app.

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

Gedrag van inschalen

Gebeurtenisgestuurd schalen vermindert automatisch de capaciteit wanneer de vraag naar uw functies wordt verminderd. Dit doet u door exemplaren van hun huidige functie-uitvoeringen leeg te maken en deze exemplaren vervolgens 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. Gebeurtenisgestuurd schalen en dit gedrag is niet van toepassing op toegewezen plan-apps.

De volgende overwegingen zijn van toepassing op inschaalgedrag:

Schaalaanpassing per functie

Is alleen van toepassing op het Flex Consumption-abonnement (preview).

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 als host fungeert voor een Flex Consumption-abonnement met deze functie:

functie1 functie2 functie3 functie4 functie5 functie6 functie7
HTTP-trigger HTTP-trigger Indelingstrigger (Duurzaam) Activiteitstrigger (duurzaam) Service Bus-trigger Service Bus-trigger Event Hubs-trigger

In dit voorbeeld:

Aanbevolen procedures en patronen voor schaalbare apps

Er zijn veel aspecten van een functie-app die van invloed is op de schaal, waaronder hostconfiguratie, runtime-footprint en resource-efficiëntie. Zie de sectie schaalbaarheid van het artikel over prestatieoverwegingen voor meer informatie. U moet ook weten hoe verbindingen zich gedragen wanneer uw functie-app wordt geschaald. Raadpleeg Verbindingen beheren in Azure Functions voor meer informatie.

Als uw app meer dan 100 functies heeft die gebruikmaken van triggers op basis van gebeurtenissen, kunt u overwegen om de app te verbreken in een of meer apps, waarbij elke app minder dan 100 functies op basis van gebeurtenissen heeft.

Zie voor meer informatie over schalen in Python en Node.js de ontwikkelaarshandleiding voor Azure Functions Python: schalen en gelijktijdigheid en Azure Functions Node.js ontwikkelaarshandleiding: schalen en gelijktijdigheid.

Volgende stappen

Zie de volgende artikelen voor meer informatie: