Hosting del piano a consumo Flex di Funzioni di Azure

  • Articolo

Consumo Flex è un piano di hosting di Funzioni di Azure basato su Linux che si basa sul modello di fatturazione serverless di pagamento a consumo per ciò che si usa. Offre maggiore flessibilità e personalizzazione introducendo networking privato, selezione delle dimensioni per la memoria dell'istanza e funzionalità scale-out veloci/ampie di scalabilità ancora basate su un modello serverless.

Importante

Il piano a consumo Flex è attualmente in anteprima. Per un elenco delle limitazioni correnti per l'uso di questo piano di hosting, vedere Considerazioni. Per informazioni aggiornate sulla fatturazione durante l'anteprima, vedere Fatturazione.

Nel repository di esempi di piani a consumo Flex è possibile esaminare i campioni end-to-end che includono il piano a consumo Flex.

Vantaggi

Il piano a consumo Flex si basa sui punti di forza del piano a consumo, tra cui ridimensionamento dinamico e fatturazione basata sull'esecuzione. Il piano a consumo Flex offre anche queste funzionalità aggiuntive:

Questa tabella consente di confrontare in modo diretto le funzionalità del piano a consumo Flex con il piano di hosting a consumo:

Funzionalità Consumo Piano a consumo Flex
Scalabilità a zero ✅ Sì ✅ Sì
Comportamento della scalabilità Guidato dagli eventi Guidato dagli eventi (veloce)
Reti virtuali ❌ Non supportato ✅ supportato
Calcolo dedicato (attenuare gli avvii a freddo) ❌ Nessuno ✅ Istanze sempre pronte (facoltativo)
Fatturazione Solo tempo di esecuzione Tempo di esecuzione e istanze sempre pronte
Istanze di scale-out (max) 200 1000

Per un raffronto completo del piano a consumo Flex rispetto al piano a consumo e a tutti gli altri tipi di piano e hosting, vedere Opzioni di scalabilità e hosting delle funzioni.

Integrazione della rete virtuale

Il piano a consumo Flex si espande sui tradizionali vantaggi del piano a consumo aggiungendo il supporto per l'integrazione della rete virtuale. Le app eseguite in un piano a consumo Flex, possono connettersi ad altri servizi di Azure protetti all'interno di una rete virtuale. Questo consente comunque di sfruttare la fatturazione e la scalabilità serverless, oltre ai vantaggi di scalabilità e velocità effettiva del piano a consumo Flex. Per altre informazioni, vedere Abilitare l'integrazione della rete virtuale.

Memoria istanza

Durante la creazione dell'app per le funzioni in un piano a consumo Flex, è possibile selezionare le dimensioni di memoria delle istanze in cui viene eseguita l'app. Per informazioni su come le dimensioni della memoria dell'istanza influiscono sui costi dell'app vedere Fatturazione.

Attualmente, il piano a consumo Flex offre opzioni di dimensioni della memoria dell'istanza sia di 2,048 MB sia di 4.096 MB.

Nel decidere la dimensioni di memoria dell'istanza da usare con le app, considerare alcuni aspetti:

  • La dimensione di memoria dell'istanza di 2.048 MB è l'impostazione predefinita e deve essere usata per gran parte degli scenari. Usare le dimensioni di memoria dell'istanza di 4.096 MB per gli scenari in cui l'app richiede una maggiore concorrenza o una potenza di elaborazione superiore. Per altre informazioni, vedere Configurare la memoria dell'istanza.
  • Le dimensioni della memoria dell'istanza sono modificabili in qualsiasi momento. Per altre informazioni, vedere Configurare la memoria dell'istanza.
  • Le risorse dell'istanza sono condivise tra il codice della funzione e l'host Funzioni.
  • Maggiore è la dimensione di memoria dell'istanza, tante più istanze è possibile gestire in termini di esecuzioni simultanee o carichi di lavoro di CPU o memoria più intensivi. Le decisioni di scalabilità specifiche si basano sul carico di lavoro.
  • La concorrenza predefinita dei trigger HTTP dipende dalle dimensioni della memoria dell'istanza. Per altre informazioni, vedere concorrenza del trigger HTTP.
  • Le CPU disponibili e la larghezza di banda di rete sono fornite in modo proporzionale a una dimensione di istanza specifica.

Ridimensionamento per funzione

La concorrenza è un fattore chiave che determina la scalabilità delle app per le funzioni del piano a consumo Flex. Per migliorare le prestazioni di ridimensionamento delle app con vari tipi di trigger, il piano a consumo Flex offre un modo più deterministico per ridimensionare l'app per funzione.

Questo comportamento di ridimensionamento per funzione è parte della piattaforma di hosting, quindi non è necessario configurare l'app o modificare il codice. Per altre informazioni, vedere Ridimensionamento per funzione nell'articolo Ridimensionamento guidato dagli eventi.

Nel ridimensionamento per funzione, le decisioni vengono prese per determinati trigger di funzione, in base alle aggregazioni di gruppi. La seguente tabella mostra il set definito di gruppi di scalabilità di funzioni:

