Hosting del piano a consumo Flex di Funzioni di Azure
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.
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:
- Istanze sempre pronte
- Integrazione della rete virtuale
- Ridimensionamento rapido basato sulla concorrenza per le app HTTP e non HTTP
- Più scelte, ad esempio, le dimensioni della memoria
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. |
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.
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.
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, ogni area in una determinata sottoscrizione prevede un limite di memoria per 512,000 MB
tutte le istanze di app in esecuzione nei piani Flex Consumption. 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
Tenere presenti queste altre considerazioni quando si usa il piano flex consumption:
- Host: è previsto un timeout di 30 secondi per l'inizializzazione dell'app. Quando l'app per le funzioni richiede più di 30 secondi per l'avvio, potrebbero essere visualizzate voci correlate a
System.TimeoutException
gRPC registrate. Non è attualmente possibile configurare questo timeout. Per altre informazioni, vedere questo elemento di lavoro 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 della rete virtuale Assicurarsi che il
Microsoft.App
provider di risorse di Azure 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 è attualmente
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 a Key Vault: i riferimenti a Key Vault nelle impostazioni dell'app non funzionano quando Key Vault è limitato all'accesso di rete, 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.
Articoli correlati
Opzioni di hosting di Funzioni di Azure Creare e gestire le app per le funzioni nel piano a consumo Flex