Opzioni di hosting di Funzioni di Azure

Articolo
05/22/2024

Quando si crea un'app per le funzioni in Azure, è necessario scegliere un'opzione di hosting per l'app. Azure offre le opzioni di hosting seguenti per il codice della funzione:

Opzione Hosting	Service	Disponibilità	Supporto dei contenitori
Piano a consumo	Funzioni di Azure	Disponibilità Generale	None
Piano A consumo Flex	Funzioni di Azure	Anteprima	None
Piano Premium	Funzioni di Azure	Disponibilità generale	Linux
Piano dedicato	Funzioni di Azure	Disponibilità generale	Linux
App contenitore	App contenitore di Azure	Disponibilità generale	Linux

Le opzioni di hosting di Funzioni di Azure sono facilitate dall'infrastruttura del Servizio app di Azure nelle macchine virtuali Linux e Windows. L'opzione di hosting scelta determina i comportamenti seguenti:

Come viene ridimensionata l'app per le funzioni.
Le risorse disponibili per ogni istanza dell'app per le funzioni.
Il supporto per funzionalità avanzate, ad esempio la connettività della rete virtuale di Azure.
Supporto per i contenitori Linux.

Il piano scelto influisce anche sui costi per l'esecuzione del codice della funzione. Per altre informazioni, vedereFatturazione.

Questo articolo fornisce un confronto dettagliato tra le varie opzioni di hosting. Per altre informazioni sull'esecuzione e la gestione del codice della funzione nei contenitori Linux, vedere Supporto dei contenitori Linux in Funzioni di Azure.

Panoramica dei piani

Di seguito è riportato un riepilogo dei vantaggi delle varie opzioni per l'hosting di Funzioni di Azure:

Opzione	Vantaggi
Piano a consumo	Pagamento delle risorse di calcolo solo quando le funzioni sono in esecuzione (con pagamento in base al consumo) con scalabilità automatica. Quando si usa un piano a consumo, le istanze dell'host di Funzioni di Azure vengono aggiunte e rimosse in modo dinamico in base al numero di eventi in ingresso. ✔ Piano di hosting predefinito che fornisce un vero hosting serverless. ✔ Pagamento solo quando le funzioni sono in esecuzione. ✔ Ridimensionamento automatico, anche durante periodi di carico elevato.
Piano A consumo Flex	Ottenere scalabilità elevata con scelte di calcolo, rete virtuale e fatturazione con pagamento in base al consumo. Nel piano A consumo Flex, le istanze dell'host Funzioni vengono aggiunte e rimosse dinamicamente in base alla concorrenza configurata per istanza e al numero di eventi in ingresso. ✔ Riduzione degli avvii a freddo specificando un certo numero di istanze con provisioning preliminare (sempre pronte). ✔ Supporto della rete virtuale per una maggiore sicurezza. ✔ Pagamento quando le funzioni sono in esecuzione. ✔ Ridimensionamento automatico, anche durante periodi di carico elevato.
Piano Premium	Ridimensionamento automatico in base alla domanda usando ruoli di lavoro preriscaldati senza ritardo dopo l’inattività, esecuzione su istanze più potenti e connessioni alle reti virtuali. Prendere in considerazione il piano Premium di Funzioni di Azure nelle situazioni seguenti: ✔ Le app per le funzioni vengono eseguite in modo continuo o quasi continuo. ✔ Si desidera un maggiore controllo delle istanze e si desidera distribuire più app per le funzioni nello stesso piano con ridimensionamento guidato dagli eventi. ✔ Si dispone di un numero elevato di esecuzioni di piccole dimensioni e di una fattura di esecuzione elevata, ma di pochi GB al secondo nel piano A consumo. ✔ Occorrono più opzioni di CPU o memoria rispetto a quelle fornite dai piani a consumo. ✔ Il codice deve essere eseguito più a lungo del tempo di esecuzione massimo consentito nel piano A consumo. ✔ È necessaria la connettività alle reti virtuali. ✔ Si desidera fornire un'immagine Linux personalizzata in cui eseguire le funzioni.
Piano dedicato	Eseguire le funzioni all'interno di un piano di servizio app a tariffe del piano di servizio app regolari. Ideale per gli scenari a esecuzione prolungata in cui non si può usare Durable Functions. Prendere in considerazione un piano di servizio app nelle situazioni seguenti: ✔ Sono presenti macchine virtuali esistenti e sottoutilizzate che eseguono già altre istanze del Servizio app. ✔ È necessario avere una fatturazione completamente prevedibile oppure è necessario ridimensionare manualmente le istanze. ✔ Si desiderano eseguire più app Web e app per le funzioni nello stesso piano ✔ È necessario accedere a scelte di dimensioni di calcolo maggiori. ✔ Isolamento dell’ambiente di calcolo completo e accesso di rete sicuro fornito da un ambiente del servizio app (ASE). ✔ Utilizzo molto elevato della memoria ed elevata scalabilità (ASE).
App contenitore	Creare e distribuire app per le funzioni in contenitori in un ambiente completamente gestito ospitato da App contenitore di Azure. Usare il modello di programmazione di Funzioni di Azure per creare app per le funzioni native del cloud, serverless e basate su eventi. Eseguire le proprie funzioni insieme ad altri microservizi, API, siti Web e flussi di lavoro come programmi ospitati in contenitori. Prendere in considerazione l'hosting delle funzioni in App contenitore nelle situazioni seguenti: ✔ Si desidera creare pacchetti di librerie personalizzate con il codice della funzione per supportare app line-of-business. ✔ È necessario eseguire la migrazione dell'esecuzione del codice da app locali o legacy a microservizi nativi del cloud in esecuzione in contenitori. ✔ Quando si desidera evitare il sovraccarico e la complessità della gestione dei cluster di Kubernetes e del calcolo dedicato. ✔ Le funzioni richiedono potenza di elaborazione di fascia alta tramite risorse di calcolo GPU dedicate.

Le tabelle rimanenti di questo articolo confrontano le opzioni di hosting in base a diverse funzionalità e comportamenti.

Supporto dei sistemi operativi

Questa tabella illustra il supporto del sistema operativo per le opzioni di hosting.

Hosting	Distribuzione di Linux¹	Distribuzione di Windows²
Piano a consumo	✅ Solo codice ❌ Contenitore (non supportato)	✅ Solo codice
Piano A consumo Flex	✅ Solo codice ❌ Contenitore (non supportato)	❌ Non supportato
Piano Premium	✅ Solo codice ✅ Contenitore	✅ Solo codice
Piano dedicato	✅ Solo codice ✅ Contenitore	✅ Solo codice
App contenitore	✅ Solo contenitore	❌ Non supportato

¹ Linux è l'unico sistema operativo supportato per lo stack di runtime Python.
² Le distribuzioni di Windows sono solo codice. Funzioni attualmente non supporta contenitori Windows.

Durata del timeout di un'app per le funzioni

La durata del timeout per le funzioni in un'app per le funzioni è definita dalla proprietà functionTimeout nel file di progetto host.json. Questa proprietà si applica in modo specifico alle esecuzioni di funzioni. Dopo l'avvio dell'esecuzione della funzione, la funzione deve restituire/rispondere entro la durata del timeout. Per altre informazioni, vedere Migliorare le prestazioni e l'affidabilità di Funzioni di Azure.

La tabella seguente mostra i valori predefiniti e massimi (in minuti) per piani specifici:

Piano	Default	Massimo¹
Piano a consumo	5	10
Piano a consumo flex	30	Senza limitazioni²
Piano Premium	30³	Illimitati³
Piano dedicato	30⁴	Illimitati³

¹ Indipendentemente dall'impostazione di timeout dell'app per le funzioni, 230 secondi è la quantità di tempo massima che una funzione attivata da HTTP può impiegare per rispondere a una richiesta. Il motivo è legato al timeout di inattività predefinito di Azure Load Balancer. Per tempi di elaborazione più lunghi, provare a usare lo schema asincrono di Durable Functions oppure rinviare il processo effettivo e restituire una risposta immediata.
² In un piano A consumo Flex l'host non applica un limite di tempo di esecuzione. Tuttavia, al momento non esistono garanzie perché la piattaforma potrebbe dover terminare le istanze durante la riduzione, le distribuzioni o l'applicazione di aggiornamenti.
³ Il timeout predefinito per la versione 1.x del runtime di Funzioni è illimitato.
⁴ Garantito per un massimo di 60 minuti. L'applicazione di patch del sistema operativo e di runtime, l'applicazione di patch alle vulnerabilità e il ridimensionamento dei comportamenti possono comunque annullare le esecuzioni delle funzioni in modo da garantire la scrittura di funzioni affidabili.

