Ridimensionamento guidato dagli eventi in Funzioni di Azure

  • Articolo

Nei piani A consumo, A consumo Flex e Premium, Funzioni di Azure ridimensiona le risorse aggiungendo altre istanze in base al numero di eventi che attivano una funzione.

Importante

Il piano A consumo Flex è attualmente in anteprima.

Il modo in cui l'app per le funzioni viene ridimensionata dipende dal piano di hosting:

  • Piano A consumo: ogni istanza dell'host Funzioni nel piano A consumo è limitata, in genere a 1,5 GB di memoria e una CPU. Un'istanza dell'host supporta l'intera app per le funzioni. Di conseguenza, tutte le funzioni all'interno di una risorsa di condivisione dell'app per le funzioni in un'istanza vengono ridimensionate contemporaneamente. Quando le app per le funzioni condividono lo stesso piano A consumo, vengono comunque ridimensionate in modo indipendente.

  • Piano A consumo Flex: il piano usa una strategia di scalabilità deterministica per funzione, in cui ogni funzione viene ridimensionata in modo indipendente, ad eccezione delle funzioni attivate da HTTP, BLOB e Durable Functions che vengono ridimensionate nei propri gruppi. Per altre informazioni, vedere Ridimensionamento per funzione. Queste istanze vengono quindi ridimensionate in base alla concorrenza delle richieste.

  • Piano Premium: le dimensioni specifiche del piano Premium determinano la memoria e la CPU disponibili per tutte le app in tale piano in tale istanza. Il piano aumenta le istanze in base alle esigenze di ridimensionamento delle app nel piano e le app si ridimensionano all'interno del piano in base alle esigenze.

I file di codice delle funzioni vengono archiviati nelle condivisioni file di Azure nell'account di archiviazione principale. Quando si elimina l'account di archiviazione principale dell'app per le funzioni, i file di codice delle funzioni vengono eliminati e non possono essere recuperati.

Ridimensionamento in fase di runtime

Funzioni di Azure usa un componente denominato controller di scalabilità per monitorare la frequenza degli eventi e determinare se aumentare il numero di istanze 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 di archiviazione code di Azure, usa il ridimensionamento basato sulla destinazione.

L'unità di scalabilità per Funzioni di Azure è l'app per le funzioni. In caso di aumento del numero di istanze dell'app per le funzioni, vengono allocate più risorse per l'esecuzione di più istanze dell'host di Funzioni di Azure. In caso di riduzione delle richieste di calcolo, il controller di scalabilità rimuove le istanze dell'host di Funzioni. Il numero di istanze viene infine “ridotto” quando non sono in esecuzione funzioni all'interno di un'app per le funzioni.

Monitoraggio degli eventi e creazione delle istanze da parte del controller di scalabilità

Avvio a freddo

Se l'app per le funzioni diventa inattiva per alcuni minuti, la piattaforma potrebbe decidere di ridimensionare il numero di istanze in cui l'app viene eseguita fino a zero. La richiesta successiva ha la latenza aggiunta del ridimensionamento da zero a uno. Questa latenza viene definita avvio a freddo. Il numero di dipendenze richieste dall'app per le funzioni può influire sull'ora di inizio 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 l'avvio a freddo influisce sulle funzioni, è consigliabile usare un piano diverso da A consumo. Gli altri piani offrono queste strategie per attenuare o eliminare gli avvii a freddo:

  • Piano Premium: supporta sia le istanze preriscaldate che le istanze sempre pronte, con almeno un'istanza.

  • Piano A consumo flex: supporta un numero facoltativo di istanze sempre pronte, che possono essere definite in base al ridimensionamento per istanza.

  • Piano dedicato: il piano stesso non viene ridimensionato in modo dinamico, ma è possibile eseguire l'app in modo continuo con l'impostazione AlwaysOn abilitata.

Introduzione al ridimensionamento

