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 |
- 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 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 |
- 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.
- 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.
- Richiede l'impostazione del piano di servizio app su Always On. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
- Il timeout predefinito per la versione 1.x del runtime di Funzioni è senza limiti.
- 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 |
- 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 aumentare fino 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 Limiti del piano di servizio app.
- 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:
- 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. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
- 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. Per i piani a consumo in Linux, lo spazio di archiviazione è attualmente di 1,5 GB.
- 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.
- 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.
- 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.
- 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.
- Quando il numero minimo di repliche è impostato su zero, il timeout predefinito dipende dai trigger specifici usati nell'app.
- Quando il numero minimo di repliche è impostato su uno o più.
- 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.