Supporto di versioni in lingue diverse

Per informazioni dettagliate sul supporto corrente dello stack di linguaggi nativi in Funzioni, vedere Linguaggi supportati in Funzioni di Azure.

Ridimensiona

Nella tabella seguente vengono confrontati i comportamenti di ridimensionamento dei vari piani di hosting.
Le istanze massime vengono fornite in base a un'app per ogni funzione (consumo) o per piano (Premium/Dedicato), a meno che non diversamente indicato.

Piano	Aumentare il numero di istanze	Numero massimo di istanze
Piano a consumo	Basato sugli eventi. Aumenta automaticamente il numero di istanze, anche durante periodi di carico elevato. L'infrastruttura di Funzioni ridimensiona le risorse di CPU e memoria aggiungendo altre istanze dell'host di Funzioni in base al numero di eventi di trigger in ingresso.	Windows: 200 Linux: 100¹
Piano A consumo Flex	Ridimensionamento per funzione. Le decisioni di ridimensionamento guidate dagli eventi vengono calcolate in base a ogni funzione, che offre un modo più deterministico per ridimensionare le funzioni nell'app. Ad eccezione di HTTP, archiviazione BLOB (Griglia di eventi) e Durable Functions, tutti gli altri tipi di trigger di funzione nell'app vengono ridimensionati su istanze indipendenti. Tutti i trigger HTTP nell'app vengono ridimensionati insieme come gruppo nelle stesse istanze, come tutti i trigger di archiviazione BLOB (Griglia di eventi). Tutti i trigger di Durable Functions condividono anche le istanze e si ridimensionano insieme.	Limitato solo dall'utilizzo totale della memoria di tutte le istanze in una determinata area. Per altre informazioni, vedere Memoria dell'istanza.
Piano Premium	Basato sugli eventi. Aumento automatico del numero di istanze anche in periodo di carico elevato. L'infrastruttura di Funzioni di Azure ridimensiona le risorse di CPU e memoria aggiungendo altre istanze dell'host di Funzioni, in base al numero di eventi su cui vengono attivate le funzioni.	Windows: 100 Linux: 20-100²
Piano Dedicato³	Manual/autoscale	10-30 100 (ASE)

¹ Durante lo scale-out, attualmente è previsto un limite di 500 istanze per ogni sottoscrizione per ogni ora per le app Linux in un piano A consumo.
² In alcune aree, le app Linux in un piano Premium possono essere ridimensionate a 100 istanze. Per altre informazioni, vedere l'articolo Piano Premium.
³ Per i limiti specifici per le varie opzioni del piano di servizio app, vedere i Limiti del piano di servizio app.

Comportamento di avvio a freddo

Piano	Dettagli
Piano a consumo	Le app possono essere ridimensionate a zero quando sono inattive, per cui alcune richieste potrebbero avere una latenza maggiore all'avvio. Il piano a consumo include alcune ottimizzazioni che contribuiscono a ridurre il tempo di avvio a freddo, incluso il pull da funzioni segnaposto preriscaldate che già dispongono dell'host della funzione e dei processi del linguaggio in esecuzione.
Piano A consumo Flex	Supporta istanze sempre pronte per ridurre il ritardo durante il provisioning di nuove istanze.
Piano Premium	Supporta istanze sempre pronte per evitare l'avvio a freddo, consentendo di gestire una o più istanze a caldo perpetuamente.
Piano dedicato	Quando l’esecuzione avviene in un piano Dedicato, l'host di Funzioni può essere eseguito continuamente su un numero prestabilito di istanze, per cui l'avvio a freddo non rappresenta in realtà un problema.

Limiti del servizio

Conto risorse	Piano a consumo	Piano A consumo Flex¹²	Piano Premium	Piano Dedicato/ambiente del servizio app
Durata del timeout predefinita (min)	5	30	30	30¹
Durata del timeout massima (min)	10	senza limiti¹⁵	Senza limiti⁷	Senza limiti²
Numero massimo di connessioni in uscita (per istanza)	600 attive (1200 totali)	unbounded	unbounded	unbounded
Dimensioni massime della richiesta (MB)³	100	100	100	100
Lunghezza massima della stringa di query³	4096	4096	4096	4096
Lunghezza massima dell'URL della richiesta³	8192	8192	8192	8192
Unità di calcolo di Azure per istanza	100	variabile	210-840	100-840/210-250⁸
Dimensioni massime della memoria (GB per istanza)	1,5	4¹³	3,5-14	1.75-14/3.5-14
Numero massimo di istanze (Windows/Linux)	200/100	1000 ¹⁴	100/20	varia in base alla SKU/100⁹
App per le funzioni per piano¹¹	100	100	100	Senza limiti⁴
Piani del servizio app	100 per area	n/d	100 per gruppo di risorse	100 per gruppo di risorse
Slot di distribuzione per app¹⁰	2	n/d	3	1-20⁹
Archiviazione⁵	5 GB	250 GB	250 GB	50-1000 GB
Domini personalizzati per applicazione	500⁶	500	500	500
Supporto per il dominio personalizzato SSL	Connessione SNI SSL senza limiti inclusa	Connessioni SNI SSL senza limiti e 1 connessione IP SSL incluse	Connessioni SNI SSL senza limiti e 1 connessione IP SSL incluse	Connessioni SNI SSL senza limiti e 1 connessione IP SSL incluse

Note sui limiti del servizio:

Per impostazione predefinita, il timeout per il runtime di Funzioni 1.x in un piano di servizio app non prevede limiti.
Richiede l'impostazione del piano di servizio app su Always On. Pagamento con tariffe standard.
Questi limiti sono impostati nell'host.
Il numero effettivo di app per le funzioni che è possibile ospitare dipende dall'attività delle app, dalle dimensioni delle istanze del computer e dall'uso delle risorse corrispondente.
Il limite di archiviazione corrisponde alle dimensioni totali del contenuto nello spazio di archiviazione temporanea in tutte le app nello stesso piano di servizio app. Il piano a consumo usa File di Azure per l'archiviazione temporanea.
Quando l'app per le funzioni è ospitata in un piano A consumo, è supportata solo l'opzione CNAME. Per le app per le funzioni in un piano Premium o in un piano di servizio app, è possibile eseguire il mapping di un dominio personalizzato usando un record CNAME o A.
Garantito per un massimo di 60 minuti.
I ruoli di lavoro ospitano app di clienti I lavoratori sono disponibili in tre dimensioni fisse: una vCPU/3,5 GB di RAM; due vCPU/7 GB di RAM; quattro vCPU/14 GB di RAM.
Per informazioni dettagliate, vedere Limiti del servizio app.
Inclusione dello slot di produzione.
Attualmente è previsto un limite di 5000 app per le funzioni in una determinata sottoscrizione.
Il piano A consumo Flex è attualmente in anteprima.
Le dimensioni dell'istanza del piano A consumo Flex sono attualmente definite come 2.048 MB o 4.096 MB. Per altre informazioni, vedere memoria dell'istanza.
Il piano A consumo Flex durante l'anteprima prevede una quota di sottoscrizione a livello di area che limita l'utilizzo totale della memoria di tutte le istanze in una determinata area. Per altre informazioni, vedere Memoria dell'istanza.
In un piano A consumo Flex l'host non applica un limite di tempo di esecuzione. Tuttavia, al momento non esistono garanzie perché la piattaforma potrebbe dover terminare le istanze durante la riduzione, le distribuzioni o l'applicazione di aggiornamenti.

Funzionalità di rete

