Ridimensionamento guidato dagli eventi in Funzioni di Azure

La scalabilità basata su eventi non si applica al piano dedicato (App Service). Il piano dedicato non scala dinamicamente in base agli eventi. Per le opzioni di scalabilità nel piano dedicato, vedi Scala un'app in Servizio app di Azure.

La scalatura basata sugli eventi non si applica quando si eseguono funzioni su App contenitore di Azure. Quando ospitato su Container Apps, la scalabilità è gestita dall'ambiente Container Apps. Per altre informazioni, vedere Impostare le regole di ridimensionamento in App contenitore di Azure.

Ridimensionamento in fase di esecuzione

Funzioni di Azure usa un componente denominato controller di scalabilità per monitorare la frequenza degli eventi e determinare se aumentare o ridurre le prestazioni. Il controller di scalabilità usa le funzionalità di euristica per ogni tipo di trigger. Ad esempio, quando si usa un trigger dell'archiviazione code di Azure, usa il ridimensionamento basato sulla destinazione.

L'unità di scalabilità per Funzioni di Azure è l'app per le funzioni. Quando l'app funzione si espande, alloca più risorse per eseguire più istanze dell'host di Funzioni di Azure. Al contrario, con la diminuzione della domanda di calcolo, il controller di scala rimuove istanze host di funzione. Il numero di istanze verrà ridotto quando non saranno in esecuzione funzioni all'interno di un'app per le funzioni.

Ogni istanza dell'host Functions nel piano Consumption è limitata, tipicamente a 1,5 GB di memoria e una CPU. Un'istanza dell'host supporta l'intera funzione app, quindi tutte le funzioni in un'app condividono risorse e scalano contemporaneamente. Quando le app di funzione condividono lo stesso piano di consumo, scalano comunque in modo indipendente.

La dimensione specifica del piano Premium determina la memoria e la CPU disponibili per tutte le app di quel piano in quell'istanza. Il piano aumenta il numero di istanze in base alle esigenze di ridimensionamento delle app nel piano e le app si ridimensionano nel piano in base alle esigenze.

A differenza degli altri piani dinamici, il piano Flex Consumption utilizza un modello deterministico di scala per funzione. In questo modello, ogni funzione è scalata indipendentemente in base al numero di eventi e alle impostazioni di concorrenza, ad eccezione delle funzioni attivate HTTP, Blob e orchestrazione (Durable) che scalano nei loro gruppi. Per altre informazioni, vedere Ridimensionamento per funzione.

La piattaforma gestisce la velocità con cui aggiunge istanze (la curva di scala), separatamente dal numero massimo di istanze. Per maggiori informazioni su come funziona la curva di scala, il comportamento di throttling e le migliori pratiche per la scala ad alta velocità, vedi Scale-out rate.

Avvio a freddo

Se la tua app di funzione rimane inattiva per qualche minuto, la piattaforma potrebbe ridurre a zero il numero di istanze che la fanno eseguire. La richiesta successiva subisce la latenza aggiuntiva della scalatura da zero a uno. Questa latenza viene definita avvio a freddo. Il numero di dipendenze richieste dalla tua app di funzionalità può influenzare l'orario di avvio a freddo. L'avvio a freddo è più di un problema per le operazioni sincrone, ad esempio i trigger HTTP che devono restituire una risposta. Se gli avviamenti a freddo stanno influenzando le tue funzioni, considera di utilizzare un piano che supporti strategie di mitigazione:

Come puoi vedere in questa tabella, sia il piano Flex Consumption che quello Premium offrono modi per eliminare gli avviamenti a freddo nelle tue app.

Introduzione al ridimensionamento

Il ridimensionamento può variare in base a diversi fattori. Le app scalano diversamente in base ai trigger e alla lingua selezionata. Fai attenzione a queste complessità dei comportamenti di scala:

• Maggior numero di casi : Un'app a singola funzione scala fino al massimo consentito dal piano. Tuttavia, una singola istanza può elaborare più messaggi o richieste alla volta. È possibile specificare un valore massimo inferiore per limitare il ridimensionamento in base alle esigenze.

• Nuovo tasso di istanza: Per i trigger HTTP, la piattaforma alloca nuove istanze al massimo una volta al secondo. Per trigger non HTTP, la piattaforma alloca nuove istanze al massimo una volta ogni 30 secondi. Il ridimensionamento è più rapido se eseguito in un piano Premium.

• Ridimensionamento basato su destinazione: La scalabilità basata su destinazione offre un modello di scalabilità rapido e intuitivo per i clienti. Attualmente, questo metodo di ridimensionamento è supportato per argomenti e code del bus di servizio, code di archiviazione, hub eventi, estensioni Apache Kafka e Azure Cosmos DB. Assicurarsi di esaminare il ridimensionamento basato su destinazione per comprendere il comportamento di ridimensionamento.

• Ridimensionamento per funzione: con alcune eccezioni di rilievo, le funzioni eseguite nel piano a consumo flessibile vengono ridimensionate su istanze indipendenti. Le eccezioni includono trigger HTTP e trigger di archiviazione BLOB (Griglia di eventi). Ognuno di questi tipi di trigger viene ridimensionato come gruppo nelle stesse istanze. Analogamente, i trigger di tutte le funzioni durevoli condividono le istanze e si ridimensionano insieme. Per altre informazioni, vedere Ridimensionamento per funzione.

• Trigger massimi monitorati: Attualmente, il controller di bilancia può monitorare solo fino a 100 trigger per prendere decisioni di scaling. Quando la tua app ha più di 100 trigger basati su eventi, le decisioni di scala si basano solo sui primi 100 trigger che vengono eseguiti. Per altre informazioni, vedere Procedure consigliate e modelli per le app scalabili.

Limitare lo scale-out

È possibile decidere di limitare il numero massimo di istanze che un'app può usare per la scalabilità orizzontale. Questa limitazione è più comune per i casi in cui un componente downstream come un database ha una velocità effettiva limitata. Per i limiti massimi di ridimensionamento quando si eseguono i vari piani di hosting, vedere Limiti di ridimensionamento.

Per impostazione predefinita, le app in esecuzione in un piano a consumo flessibile hanno un limite di 100 istanze complessive. Attualmente il numero massimo di istanze più basso è 1 e il numero massimo di istanze supportato più alto è 1000. Quando si usa il comando az functionapp create per creare un'app per le funzioni nel piano a consumo flessibile, usare il parametro --maximum-instance-count per impostare questo numero massimo di istanze per l'app.

Il numero massimo di istanze si applica alle istanze on-demand in ogni gruppo di scala per funzione (gruppo di funzioni) piuttosto che alle istanze combinate dell'app. Le istanze sempre pronte non sono limitate dal numero massimo di istanze e non contano per esso.

Anche se è possibile modificare il numero massimo di istanze delle app Flex Consumption fino a 1000, il limite di quota per le app viene raggiunto prima di raggiungere tale numero. Per altri dettagli, vedere le Quote di memoria della sottoscrizione a livello di area.

Questo esempio crea un'app con un numero massimo di istanze di 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 questo esempio si usa il comando az functionapp scale config set per modificare il numero massimo di istanze per un'app esistente in 150:

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

In un piano a consumo o elastico Premium è possibile specificare un limite massimo inferiore per l'app modificando il valore dell'impostazione di configurazione del sito functionAppScaleLimit. È possibile impostare functionAppScaleLimit su 0 o su null per evitare restrizioni oppure su un valore valido compreso tra 1 e il limite massimo dell'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

Tasso di scala

Nel piano Flex Consumption, la piattaforma gestisce anche la velocità con cui aggiunge istanze (la curva di scala), separatamente dal conteggio massimo di istanze. Per come funziona la curva di scala, il comportamento di throttling e le migliori pratiche per la scala ad alta velocità, vedi Scale-out rate.

Tasso di scala

Nei piani Consumo e Premium, il controller della bilancia gestisce la velocità con cui vengono aggiunte nuove istanze. Per i trigger HTTP, le nuove istanze vengono allocate al massimo una volta al secondo. Per i trigger non HTTP, nuove istanze vengono allocate al massimo una volta ogni 30 secondi. Il ridimensionamento è più rapido se eseguito in un piano Premium.

Riduzioni

Il ridimensionamento basato su eventi riduce automaticamente la capacità quando la domanda per le funzioni si riduce. Questa riduzione avviene svuotando le istanze dalle esecuzioni delle funzioni correnti e rimuovendo le istanze. Questo comportamento viene registrato come modalità di svuotamento. Il periodo di tolleranza per le funzioni attualmente in esecuzione può estendersi fino a 10 minuti per le app del piano a consumo e fino a 60 minuti per le app dei piani a consumo flessibile e Premium. La scalabilità guidata dagli eventi e questo comportamento non si applicano alle app del piano dedicato.

Per le riduzioni si applicano le considerazioni seguenti:

• Per le app in esecuzione in Windows in un piano a consumo, solo per le app create dopo maggio 2021 i comportamenti della modalità di svuotamento sono abilitati per impostazione predefinita.
• Per abilitare l'arresto normale per le funzioni tramite il trigger del bus di servizio, usare la versione 4.2.0 o successive dell'estensione del bus di servizio.

Ridimensionamento per funzione

Il piano a consumo flessibile è univoco in quanto implementa un comportamento di ridimensionamento per funzione. Nel ridimensionamento per funzione, ad eccezione dei trigger HTTP, dei trigger BLOB (Griglia di eventi) e di Durable Functions, tutti gli altri tipi di trigger di funzione nell'app si ridimensionano su istanze indipendenti. I trigger HTTP nell'app vengono ridimensionati tutti insieme come gruppo nelle stesse istanze, come tutti i BLOB (Griglia di eventi) e tutti i trigger Durable Functions, che dispongono di istanze condivise.

Si consideri un'app per le funzioni ospitata da un piano Flex Consumption con le funzioni seguenti:

In questo esempio:

• Le due funzioni attivate da HTTP (function1 e function2) vengono eseguite insieme nelle proprie istanze e vengono ridimensionate insieme in base alle impostazioni di concorrenza HTTP.
• Le due Durable Functions (function3 e function4) vengono eseguite insieme nelle proprie istanze e vengono ridimensionate insieme in base alle limitazioni di concorrenza configurate.
• La funzione attivata dal bus di servizio function5 viene eseguita autonomamente e viene ridimensionata in modo indipendente in base alle regole di ridimensionamento basate sulla destinazione per code e argomenti del bus di servizio.
• La funzione attivata dal bus di servizio function6 viene eseguita autonomamente e viene ridimensionata in modo indipendente in base alle regole di ridimensionamento basate sulla destinazione per code e argomenti del bus di servizio.
• Il trigger Hub eventi (function7) viene eseguito nelle proprie istanze e viene ridimensionato in modo indipendente in base alle regole di ridimensionamento basate sulla destinazione per Hub eventi.

Procedure consigliate e modelli per app scalabili

Molti aspetti di un'app di funzione influenzano la sua scala, inclusa la configurazione dell'host, l'ingombro in tempo di esecuzione e l'efficienza delle risorse. Per altre informazioni, vedere la sezione relativa alla scalabilità nell'articolo sulle prestazioni. È inoltre necessario comprendere il funzionamento delle connessioni quando l'app per le funzioni viene ridimensionata. Per altre informazioni, vedere How to manage connections in Funzioni di Azure (Come gestire le connessioni in Funzioni di Azure).

Se la tua app ha più di 100 funzioni che utilizzano trigger basati su eventi, considera di suddividere l'app in una o più app, ognuna con meno di 100 funzioni basate su eventi.

Per altre informazioni sul ridimensionamento in Python e Node.js, vedere la sezione Ridimensionamento e prestazioni della guida per sviluppatori Python per Funzioni di Azure e la sezione Ridimensionamento e concorrenza della guida per sviluppatori di Funzioni di Azure Node.js.