Gruppi di scalabilità Trigger nel gruppo Valore delle impostazioni
Trigger HTTP Trigger HTTP
Trigger SignalR		 http
Trigger di archiviazione BLOB
(basato su Griglia di eventi)		 Trigger di archiviazione BLOB blob
Funzioni durevoli Trigger di orchestrazione
Trigger attività
Trigger entità		 durable

Tutte le altre funzioni nell'app vengono ridimensionate singolarmente nel proprio set di istanze, a cui viene fatto riferimento usando la convenzione function:<NAMED_FUNCTION>.

Istanze sempre pronte

Il piano a consumo Flex include una funzionalità sempre pronta che consente di scegliere istanze sempre in esecuzione e assegnate a ognuno dei gruppi o funzioni di scalabilità per funzione. Questa è un'ottima opzione per gli scenari in cui occorre avere un numero minimo di istanze sempre pronte per gestire le richieste, ad esempio per ridurre la latenza di avvio a freddo dell'applicazione. Il valore predefinito è 0 (zero).

Ad esempio, se sempre pronte viene impostato su 2 per il gruppo HTTP di funzioni, la piattaforma mantiene due istanze sempre in esecuzione e assegnate all'app per le funzioni HTTP nell'app. Queste istanze elaborano le esecuzioni di funzione, ma a seconda delle impostazioni di concorrenza, la piattaforma viene ridimensionata oltre le due istanze con istanze su richiesta.

Per informazioni su come configurare le istanze sempre pronte, vedere Impostare il numero di istanze sempre pronte.

Concorrenza

La concorrenza fa riferimento al numero di esecuzioni simultanee di una funzione in un'istanza dell'app. È possibile impostare un numero massimo di esecuzioni simultanee che ciascuna istanza dovrà gestire in un determinato momento. Per altre informazioni, vedere concorrenza del trigger HTTP.

La concorrenza impatta in modo diretto sulla scalabilità dell'app perché a livelli di concorrenza inferiori, sono necessarie più istanze per gestire la domanda guidata dagli eventi per una funzione. Sebbene sia possibile controllare e ottimizzare la concorrenza, sono disponibili alcune impostazioni predefinite adatte alla maggior parte dei casi. Per informazioni su come impostare i limiti di concorrenza per le funzioni di trigger HTTP, vedere Impostare i limiti di concorrenza HTTP.

Distribuzione

Le distribuzioni nel piano A consumo Flex seguono un unico percorso. Dopo aver compilato e compresso il codice del progetto in un pacchetto dell’applicazione, viene distribuito in un contenitore di archiviazione BLOB. All'avvio, l'app ottiene il pacchetto ed esegue il codice della funzione di questo pacchetto. Per impostazione predefinita, uno stesso account di archiviazione usato per archiviare i metadati host interni (AzureWebJobsStorage) viene usato anche come contenitore di distribuzione. Tuttavia, è possibile usare un account di archiviazione alternativo o scegliere il metodo di autenticazione preferito configurando le impostazioni di distribuzione dell’app. Nella semplificazione del percorso di distribuzione, non è più necessario che le impostazioni dell'app influiscano sul comportamento della distribuzione.

Fatturazione

La determinazione dei costi di esecuzione delle app con il piano a consumo Flex avviene in base a due modalità. Ciascuna modalità è determinata per istanza.

Modalità di fatturazione Descrizione
On demand Nell'esecuzione in modalità on demand, il codice della funzione viene fatturato solo per il periodo di tempo in cui il codice della funzione viene eseguito nelle istanze disponibili. La modalità on demand non richiede un numero minimo di istanze. La fatturazione concerne:

• La quantità totale di memoria di cui è stato effettuato il provisioning mentre ogni istanza on demand esegue attivamente funzioni (in GB al secondo), meno una concessione gratuita di GB-s al mese.
• Il numero totale di esecuzioni, meno una concessione gratuita (un numero) di esecuzioni al mese.
Sempre pronte È possibile configurare una o più istanze, assegnate a tipi di trigger specifici (HTTP/Durable/BLOB) e singole funzioni, sempre disponibili per gestire le richieste. Con l'abilitazione delle istanze sempre pronte, la fatturazione concerne:

• Quantità totale di memoria di cui è stato effettuato il provisioning in tutte le istanze sempre pronte, note come baseline (in GB al secondo).
• La quantità totale di memoria di cui è stato effettuato il provisioning durante il tempo in cui ogni istanza sempre pronta sta eseguendo attivamente le funzioni (in GB al secondo).
• Il numero totale di esecuzioni.

La fatturazione sempre pronte non prevede concessioni gratuite.

Il periodo di esecuzione minimo fatturabile per entrambe le modalità di esecuzione è 1.000 ms. Successivamente, il periodo di attività fatturabile viene arrotondato a 100 ms più vicini. Per informazioni dettagliate sui contatori di fatturazione del piano a consumo Flex, vedere Riferimento monitoraggio.

Per informazioni dettagliate sulla modalità di calcolo dei costi quando si esegue in un piano a consumo Flex, inclusi alcuni esempi, vedere Costi calcolati a consumo.

Per le informazioni più aggiornate sui prezzi di esecuzione, sui costi baseline di sempre pronte e sulle concessioni gratuite per le esecuzioni on demand, vedere Pagina prezzi di Funzioni di Azure.