Il ridimensionamento può variare in base a vari fattori, e le app ridimensionano diversamente a seconda dei trigger e della lingua selezionati. I comportamenti di ridimensionamento presentano alcune complessità da tenere presenti:

  • Numero massimo di istanze: una singola app per le funzioni può essere aumentata solo fino a un massimo consentito dal piano. Tuttavia, una singola istanza può elaborare più messaggi o richieste alla volta. È possibile specificare un valore massimo inferiore per limitare la scalabilità in base alle esigenze.
  • Frequenza delle nuove istanze: per i trigger HTTP, le nuove istanze vengono allocate al massimo una volta al secondo. Per i trigger non HTTP, le nuove istanze vengono allocate al massimo una volta ogni 30 secondi. Il ridimensionamento è più rapido se eseguito in un piano Premium.
  • Scalabilità basata su destinazione: il ridimensionamento basato su destinazione offre un modello di scalabilità rapido e intuitivo per i clienti ed è attualmente supportato per le code e gli argomenti del bus di servizio, le code di archiviazione, Hub eventi, Apache Kafka e le estensioni di Azure Cosmos DB. Assicurarsi di esaminare il ridimensionamento basato su destinazione per comprendere il comportamento di ridimensionamento.
  • Scalabilità per funzione: con alcune eccezioni rilevanti, le funzioni in esecuzione nel piano A consumo Flex 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 insieme come gruppo nelle stesse istanze. Analogamente, tutti i trigger di Durable Functions condividono anche le istanze e si ridimensionano insieme. Per altre informazioni, vedere Ridimensionamento per funzione.
  • Trigger monitorati massimi: Attualmente, il controller di ridimensionamento può monitorare solo fino a 100 trigger per prendere decisioni di ridimensionamento. Quando l'app ha più di 100 trigger basati su eventi, le decisioni di scalabilità vengono prese solo in base ai primi 100 trigger 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. Questo è più comune per i casi in cui un componente downstream come un database ha una velocità effettiva limitata. Per i limiti massimi di scalabilità quando si eseguono i vari piani di hosting, vedere Limiti di scalabilità.

Piano A consumo Flex

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

Si noti che, sebbene sia possibile modificare il numero massimo di istanze delle app di Consumo Flex fino a 1000, le app raggiungeranno un limite di quota 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 <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

In questo esempio viene usato 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

Piani A consumo/Premium

In un piano A consumo o Elastic 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>

Comportamenti di scalabilità orizzontale

Il ridimensionamento basato su eventi riduce automaticamente la capacità quando la domanda per le funzioni viene ridotta. A tale scopo, svuotare le istanze delle esecuzioni correnti della funzione e quindi rimuovere tali 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 comsumo Flex e Premium. La scalabilità guidata dagli eventi e questo comportamento non si applicano alle app del piano dedicato.

Per i comportamenti di scalabilità orizzontale si applicano le considerazioni seguenti:

  • Per l'app in esecuzione in Windows in un piano A consumo, solo le app create dopo maggio 2021 hanno comportamenti di modalità di svuotamento 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 una versione successiva dell'estensione del bus di servizio.

Ridimensionamento per funzione

Si applica solo al piano A consumo Flex (anteprima).

Il piano A consumo Flex è 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 nella scalabilità dell'app 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 di Durable Functions, che dispongono di istanze condivise.

Si consideri un'app per le funzioni ospitata in un piano A consumo Flex con questa funzione:

function1 function2 function3 function4 function5 function6 function7
Trigger HTTP Trigger HTTP Trigger di orchestrazione (Durable) Trigger attività (Durable) Trigger per bus di servizio Trigger per bus di servizio Trigger per Hub eventi

In questo esempio:

Procedure consigliate e modelli per app scalabili

Esistono molti aspetti di un'app per le funzioni che hanno un impatto sul ridimensionamento, ad esempio la configurazione dell'host, il footprint del runtime 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 Azure Functions (Come gestire le connessioni in Funzioni di Azure).

Se l'app ha più di 100 funzioni che usano trigger basati su eventi, valutare la possibilità di suddividere l'app in una o più app, in cui ogni app ha meno di 100 funzioni basate su eventi.

Per altre informazioni sul ridimensionamento in Python e Node.js, vedere Guida per sviluppatori Python per Funzioni di Azure - Ridimensionamento e concorrenza e Funzioni di Azure Node.js guida per sviluppatori - Ridimensionamento e concorrenza.

Passaggi successivi

Per ulteriori informazioni, vedere gli articoli seguenti: