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. Sono disponibili tre piani di hosting di base per Funzioni di Azure: piano a consumo, piano Premium e piano dedicato (servizio app). Tutti i piani di hosting sono disponibili generalmente su macchine virtuali sia Linux che Windows.

Il piano di hosting 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.

Questo articolo fornisce un confronto dettagliato tra i vari piani di hosting, insieme all'hosting basato su Kubernetes.

Nota

Se si sceglie di ospitare le funzioni in un cluster Kubernetes, è consigliabile usare un cluster Kubernetes abilitato per Azure Arc. L'hosting in un cluster Kubernetes abilitato per Azure Arc è attualmente in anteprima. Per altre informazioni, vedere servizio app, Funzioni e App per la logica in Azure Arc.

Panoramica dei piani

Di seguito è riportato un riepilogo dei vantaggi offerti dai tre piani di hosting principali per Funzioni:

Piano Vantaggi
Piano a consumo Ridimensionare automaticamente e pagare solo per le risorse di calcolo quando le funzioni sono in esecuzione.

Nel piano a consumo le istanze dell'host di Funzioni 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.

Si consideri il piano Funzioni di Azure Premium nelle situazioni seguenti:

✔ Le app per le funzioni vengono eseguite in modo continuo o quasi continuo.
✔ Si dispone di un numero elevato di esecuzioni di piccole dimensioni e di una fattura di esecuzione elevata, ma bassi GB secondi 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 dei piani di servizio app.

Ideale per scenari a esecuzione prolungata in cui non è possibile 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.

Gli ambiente del servizio app sono appropriati 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.
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 varie 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 di piano dedicato, vedere la pagina dei prezzi servizio app.

Sistema operativo/runtime

La tabella seguente illustra il supporto del sistema operativo e della lingua per i piani di hosting.

Linux1,2
solo codice
Solo codice Di 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 funzioni è definita dalla functionTimeout 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à dei Funzioni di Azure.

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

Piano Predefinito Massimo1
Piano a consumo 5 10
Piano Premium 302 Nessuna limitazione
Piano dedicato 302 Nessuna limitazione

1 Indipendentemente dall'impostazione del timeout dell'app per le funzioni, 230 secondi è il tempo massimo che una funzione attivata 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.

Scalabilità

La tabella seguente confronta 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 sia indicato diversamente.

Piano Aumentare il numero di istanze Numero massimo di istanze #
Piano a consumo Guidata dall'evento. Aumento automatico del numero di istanze anche in periodo di carico elevato. Funzioni di Azure infrastruttura ridimensiona le risorse CPU e memoria aggiungendo istanze aggiuntive dell'host Funzioni, in base al numero di eventi trigger in ingresso. Windows: 200
Linux: 1001
Piano Premium Guidata dall'evento. Aumento automatico del numero di istanze anche in periodo di carico elevato. Funzioni di Azure le risorse di CPU e memoria vengono ridimensionate aggiungendo istanze aggiuntive dell'host funzioni, in base al numero di eventi attivati dalle funzioni. Windows: 100
Linux: 20-1002
Piano dedicato3 Scalabilità manuale/automatica 10-30
Ambiente del servizioapp 3 Scalabilità manuale/automatica 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 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, vale a dire che alcune richieste potrebbero avere una latenza aggiuntiva all'avvio. Il piano a consumo include alcune ottimizzazioni per ridurre l'ora di inizio a freddo, incluso il pull da funzioni segnaposto pre-riscaldamento che hanno già l'host della funzione e i processi del linguaggio in esecuzione.
Piano Premium Istanze con riscaldamento perpetuo per evitare qualsiasi 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 è 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 è 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 rilevato un avvio a freddo per i nuovi eventi.

Limiti del servizio

Risorsa 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 piano 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 TB 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. e sono disponibili in tre dimensioni fisse: Una vCPU/3,5 GB di RAM, due vCPU/7 GB di RAM oppure quattro vCPU/14 GB di RAM.
9 Per informazioni dettagliate, vedere limiti di servizio app.
10 Incluso lo slot di produzione.

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 contiene un'altra app per le funzioni o un'altra app Web.
  • 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. Ciò 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 al mapping dei piani dell'app per le funzioni e delle app Web a pool di risorse diversi al momento della 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 momento in cui vengono eseguite le 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 a caldo. Questo piano offre i prezzi più prevedibili.
Piano dedicato Si paga lo stesso per le app per le funzioni in un piano servizio app come per altre risorse servizio app, ad esempio le app Web.
Ambiente del servizio app Esiste una tariffa mensile fissa per un ambiente del servizio app che paga l'infrastruttura e non cambia con le dimensioni dell'ambiente del servizio app. È 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 all'inizio del cluster, proprio come una normale app.

Passaggi successivi