Opzioni di hosting di Funzioni di Azure

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 Linux1 Distribuzione di Windows2
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
  1. Linux è l'unico sistema operativo supportato per lo stack di runtime Python.
  2. 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 evitare timeout, è importante scrivere funzioni solide. 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 Massimo1
Piano a consumo 5 10
Piano a consumo flex 30 Unbounded2
Piano Premium 304 Unbounded2
Piano dedicato 304 Unbounded3
App contenitore 30 Senza vincoli5
  1. 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.
  2. Non è prevista l'applicazione di una durata di esecuzione del timeout massima. Tuttavia, il periodo di tolleranza previsto per l'esecuzione di una funzione è di 60 minuti durante la riduzione per i piani a consumo Flex e Premium e un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
  3. Richiede l'impostazione del piano di servizio app su Always On. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
  4. Il timeout predefinito per la versione 1.x del runtime di Funzioni è senza limiti.
  5. Quando il numero minimo di repliche è impostato su zero, il timeout predefinito dipende dai trigger specifici usati nell'app.

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: 1001
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-1002
Piano Dedicato3 Manual/autoscale 10-30
100 (ASE)
App contenitore 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. 300-10004
  1. 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.
  2. In alcune aree, le app Linux in un piano Premium possono aumentare fino a 100 istanze. Per altre informazioni, vedere l'articolo Piano Premium.
  3. Per i limiti specifici per le varie opzioni del piano di servizio app, vedere Limiti del piano di servizio app.
  4. In App contenitore, il valore predefinito è 10 istanze, ma è possibile impostare il numero massimo di repliche, che ha un massimo complessivo di 1000. Questa impostazione viene rispettata purché sia disponibile una quota di core sufficiente. Quando si crea l'app per le funzioni dal portale di Azure, sono limitate a 300 istanze.

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 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.
App contenitore Dipende dal numero minimo di repliche:
• Se impostato su zero: le app possono essere ridimensionate su zero quando sono inattive e alcune richieste potrebbero avere una latenza maggiore all'avvio.
• Se impostato su uno o più: il processo host viene eseguito in modo continuo, il che significa che l'avvio a freddo non è un problema.

Limiti del servizio

Conto risorse Piano a consumo Piano A consumo Flex13 Piano Premium Piano Dedicato/ambiente del servizio app App contenitore
Durata del timeout predefinita (min) 5 30 30 301 3016
Durata del timeout massima (min) 10 senza limiti8 senza limiti8 Senza limiti2 senza limiti17
Numero massimo di connessioni in uscita (per istanza) 600 attive (1200 totali) unbounded unbounded unbounded unbounded
Dimensioni massime della richiesta (MB)3 100 100 100 100 100
Lunghezza massima della stringa di query3 4096 4096 4096 4096 4096
Lunghezza massima dell'URL della richiesta3 8192 8192 8192 8192 8192
Unità di calcolo di Azure per istanza 100 variabile 210-840 100-840/210-2509 variabile
Dimensioni massime della memoria (GB per istanza) 1,5 414 3,5-14 1.75-14/3.5-14 variabile
Numero massimo di istanze (Windows/Linux) 200/100 1000 15 100/20 varia in base alla SKU/10010 10-30018
App per le funzioni per piano12 100 100 100 Senza limiti4 Senza limiti4
Piani del servizio app 100 per area n/d 100 per gruppo di risorse 100 per gruppo di risorse n/d
Slot di distribuzione per app11 2 n/d 3 1-2010 non supportato
Archiviazione (temporanea)5 0.5 GB 0,8 GB 21-140 GB 11-140 GB n/d
Archiviazione (persistente) 1 GB6 0 GB6 250 GB 10-1000 GB10 n/d
Domini personalizzati per applicazione 5007 500 500 500 non supportato
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 non supportato

Note sui limiti del servizio:

  1. Per impostazione predefinita, il timeout per il runtime di Funzioni 1.x in un piano di servizio app non prevede limiti.
  2. Richiede l'impostazione del piano di servizio app su Always On. Pagamento con tariffe standard. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
  3. Questi limiti sono impostati nell'host.
  4. 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.
  5. 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. Per i piani a consumo in Linux, lo spazio di archiviazione è attualmente di 1,5 GB.
  6. Il piano a consumo usa una condivisione file di Azure per l'archiviazione persistente. Quando si specifica una condivisione file di Azure personalizzata, i limiti di dimensione della condivisione specifici dipendono dall'account di archiviazione impostato per WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. In Linux è necessario montare in modo esplicito la condivisione file di Azure per i piani Flex Consumption e Consumption.
  7. 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.
  8. Non è prevista l'applicazione di una durata di esecuzione del timeout massima. Tuttavia, il periodo di tolleranza previsto per l'esecuzione di una funzione è di 60 minuti durante la riduzione e 10 minuti durante gli aggiornamenti della piattaforma.
  9. 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.
  10. Per informazioni dettagliate, vedere Limiti del servizio app.
  11. Inclusione dello slot di produzione.
  12. Attualmente è previsto un limite di 5000 app per le funzioni in una determinata sottoscrizione.
  13. Il piano A consumo Flex è attualmente in anteprima.
  14. 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.
  15. 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.
  16. Quando il numero minimo di repliche è impostato su zero, il timeout predefinito dipende dai trigger specifici usati nell'app.
  17. Quando il numero minimo di repliche è impostato su uno o più.
  18. In App contenitore è possibile impostare il numero massimo di repliche, che viene rispettato solo se è disponibile una quota di core sufficiente.

Funzionalità di rete

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

*Per altre informazioni, vedere Reti nell’ambiente App contenitore di Azure.

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.
App contenitore La fatturazione in App contenitore di Azure si basa sul tipo di piano. Per altre informazioni, vedere Fatturazione in App contenitore di Azure.

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.

Passaggi successivi