Funzionalità	Piano a consumo	Piano A consumo Flex	Piano Premium	Piano Dedicato/ambiente del servizio app
Restrizioni IP in ingresso	✅ Sì	✅ Sì	✅ Sì	✅ Sì
Endpoint privati in ingresso	❌ No	✅ Sì	✅ Sì	✅ Sì
Integrazione della rete virtuale	❌ No	✅ Sì (regionale)	✅ Sì (regionale)	✅ Sì (regionale e gateway)
Trigger della rete virtuale (non HTTP)	❌ No	✅ Sì	✅ Sì	✅ Sì
Connessioni ibride (solo Windows)	❌ No	❌ No	✅ Sì	✅ Sì
Restrizioni IP in uscita	❌ No	✅ Sì	✅ Sì	✅ Sì

Fatturazione

Piano	Dettagli
Piano a consumo	Pagamento solo per il periodo in cui le funzioni sono in esecuzione. La fatturazione si basa sul numero di esecuzioni, il tempo di esecuzione e la memoria usata.
Piano A consumo Flex	La fatturazione si basa sul numero di esecuzioni, sulla memoria delle istanze quando eseguono funzioni attivamente, oltre al costo di tutte le istanze sempre pronte. Per altre informazioni, vedere Fatturazione nel piano A consumo Flex.
Piano Premium	Il piano Premium si basa sul numero di secondi di core e sulla memoria usati nelle istanze necessarie e preriscaldate. Almeno un'istanza per piano deve essere sempre mantenuta calda. Questo piano fornisce i prezzi più prevedibili.
Piano dedicato	Per le app per le funzioni in un piano di servizio app si paga lo stesso importo che si pagherebbe per altre risorse del servizio app, ad esempio le app Web. Per un ambiente del servizio app è disponibile una tariffa mensile fissa che si paga per l'infrastruttura e non cambia con le dimensioni dell'ambiente. È previsto anche un costo per vCPU del piano di servizio app. Tutte le app ospitate in un ambiente del servizio app fanno parte di uno SKU di prezzi isolato. Per altre informazioni, vedere l'articolo sulla panoramica dell'ambiente del servizio app.

Per un confronto diretto dei costi tra piani di hosting dinamici (A consumo, A consumo Flex e Premium), vedere la pagina dei prezzi di Funzioni di Azure. Per i prezzi delle varie opzioni del piano Dedicato, vedere la pagina dei prezzi del servizio app. Per i prezzi dell'hosting delle app contenitore, vedere Prezzi di App contenitore di Azure.

Limitazioni per la creazione di nuove app per le funzioni in un gruppo di risorse esistente

In alcuni casi, quando si tenta di creare un nuovo piano di hosting per la propria app per le funzioni in un gruppo di risorse esistente, è possibile che venga visualizzato uno degli errori seguenti:

Il piano tariffario non è consentito in questo gruppo di risorse
I ruoli di lavoro <SKU_name> non sono disponibili nel gruppo di risorse <resource_group_name>

Ciò può verificarsi quando vengono soddisfatte le condizioni seguenti:

Si crea un'app per le funzioni in un gruppo di risorse esistente che non ha mai contenuto un'altra app per le funzioni o un'app Web. Ad esempio, le app a consumo per Linux non sono supportate nello stesso gruppo di risorse dei piani Linux Dedicati o Linux Premium.
La nuova app per le funzioni viene creata nella stessa area dell'app precedente.
L'app precedente è in qualche modo incompatibile con la nuova app. Questo errore può verificarsi tra SKU, sistemi operativi o a causa di altre funzionalità a livello di piattaforma, ad esempio il supporto della zona di disponibilità.

Il motivo è dovuto alla modalità di mapping dei piani di app per le funzioni e app Web a pool di risorse diversi durante la creazione. Sku diversi richiedono un set diverso di funzionalità dell'infrastruttura. Quando si crea un'app in un gruppo di risorse, tale gruppo di risorse viene mappato e assegnato a un pool specifico di risorse. Se si tenta di creare un altro piano in tale gruppo di risorse e il pool mappato non dispone delle risorse necessarie, si verifica questo errore.

Quando si verifica questo errore, creare, invece, l'app per le funzioni e il piano di hosting in un nuovo gruppo di risorse.

Condividi tramite