Opzioni di hosting di Funzioni di Azure
Quando si crea un'app per le funzioni in Azure, è necessario scegliere un piano di hosting per l'app. Esistono tre piani di hosting Funzioni di Azure di base forniti da Funzioni di Azure: piano a consumo, piano Premium e Piano dedicato (servizio app). Questi piani di hosting sono facilitati dall'infrastruttura del servizio app Azure e sono disponibili a livello generale nelle macchine virtuali Linux e Windows.
Il piano di hosting Funzioni di Azure scelto 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.
Oltre a Funzioni di Azure hosting, è anche possibile ospitare app per le funzioni in contenitori che possono essere distribuite nei cluster Kubernetes o in App Contenitore di Azure. Se si sceglie di ospitare le funzioni in un cluster Kubernetes, è consigliabile usare un cluster Kubernetes abilitato per Azure Arc. Per altre informazioni sulla distribuzione di app contenitore personalizzate, vedere Hosting di app contenitore di Azure di Funzioni di Azure.
Questo articolo fornisce un confronto dettagliato tra i vari piani di hosting, incluse le opzioni di hosting basate su contenitori.
Nota
L'hosting di contenitori Funzioni di Azure sia nei cluster Kubernetes abilitati per Azure Arc che nelle app contenitore di Azure è attualmente in anteprima.
Panoramica dei piani
Di seguito è riportato un riepilogo dei vantaggi dei tre principali piani di hosting Funzioni di Azure:
| Piano | Vantaggi |
|---|---|
| Piano a consumo | Aumenta o riduci automaticamente le prestazioni e paga i costi delle risorse di calcolo solo quando le funzioni sono in esecuzione. 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. ✔ Pagare solo quando le funzioni sono in esecuzione. ✔ Ridimensiona automaticamente, anche durante periodi di carico elevato. |
| Piano Premium | Consente di dimensionare automaticamente in base alla domanda usando ruoli di lavoro preriscaldati che eseguono le applicazioni senza ritardi dopo l'inattività, di usare istanze più potenti per l'esecuzione e di connettersi alle reti virtuali. Prendere in considerazione il piano Funzioni di Azure Premium nelle situazioni seguenti: ✔ Le app per le funzioni vengono eseguite continuamente o quasi continuamente. ✔ Si dispone di un numero elevato di esecuzioni di piccole dimensioni e di una fattura di esecuzione elevata, ma di pochi GB nel piano a consumo. ✔ Sono necessarie più opzioni di CPU o memoria rispetto a quelle fornite dal piano a consumo. ✔ Il codice deve essere eseguito più a lungo del tempo di esecuzione massimo consentito nel piano a consumo. ✔ Sono necessarie funzionalità non disponibili nel piano a consumo, ad esempio la connettività di rete virtuale. ✔ Si vuole 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 regolari del piano servizio app. Ideale per gli scenari a esecuzione prolungata in cui non si può usare Durable Functions. Si consideri un piano servizio app nelle situazioni seguenti: ✔ Sono presenti macchine virtuali sottoutilizzate che eseguono già altre istanze di servizio app. ✔ Sono necessari il ridimensionamento predittivo e i costi. |
Le tabelle di confronto in questo articolo includono anche le opzioni di hosting seguenti, che forniscono la quantità più elevata di controllo e isolamento in cui eseguire le app per le funzioni.
| Opzione Hosting | Dettagli |
|---|---|
| ASE | L'ambiente del servizio app di Azure è una funzionalità del servizio app di Azure che offre un ambiente completamente isolato e dedicato per l'esecuzione sicura delle app del servizio app su larga scala. Le edizione Standard sono appropriate per i carichi di lavoro dell'applicazione che richiedono: ✔ Scala molto elevata. ✔ Isolamento di calcolo completo e accesso sicuro alla rete. ✔ Utilizzo elevato della memoria. |
| App contenitore di Azure | App Azure Container è un ambiente completamente gestito che consente di eseguire microservizi e applicazioni in contenitori in una piattaforma serverless. Le app di Azure Container consentono di eseguire le funzioni con la potenza del servizio Azure Kubernetes sottostante (servizio Azure Kubernetes) rimuovendo la complessità di dover usare le API Kubernetes. |
| Kubernetes (Diretto o Azure Arc) |
Kubernetes offre un ambiente completamente isolato e dedicato in esecuzione nella piattaforma Kubernetes. Kubernetes è appropriato per i carichi di lavoro dell'applicazione che richiedono: ✔ Requisiti hardware personalizzati. ✔ Isolamento e accesso sicuro alla rete. ✔ Possibilità di essere eseguita in un ambiente ibrido o multi-cloud. ✔ Eseguire insieme ad applicazioni e servizi Kubernetes esistenti. |
Le tabelle rimanenti di questo articolo confrontano i piani relativi a diverse funzionalità e comportamenti. Per un confronto dei costi tra piani di hosting dinamici (Consumo e Premium), vedere la pagina dei prezzi Funzioni di Azure. Per i prezzi delle varie opzioni del piano dedicato, vedere la pagina dei prezzi servizio app.
Sistema operativo/runtime
La tabella seguente illustra il supporto linguistico e del sistema operativo per i piani di hosting.
| Linux1,2 solo codice |
Solo codice Windows | Linux1,2,3 Contenitore Docker |
|
|---|---|---|---|
| Piano a consumo | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
Nessun supporto |
| Piano Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Piano dedicato | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (diretto) | n/d | n/d | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (anteprima) | C# JavaScript Java Python TypeScript |
n/d | C# JavaScript Java PowerShell Core Python TypeScript |
1 Linux è l'unico sistema operativo supportato per lo stack di runtime Python.
2 Il supporto di PowerShell in Linux è attualmente in anteprima.
3 Linux è l'unico sistema operativo supportato per i contenitori Docker.
Durata del timeout di un'app per le funzioni
La durata del timeout per le funzioni in un'app per le functionTimeout funzioni è definita dalla proprietà 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à 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 Premium | 302 | Illimitati3 |
| Piano dedicato | 302 | Illimitati3 |
1 Indipendentemente dall'impostazione di timeout dell'app per le funzioni, 230 secondi è la quantità massima di tempo che una funzione attivata tramite HTTP può richiedere 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 Il timeout predefinito per la versione 1.x del runtime di Funzioni è illimitato.
3 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.
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 | Guidata dagli eventi. Aumento automatico del numero di istanze anche in periodo di carico elevato. Funzioni di Azure'infrastruttura ridimensiona le risorse di CPU e memoria aggiungendo istanze aggiuntive dell'host di Funzioni, in base al numero di eventi di trigger in ingresso. | Windows: 200 Linux: 1001 |
| Piano Premium | Guidata dagli eventi. Aumento automatico del numero di istanze anche in periodo di carico elevato. Funzioni di Azure'infrastruttura ridimensiona le risorse di CPU e memoria aggiungendo istanze aggiuntive dell'host di Funzioni, in base al numero di eventi su cui vengono attivate le funzioni. | Windows: 100 Linux: 20-1002 |
| Pianodedicato 3 | Manual/autoscale | 10-30 |
| A edizione Standard 3 | Manual/autoscale | 100 |
| Kubernetes | Scalabilità automatica basata su eventi per i cluster Kubernetes tramite KEDA. | Varia in base al cluster |
1 Durante la scalabilità orizzontale, è 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 essere ridimensionate a 100 istanze. Per altre informazioni, vedere l'articolo Piano Premium.
3 Per limiti specifici per le varie opzioni di piano servizio app, vedere i limiti del piano servizio app.
Comportamento di avvio a freddo
| Piano | Dettagli |
|---|---|
| Piano a consumo | Le app possono essere ridimensionate a zero quando sono inattive, ovvero alcune richieste potrebbero avere una latenza aggiuntiva all'avvio. Il piano a consumo include alcune ottimizzazioni per ridurre l'ora di avvio a freddo, tra cui il pull dalle funzioni segnaposto pre-riscaldamento che dispongono già dell'host funzione e dei processi del linguaggio in esecuzione. |
| Piano Premium | Istanze a caldo perpetuo per evitare l'avvio a freddo. |
| Piano dedicato | Quando si esegue in un piano dedicato, l'host funzioni può essere eseguito in modo continuo, il che significa che l'avvio a freddo non è davvero un problema. |
| ASE | Quando si esegue in un piano dedicato, l'host funzioni può essere eseguito in modo continuo, il che significa che l'avvio a freddo non è davvero un problema. |
| Kubernetes | A seconda della configurazione KEDA, le app possono essere configurate per evitare un avvio a freddo. Se configurato per la scalabilità su zero, viene riscontrato un avvio a freddo per i nuovi eventi. |
Limiti del servizio
| Resource | Piano a consumo | Piano Premium | Piano dedicato | ASE | Kubernetes |
|---|---|---|---|---|---|
| Durata del timeout predefinita (min) | 5 | 30 | 301 | 30 | 30 |
| Durata del timeout massima (min) | 10 | Senza limiti7 | Senza limiti2 | unbounded | unbounded |
| 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 | Dipende dal cluster |
| Lunghezza massima della stringa di query3 | 4096 | 4096 | 4096 | 4096 | Dipende dal cluster |
| Lunghezza massima dell'URL della richiesta3 | 8192 | 8192 | 8192 | 8192 | Dipende dal cluster |
| Unità di calcolo di Azure per istanza | 100 | 210-840 | 100-840 | 210-2508 | Prezzi del servizio Azure Kubernetes |
| Dimensioni massime della memoria (GB per istanza) | 1,5 | 3,5-14 | 1,75-14 | 3,5-14 | Qualsiasi nodo è supportato |
| Numero massimo di istanze (Windows/Linux) | 200/100 | 100/20 | varia in base alla SKU9 | 1009 | Dipende dal cluster |
| App per le funzioni per piano11 | 100 | 100 | Senza limiti4 | unbounded | unbounded |
| Piani del servizio app | 100 per area | 100 per gruppo di risorse | 100 per gruppo di risorse | - | - |
| Slot di distribuzione per app10 | 2 | 3 | 1-209 | 20 | n/d |
| Archiviazione5 | 5 GB | 250 GB | 50-1000 GB | 1 TB | n/d |
| Domini personalizzati per applicazione | 5006 | 500 | 500 | 500 | n/d |
| 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 | n/d |
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.
3 Questi limiti vengono 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. Il piano a consumo usa File di Azure per l'archiviazione temporanea.
6 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.
7 Garantito per un massimo di 60 minuti.
8 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.
9 Per informazioni dettagliate, vedere limiti servizio app.
10 Inclusione dello slot di produzione.
11 Attualmente è previsto un limite di 5000 app per le funzioni in una determinata sottoscrizione.
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 l'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
- <> SKU_name i ruoli di lavoro 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 abbia mai contenuto un'altra app per le funzioni o un'app Web. Ad esempio, le app a consumo di 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 problema 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 verificherà 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.
Funzionalità di rete
| Funzionalità | Piano a consumo | Piano Premium | Piano dedicato | ASE |
|---|---|---|---|---|
| Restrizioni IP in ingresso | ✅Sì | ✅Sì | ✅Sì | ✅Sì |
| Endpoint privati in ingresso | ❌No | ✅Sì | ✅Sì | ✅Sì |
| Integrazione della rete virtuale | ❌No | ✅Sì (Regionale) | ✅Sì (Regional e Gateway) | ✅Sì |
| Trigger della rete virtuale (non HTTP) | ❌No | ✅Sì | ✅Sì | ✅Sì |
| Connessioni ibride (solo Windows) | ❌No | ✅Sì | ✅Sì | ✅Sì |
| Restrizioni IP in uscita | ❌No | ✅Sì | ✅Sì | ✅Sì |
Fatturazione
| Piano | Dettagli |
|---|---|
| Piano a consumo | Pagare solo per il tempo di esecuzione delle funzioni. La fatturazione si basa sul numero di esecuzioni, il tempo di esecuzione e la memoria usata. |
| Piano Premium | Il piano Premium si basa sul numero di secondi di core e memoria usati tra le istanze necessarie e pre-riscaldamento. Almeno un'istanza per piano deve essere sempre mantenuta calda. Questo piano fornisce i prezzi più prevedibili. |
| Piano dedicato | Si paga lo stesso per le app per le funzioni in un piano di servizio app come per altre risorse servizio app, ad esempio le app Web. |
| ambiente del servizio app (A edizione Standard) | Esiste una tariffa mensile fissa per un A edizione Standard che paga per l'infrastruttura e non cambia con le dimensioni della A edizione Standard. È previsto anche un costo per servizio app piano vCPU. Tutte le app ospitate in un ambiente del servizio app fanno parte di uno SKU di prezzi isolato. |
| Kubernetes | Si pagano solo i costi del cluster Kubernetes; nessuna fatturazione aggiuntiva per Funzioni. L'app per le funzioni viene eseguita come carico di lavoro dell'applicazione sopra il cluster, proprio come un'app normale. |