Versioni stack di linguaggio supportate

Questa tabella mostra le versioni dello stack di linguaggio attualmente supportate per le app con piano a consumo Flex:

Stack linguaggio Versione richiesta
C# (modalità processo isolato)1 .NET 82
Java Java 11, Java 17
Node.js Node 20
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11

1La modalità C# In-Process non è supportata. È invece necessario eseguire la migrazione del progetto di codice .NET da eseguire nel modello del ruolo di lavoro isolato.
2Richiede la versione 1.20.0 o successiva di Microsoft.Azure.Functions.Worker e la versione 1.16.2 o successiva di Microsoft.Azure.Functions.Worker.Sdk.

Quote di memoria della sottoscrizione a livello di area

Attualmente in anteprima, ogni area in una determinata sottoscrizione ha un limite di memoria di 512,000 MB per tutte le istanze di app in esecuzione nei piani A consumo Flex. Ciò significa che, in una determinata sottoscrizione e area, è possibile avere qualsiasi combinazione di dimensioni e conteggi della memoria dell'istanza, purché rimangano al di sotto del limite di quota. Ad esempio, ogni esempio seguente indica che la quota è stata raggiunta e le app interrompono il ridimensionamento:

  • Si dispone di un'app da 2.048 MB ridimensionata a 100 istanze e di una seconda app da 2.048 MB ridimensionata a 150 istanze
  • Si dispone di un'app da 2.048 MB con un aumento a 250 istanze
  • Si dispone di un'app da 4.096 MB con un aumento a 125 istanze
  • Si dispone di un'app da 4.096 MB ridimensionata a 100 istanze e di un'app da 2.048 MB ridimensionata a 50 istanze

Questa quota può essere aumentata per consentire alle app incluse nel piano A consumo Flex di aumentare ulteriormente le prestazioni, a seconda delle esigenze. Se le app richiedono una quota maggiore, creare un ticket di supporto.

Proprietà e impostazioni deprecate

Nel piano a consumo Flex, molte delle impostazioni di applicazione standard e proprietà di configurazione del sito usate in Bicep, nei modelli ARM e nel piano di controllo complessivo, sono deprecate o spostate, e non devono essere usate durante l'automazione della creazione delle risorse dell'app per le funzioni. Per altre informazioni, vedere Deprecazione nel piano a consumo Flex.

Considerazioni

Quando si usa il piano a consumo Flex durante l'anteprima corrente, tenere presenti queste altre considerazioni:

  • Host: è previsto un timeout di 30 secondi per l'inizializzazione dell'app. Se l'avvio dell'app per le funzioni richiede più di 30 secondi, verranno visualizzate voci System.TimeoutException correlate a gRPC. Questo timeout sarà configurabile e verrà implementata un'eccezione più chiara come parte di questo elemento di lavoro dell'host.
  • Durable Functions: Archiviazione di Azure è attualmente l'unico provider di archiviazione supportato per Durable Functions quando è ospitato nel piano Flex Consumption. Vedere le raccomandazioni per l'hosting di Durable Functions nel piano Flex Consumption.
  • Integrazione rete virtuale Assicurarsi che il provider di risorse di Azure Microsoft.App sia abilitato per la sottoscrizione seguendo queste istruzioni. La delega della subnet richiesta dalle app A consumo Flex è Microsoft.App/environments.
  • Trigger: sono completamente supportati tutti i trigger, ad eccezione dei trigger Kafka e Azure SQL. Il trigger di archiviazione BLOB supporta solo l'origine Griglia di eventi. Le app per le funzioni non C# devono usare la versione [4.0.0, 5.0.0) del bundle di estensione o una versione successiva.
  • Aree: attualmente non tutte le aree sono supportate. Per altre informazioni, vedere Visualizzare le aree attualmente supportate.
  • Distribuzioni: gli slot di distribuzione non sono attualmente supportati.
  • Scala: la scala massima più bassa nell'anteprima è 40. Il valore più alto attualmente supportato è 1000.
  • Dipendenze gestite: le dipendenze gestite in PowerShell non sono supportate dal piano A consumo Flex. È invece necessario definire moduli personalizzati.
  • Impostazioni di diagnostica: le impostazioni di diagnostica non sono attualmente supportate.
  • Certificati: il caricamento dei certificati con l'impostazione dell'app WEBSITE_LOAD_CERTIFICATES non è attualmente supportato.
  • Riferimenti all'insieme di credenziali delle chiavi: i riferimenti a Key Vault nelle impostazioni dell'app non funzionano quando l'accesso alla rete è limitato, anche se l'app per le funzioni ha Rete virtuale integrazione. La soluzione alternativa corrente consiste nel fare riferimento direttamente all'insieme di credenziali delle chiavi nel codice e leggere i segreti necessari.
  • File di Azure montaggio di condivisione file: il montaggio di una condivisione file File di Azure non funziona quando l'app per le funzioni ha Rete virtuale integrazione.

Opzioni di hosting di Funzioni di Azure Creare e gestire le app per le funzioni nel piano a consumo Flex