Ridimensionamento basato su eventi in Funzioni di Azure
Nei piani a consumo e Premium Funzioni di Azure ridimensiona le risorse di CPU e memoria aggiungendo altre istanze dell'host di Funzioni. Il numero di istanze viene determinato in base al numero di eventi che attivano una funzione.
Ogni istanza dell'host funzioni nel piano a consumo è limitata, in genere a 1,5 GB di memoria e a una CPU. Un'istanza dell'host è l'intera app per le funzioni. In altre parole, tutte le funzioni all'interno di un'app per le funzioni condividono le risorse all'interno di un'istanza e vengono dimensionate contemporaneamente. Le app per le funzioni che condividono lo stesso piano a consumo vengono dimensionate in modo indipendente. Nel piano Premium le dimensioni del piano determinano la memoria e la CPU disponibili per tutte le app in una specifica istanza.
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 "ridimensionato" quando non viene eseguita alcuna funzione all'interno di un'app per le funzioni.
Avvio a freddo
Dopo che l'app per le funzioni è stata inattiva per un certo numero di minuti, la piattaforma può ridurre 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, prendere in considerazione l'esecuzione in un piano Premium o in un piano dedicato con l'impostazione Always On abilitata.
Introduzione al ridimensionamento
Il ridimensionamento può variare in base a diversi fattori e le app vengono ridimensionate in modo diverso in base ai trigger e alla lingua selezionati. I comportamenti di ridimensionamento presentano alcune complessità da tenere presenti:
- Numero massimo di istanze: una singola app per le funzioni aumenta solo fino a un massimo consentito dal piano. Una singola istanza può elaborare più di un messaggio o più di una richiesta alla volta. Pertanto, non esiste alcun limite per quanto riguarda il numero di esecuzioni parallele. È 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 bus di servizio, le code Archiviazione, hub eventi e le estensioni cosmos DB. Assicurarsi di esaminare il ridimensionamento basato su destinazione per comprendere il comportamento di ridimensionamento.
Limitare lo scale-out
È possibile limitare il numero massimo di istanze usate da un'app per aumentare le prestazioni. Questo scenario è più comune per i casi in cui un componente downstream, come un database, ha una velocità effettiva limitata. Per impostazione predefinita, le funzioni del piano a consumo vengono aumentate fino a un massimo di 200 istanze e le funzioni del piano Premium fino a un massimo di 100 istanze. È possibile specificare un limite massimo inferiore per un'app specifica modificando il valore 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 del piano Premium. La scalabilità guidata dagli eventi e questo comportamento non si applica alle app del piano dedicato.
Per i comportamenti di scalabilità orizzontale si applicano le considerazioni seguenti:
- Per le app per le funzioni del piano a consumo in esecuzione in Windows, 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 usando il trigger bus di servizio, usare la versione 4.2.0 o una versione successiva dell'estensione bus di servizio.
Procedure consigliate e modelli per app scalabili
Esistono molti aspetti di un'app per le funzioni che influiscono sulla scalabilità, tra cui la configurazione dell'host, il footprint di 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).
Per altre informazioni sul ridimensionamento in Python e Node.js, vedere Funzioni di Azure Guida per sviluppatori Python - Ridimensionamento e concorrenza e guida per sviluppatori Funzioni di Azure Node.js - Ridimensionamento e concorrenza.
Modello di fatturazione
La fatturazione per i diversi piani è descritta in dettaglio nella pagina dei prezzi Funzioni di Azure. L'utilizzo viene aggregato a livello di app per le funzioni e viene calcolato solo il tempo di esecuzione del codice di tale funzione. Per la fatturazione vengono usate le unità seguenti:
- Utilizzo delle risorse in gigabyte al secondo (GB-s). Calcolato come combinazione di dimensioni di memoria e tempo di esecuzione per tutte le funzioni in un'app per le funzioni.
- Esecuzioni. Conteggiate ogni volta che una funzione viene eseguita in risposta a un trigger di evento.
Le query e le informazioni utili su come comprendere la fattura a consumo sono disponibili nelle domande frequenti sulla fatturazione.
Passaggi successivi
Per ulteriori informazioni, vedere gli articoli seguenti: