Stima dei costi basati sul consumo
Questo articolo illustra come stimare i costi del piano per i piani di hosting Flex Consumption and Consumption.
Funzioni di Azure attualmente offre queste diverse opzioni di hosting per le app per le funzioni, con ogni opzione con un proprio modello tariffario del piano di hosting:
| Piano | Descrizione |
|---|---|
| Piano a consumo flex | Si paga il tempo di esecuzione per le istanze in cui vengono eseguite le funzioni, oltre a tutte le istanze sempre pronte. Le istanze vengono aggiunte e rimosse dinamicamente in base al numero di eventi in ingresso. Si tratta del piano di scalabilità dinamico consigliato, che supporta anche l'integrazione della rete virtuale. |
| Premium | Offre le stesse funzionalità e gli stessi meccanismi di ridimensionamento del piano a consumo, ma con prestazioni migliorate e integrazione della rete virtuale. Il costo è basato sul piano tariffario scelto. Per altre informazioni, vedere Piano Premium di Funzioni di Azure. |
| Dedicato (servizio app) (livello basic o superiore) |
Quando è necessario eseguire in macchine virtuali dedicate o in isolamento, usare immagini personalizzate o usare la capacità del piano di servizio app in eccesso. Usa la fatturazione normale del piano di servizio app. Il costo è basato sul piano tariffario scelto. |
| App contenitore | Creare e distribuire app per le funzioni in contenitori in un ambiente completamente gestito ospitato da App Azure Container, che consente di eseguire le funzioni insieme ad altri microservizi, API, siti Web e flussi di lavoro come programmi ospitati in contenitori. |
| Consumo | Viene addebitato solo il tempo di esecuzione dell'app per le funzioni. Questo piano include una concessione gratuita per ogni sottoscrizione. |
È consigliabile scegliere sempre l'opzione che supporti al meglio le funzionalità, le prestazioni e i requisiti di costo per le esecuzioni delle funzioni. Per altre informazioni, vedere Ridimensionamento e hosting di Funzioni di Azure.
Questo articolo è incentrato sui piani Flex Consumption e Consumption perché in questi piani la fatturazione dipende dai periodi attivi di esecuzioni all'interno di ogni istanza.
Durable Functions può essere eseguito anche in entrambi questi piani. Per altre informazioni sulle considerazioni sui costi quando si usa Durable Functions, vedere Fatturazione di Durable Functions.
Costi basati sul consumo
Il modo in cui vengono calcolati i costi basati sul consumo, incluse le concessioni gratuite, dipende dal piano specifico. Per informazioni sui costi e sulle concessioni più aggiornati, vedere la pagina dei prezzi di Funzioni di Azure.
La determinazione dei costi di esecuzione delle app con il piano a consumo Flex avviene in base a due modalità. Ciascuna modalità è determinata per istanza.
| Modalità di fatturazione | Descrizione |
|---|---|
| On demand | Nell'esecuzione in modalità on demand, il codice della funzione viene fatturato solo per il periodo di tempo in cui il codice della funzione viene eseguito nelle istanze disponibili. La modalità on demand non richiede un numero minimo di istanze. La fatturazione concerne: • La quantità totale di memoria di cui è stato effettuato il provisioning mentre ogni istanza on demand esegue attivamente funzioni (in GB al secondo), meno una concessione gratuita di GB-s al mese. • Il numero totale di esecuzioni, meno una concessione gratuita (un numero) di esecuzioni al mese. |
| Sempre pronte | È possibile configurare una o più istanze, assegnate a tipi di trigger specifici (HTTP/Durable/Blob) e singole funzioni, sempre disponibili per gestire le richieste. Con l'abilitazione delle istanze sempre pronte, la fatturazione concerne: • Quantità totale di memoria di cui è stato effettuato il provisioning in tutte le istanze sempre pronte, note come baseline (in GB al secondo). • La quantità totale di memoria di cui è stato effettuato il provisioning durante il tempo in cui ogni istanza sempre pronta sta eseguendo attivamente le funzioni (in GB al secondo). • Il numero totale di esecuzioni. La fatturazione sempre pronte non prevede concessioni gratuite. |
Per le informazioni più aggiornate sui prezzi di esecuzione, sui costi baseline di sempre pronte e sulle concessioni gratuite per le esecuzioni on demand, vedere Pagina prezzi di Funzioni di Azure.
Questo diagramma rappresenta il modo in cui i costi su richiesta vengono determinati in questo piano:
Oltre al tempo di esecuzione, quando si usano una o più istanze sempre pronte, viene addebitata anche una tariffa di base inferiore per il numero di istanze sempre pronte gestite. Il tempo di esecuzione per le istanze sempre pronte potrebbe essere più economico rispetto al tempo di esecuzione delle istanze con esecuzione su richiesta.
Importante
In questo articolo vengono usati prezzi su richiesta per comprendere i calcoli di esempio. Controllare sempre i costi correnti nella pagina dei prezzi Funzioni di Azure quando si stimano i costi che è possibile sostenere durante l'esecuzione delle funzioni nel piano a consumo Flex.
Si consideri un'app per le funzioni costituita solo da trigger HTTP con e questi fatti di base:
- I trigger HTTP gestiscono 40 richieste costanti al secondo.
- I trigger HTTP gestiscono 10 richieste simultanee.
- L'impostazione delle dimensioni della memoria dell'istanza è
2048 MB. - Non sono state configurate istanze sempre pronte, il che significa che l'app può essere ridimensionata fino a zero.
In una situazione come questa, il prezzo dipende più dal tipo di lavoro svolto durante l'esecuzione del codice. Verranno ora esaminati due scenari di carico di lavoro:
Carico di lavoro associato alla CPU: in un carico di lavoro associato alla CPU non esiste alcun vantaggio per l'elaborazione di più richieste in parallelo nella stessa istanza. Ciò significa che è preferibile distribuire ogni richiesta alla propria istanza in modo che le richieste siano completate il più rapidamente possibile senza conflitti. In questo scenario è consigliabile impostare una concorrenza di trigger HTTP bassa di
1. Con 10 richieste simultanee, l'app viene ridimensionata a uno stato stabile di circa 10 istanze e ogni istanza elabora continuamente una richiesta alla volta.Poiché le dimensioni di ogni istanza sono di circa 2 GB, il consumo per una singola istanza attiva continua è
2 GB * 3600 s = 7200 GB-s, che alla velocità di esecuzione su richiesta presunta (senza concessioni gratuite applicate) è$0.1152 USDper ogni ora per ogni istanza. Poiché l'app associata alla CPU viene ridimensionata a 10 istanze, la frequenza oraria totale per il tempo di esecuzione è$1.152 USD.Analogamente, l'addebito su richiesta per esecuzione (senza concessioni gratuite) di 40 richieste al secondo è uguale a
40 * 3600 = 144,000o 0,144 milioni di esecuzioni all'ora. Il costo orario totale (gratuito di concessione) delle esecuzioni è quindi0.144 * $0.20, ovvero$0.0288all'ora.In questo scenario, il costo orario totale di esecuzione su richiesta su 10 istanze è
$1.152 + $0.0288 = $1.1808 USD.Carico di lavoro associato a I/O: in un carico di lavoro associato a I/O, la maggior parte del tempo dell'applicazione viene impiegato in attesa della richiesta in ingresso, che potrebbe essere limitato dalla velocità effettiva di rete o da altri fattori upstream. A causa degli input limitati, il codice può elaborare più operazioni contemporaneamente senza alcun impatto negativo. In questo scenario si supponga di poter elaborare tutte le 10 richieste simultanee nella stessa istanza.
Poiché gli addebiti per il consumo si basano solo sulla memoria di ogni istanza attiva, il calcolo dell'addebito a consumo è semplicemente
2 GB * 3600 s = 7200 GB-s, che a seconda della velocità di esecuzione su richiesta presunta (senza concessioni gratuite applicate) è$0.1152 USDall'ora per la singola istanza.Come nello scenario associato alla CPU, l'addebito su richiesta per esecuzione (senza concessioni gratuite) di 40 richieste al secondo è uguale a
40 * 3600 = 144,000o 0,144 milioni di esecuzioni all'ora. In questo caso, il costo totale (senza concessione) oraria delle esecuzioni0.144 * $0.20, che è$0.0288all'ora.In questo scenario, il costo totale orario di esecuzione su richiesta su una singola istanza è
$0.1152 + $0.0288 = $0.144 USD.
Altri costi correlati
Quando si stima il costo complessivo dell'esecuzione delle funzioni in qualsiasi piano, tenere presente che il runtime di Funzioni usa diversi altri servizi di Azure, ognuno dei quali viene fatturato separatamente. Quando si stimano i prezzi per le app per le funzioni, tutti i trigger e le associazioni disponibili che si integrano con altri servizi di Azure richiedono la creazione e il pagamento per tali altri servizi.
Per le funzioni in esecuzione in un piano a consumo, il costo totale è il costo di esecuzione delle funzioni, oltre al costo della larghezza di banda e ad altri servizi.
Quando si stimano i costi complessivi dell'app per le funzioni e dei servizi correlati, usare il calcolatore prezzi di Azure.
| Costo correlato | Descrizione |
|---|---|
| Account di archiviazione | Per ogni app per le funzioni è necessario disporre di un account di archiviazione di Azure per utilizzo generico associato, che viene fatturato separatamente. Questo account viene usato internamente dal runtime di Funzioni, ma è anche possibile usarlo per i trigger e le associazioni di archiviazione. Se non si ha un account di archiviazione, ne viene creato uno quando viene creata l'app per le funzioni. Per altre informazioni, vedere Requisiti dell'account di archiviazione. |
| Application Insights | Funzioni si basa su Application Insights per offrire un'esperienza di monitoraggio ad alte prestazioni per le app per le funzioni. Anche se non è obbligatorio, è necessario abilitare l'integrazione di Application Insights. Ogni mese è inclusa una concessione gratuita di dati di telemetria. Per altre informazioni, vedere la pagina dei prezzi di Monitoraggio di Azure. |
| Larghezza di banda della rete | È possibile sostenere costi per il trasferimento dei dati a seconda della direzione e dello scenario dello spostamento dei dati. Per altre informazioni, vedere Dettagli sui prezzi della larghezza di banda. |
Comportamenti che influiscono sul tempo di esecuzione
I comportamenti seguenti delle funzioni possono influire sul tempo di esecuzione:
Trigger e associazioni: il tempo impiegato per leggere l'input e scrivere l'output nelle associazioni di funzione viene conteggiato come tempo di esecuzione. Ad esempio, quando la funzione usa un'associazione di output per scrivere un messaggio in una coda di archiviazione di Azure, il tempo di esecuzione include il tempo impiegato per scrivere il messaggio nella coda, incluso nel calcolo del costo della funzione.
Esecuzione asincrona: il tempo di attesa della funzione per i risultati di una richiesta asincrona (
awaitin C#) viene conteggiato come tempo di esecuzione. Il calcolo del secondo GB si basa sull'ora di inizio e di fine della funzione e sull'utilizzo della memoria in tale periodo. Ciò che accade nel tempo in termini di attività della CPU non viene inserito nel calcolo. È possibile ridurre i costi durante le operazioni asincrone usando Durable Functions. Non viene addebitato alcun tempo dedicato alle attese nelle funzioni dell'agente di orchestrazione.
Visualizzazione dei dati correlati ai costi
Nella fattura è possibile visualizzare i dati relativi ai costi delle Esecuzioni totali - Funzioni e Tempo di esecuzione - Funzioni, insieme ai costi effettivi fatturati. Tuttavia, questi dati della fattura sono un'aggregazione mensile per un periodo di fatturazione precedente.
Metriche a livello di app per le funzioni
Per comprendere meglio i costi delle funzioni, è possibile usare Monitoraggio di Azure per visualizzare le metriche relative ai costi attualmente generate dalle app per le funzioni.
Usare Esplora metriche di Monitoraggio di Azure per visualizzare i dati correlati ai costi per le app per le funzioni del piano a consumo in un formato grafico.
Nel portale di Azure passare all'app per le funzioni.
Nel pannello sinistro scorrere verso il basso fino a Monitoraggio e scegliere Metriche.
In Metrica scegliere Conteggio delle esecuzioni della funzione e Somma per aggregazione. In questo modo viene aggiunta la somma dei conteggi di esecuzione durante il periodo scelto al grafico.
Selezionare Aggiungi metrica e ripetere i passaggi da 2 a 4 per aggiungere unità di esecuzione delle funzioni al grafico.
Il grafico risultante contiene i totali per entrambe le metriche di esecuzione nell'intervallo di tempo scelto, che in questo caso è di due ore.
Poiché il numero di unità di esecuzione è molto maggiore del numero di esecuzioni, il grafico mostra solo le unità di esecuzione.
Questo grafico mostra un totale di 1,11 miliardi Function Execution Units utilizzato in un periodo di due ore, misurato in MB-millisecondi. Per eseguire la conversione in GB-secondi, dividere per 1024000. In questo esempio l'app per le funzioni ha utilizzato 1110000000 / 1024000 = 1083.98 GB-secondi. È possibile accettare questo valore e moltiplicarsi per il prezzo corrente del tempo di esecuzione nella pagina dei prezzi di Funzioni, che offre il costo di queste due ore, presupponendo che siano già state usate concessioni gratuite di tempo di esecuzione.
Metriche a livello di funzione
Le unità di esecuzione delle funzioni sono una combinazione di tempo di esecuzione e l'utilizzo della memoria, che rende difficile la metrica per comprendere l'utilizzo della memoria. I dati di memoria non sono attualmente disponibili tramite Monitoraggio di Azure. Tuttavia, se si vuole ottimizzare l'utilizzo della memoria dell'app, è possibile usare i dati del contatore delle prestazioni raccolti da Application Insights.
Se non è già stato fatto, abilitare Application Insights nell'app per le funzioni. Con questa integrazione abilitata, è possibile eseguire query su questi dati di telemetria nel portale.
Si possono usare Esplora metriche di Monitoraggio di Azure nel portale di Azure o nelle API REST per ottenere i dati delle metriche di monitoraggio.
Determinare l'utilizzo della memoria
In Monitoraggio, selezionare log (analisi), quindi copiare la query di telemetria seguente e incollarla nella finestra di query e selezionare Esegui. Questa query restituisce l'utilizzo totale della memoria in ogni momento campionato.
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
I risultati sono simili all'esempio seguente:
| timestamp [UTC] | name | value |
|---|---|---|
| 12/09/2019, 1:05:14.947 | Byte privati | 209,932,288 |
| 12/09/2019, 1:06:14.994 | Byte privati | 212,189,184 |
| 12/09/2019, 1:06:30.010 | Byte privati | 231,714,816 |
| 12/09/2019, 1:07:15.040 | Byte privati | 210,591,744 |
| 12/09/2019, 1:12:16.285 | Byte privati | 216,285,184 |
| 12/09/2019, 1:12:31.376 | Byte privati | 235,806,720 |
Determinare la durata
Monitoraggio di Azure tiene traccia delle metriche a livello di risorsa, che per Funzioni è l'app per le funzioni. L'integrazione di Application Insights genera metriche per ogni funzione. Ecco una query di analisi di esempio per ottenere la durata media di una funzione:
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| name | averageDurationMilliseconds |
|---|---|
| QueueTrigger AvgDurationMs | 16.087 |
| QueueTrigger MaxDurationMs | 90.249 |
| QueueTrigger MinDurationMs | 8.522 |