Platíte za dobu provádění instancí, na kterých jsou vaše funkce spuštěné, a za všechny instance, které jsou vždy připravené . Instance se dynamicky přidávají a odebírají na základě počtu příchozích událostí. Podporuje také integraci virtuální sítě.
Poskytuje stejné funkce a mechanismus škálování jako plán Consumption, ale s lepším výkonem a integrací virtuální sítě. Náklady jsou založené na zvolené cenové úrovni. Další informace najdete v plánu Azure Functions Premium.
Pokud potřebujete běžet na vyhrazených virtuálních počítačích nebo v izolaci, použijte vlastní image nebo chcete využít nadbytečnou kapacitu plánu služby App Service. Používá běžnou fakturaci plánu služby App Service. Náklady jsou založené na zvolené cenové úrovni.
Důležité
Plán Flex Consumption je aktuálně ve verzi Preview.
Vždy byste měli zvolit plán, který nejlépe podporuje funkce, výkon a požadavky na náklady pro provádění funkcí. Další informace najdete v tématu Škálování a hostování azure Functions.
Tento článek se zaměřuje na plány Consumption a Flex Consumption, protože v těchto plánech fakturace závisí na aktivních obdobích provádění v jednotlivých instancích.
Durable Functions může také běžet v obou těchto plánech. Další informace o aspektech nákladů při používání Durable Functions najdete v tématu Fakturace Durable Functions.
Náklady na základě spotřeby
Způsob výpočtu nákladů založených na spotřebě, včetně bezplatných grantů, závisí na konkrétním plánu. Informace o nejaktuálnějších nákladech a udělení najdete na stránce s cenami služby Azure Functions.
Náklady na spuštění jedné funkce se měří v GB sekund. Náklady na spuštění se počítají zkombinováním využití paměti s časem spuštění. Funkce, která běží na delší náklady více, stejně jako funkce, která spotřebovává více paměti.
Představte si případ, kdy množství paměti používané funkcí zůstává konstantní. V tomto případě je výpočet nákladů jednoduchý násobení. Řekněme například, že vaše funkce spotřebovala 0,5 GB po dobu 3 sekund. Pak náklady na provádění jsou 0.5GB * 3s = 1.5 GB-seconds.
Vzhledem k tomu, že se využití paměti v průběhu času mění, je výpočet v podstatě nedílnou součástí využití paměti v průběhu času. Systém provádí tento výpočet vzorkováním využití paměti procesu (spolu s podřízenými procesy) v pravidelných intervalech. Jak je uvedeno na stránce s cenami, využití paměti se zaokrouhlí nahoru na nejbližší kbelík 128 MB. Pokud váš proces používá 160 MB, účtuje se vám 256 MB. Výpočet bere v úvahu souběžnost, což je několik souběžných spuštění funkcí ve stejném procesu.
Poznámka:
I když využití procesoru není přímo považováno za náklady na spuštění, může mít vliv na náklady, pokud ovlivňuje dobu provádění funkce.
Pokud u funkce aktivované protokolem HTTP dojde k chybě před tím, než se kód funkce začne spouštět, nebudou se vám účtovat poplatky za provedení. To znamená, že 401 odpovědí z platformy kvůli ověření klíče rozhraní API nebo funkci ověřování nebo autorizace služby App Service se nezapočítávají do vašich nákladů na spuštění. Podobně se odpovědi stavového kódu 5xx nezapočítávají, když nastanou na platformě před tím, než vaše funkce zpracuje požadavek. Odpověď 5xx vygenerovaná platformou po spuštění kódu funkce se stále počítá jako spuštění, a to i v případě, že chyba není vyvolána z kódu funkce.
Při spouštění aplikací v plánu Flex Consumption se určují dva režimy, podle kterých se náklady určují. Každý režim je určen pro jednotlivé instance.
Režim fakturace
Popis
Na požádání
Při spuštění v režimu na vyžádání se vám účtuje jenom doba, po kterou kód funkce běží na dostupných instancích. V režimu na vyžádání se nevyžaduje žádný minimální počet instancí. Účtuje se vám:
• Celková velikost paměti zřízená, zatímco každá instance na vyžádání aktivně spouští funkce (v GB sekundách), minus bezplatný grant GB za měsíc. • Celkový počet spuštění minus bezplatný grant (počet) spuštění za měsíc.
Vždy připraveno
Můžete nakonfigurovat jednu nebo více instancí přiřazených ke konkrétním typům triggerů (HTTP/Durable/Blob) a jednotlivým funkcím, které jsou vždy dostupné pro zpracování požadavků. Pokud máte povolené všechny vždy připravené instance, účtují se vám poplatky za:
• Celková velikost paměti zřízená ve všech instancích, které jsou vždy připravené, označované jako standardní hodnoty (v GB sekundách). • Celková velikost paměti zřízená během doby, kdy každá vždy připravená instance aktivně spouští funkce (v GB sekundách). • Celkový počet spuštění.
Ve vždy připravené fakturaci neexistují žádné bezplatné granty.
Tento diagram znázorňuje způsob určení nákladů na vyžádání v tomto plánu:
Kromě doby provádění se vám při použití jedné nebo více vždy připravených instancí účtuje také nižší směrná sazba za počet vždy připravených instancí, které udržujete. Doba provádění pro vždy připravené instance může být levnější než doba provádění u instancí s prováděním na vyžádání.
Důležité
V tomto článku jsou k dispozici pouze ceny, které vám pomůžou pochopit ukázkové výpočty. Při odhadu nákladů, které se vám můžou při spouštění funkcí v plánu Flex Consumtion zobrazovat, vždy zkontrolujte stránku s cenami služby Azure Functions.
V příkladech v této části zvažte slevové ceny ve verzi Preview v této tabulce pro průběžné platby v oblasti USA – východ.
Režim
Měřič
Bezplatné měsíční granty
Sazby spotřeby
Na vyžádání
Doba provádění (GB/s)
100,000
$0.000016 za GB-s
Na vyžádání
Provádění (počet)
250,000
$0.20 za milion spuštění
Vždy připraveno
Směrný plán (nečinný) čas (GB-s)
-
$0.000004 za GB-s
Vždy připraveno
Doba provádění (GB/s)
-
$0.000009 za GB-s
Vždy připraveno
Provádění (počet)
-
$0.20 za milion spuštění
Představte si aplikaci funkcí, která se skládá jenom z triggerů HTTP, s těmito základními fakty:
Triggery HTTP zpracovávají 40 konstantních požadavků za sekundu.
Nejsou nakonfigurované žádné vždy připravené instance, což znamená, že aplikace může škálovat na nulu.
V takové situaci závisí cena více na druhu práce prováděné během provádění kódu. Pojďme se podívat na dva scénáře úloh:
Úloha vázaná na procesor: V úloze vázané na procesor neexistuje žádná výhoda pro paralelní zpracování více požadavků ve stejné instanci. To znamená, že lépe distribuujete jednotlivé požadavky do své vlastní instance, aby se požadavky co nejrychleji dokončily bez kolize. V tomto scénáři byste měli nastavit nízkou souběžnost triggeru 1HTTP . Při 10 souběžných požadavcích se aplikace škáluje na stabilní stav zhruba 10 instancí a každá instance neustále zpracovává jeden požadavek najednou.
Vzhledem k tomu, že velikost každé instance je ~2 GB, spotřeba jedné nepřetržitě aktivní instance je 2 GB * 3600 s = 7200 GB-s, což je předpokládaná míra provádění na vyžádání (bez použití bezplatných grantů) $0.1152 USD za hodinu na instanci. Vzhledem k tomu, že se aplikace vázané na procesor škáluje na 10 instancí, celková hodinová rychlost pro dobu provádění je $1.152 USD.
Podobně se poplatek za provedení na vyžádání (bez bezplatných grantů) 40 žádostí za sekundu rovná 40 * 3600 = 144,000 0,144 milionům spuštění za hodinu. Celkové (grantové) hodinové náklady na provádění jsou pak 0.144 * $0.20, což je $0.0288 za hodinu.
V tomto scénáři jsou $1.152 + $0.0288 = $1.1808 USDcelkové hodinové náklady na provoz na vyžádání na 10 instancí .
Vstupně-výstupní úloha: Ve vstupně-výstupních úlohách se většina času aplikace stráví čekáním na příchozí požadavek, což může být omezené propustností sítě nebo jinými nadřazenými faktory. Z důvodu omezených vstupů může kód zpracovávat více operací současně bez negativních dopadů. V tomto scénáři předpokládejme, že můžete zpracovat všech 10 souběžných požadavků ve stejné instanci.
Vzhledem k tomu, že poplatky za spotřebu jsou založeny pouze na paměti každé aktivní instance, výpočet poplatku za spotřebu je jednoduše 2 GB * 3600 s = 7200 GB-s, což se předpokládá, že míra provádění na vyžádání (bez použití bezplatných grantů) je $0.1152 USD pro jednu instanci každou hodinu.
Stejně jako ve scénáři vázaném na procesor se 40 * 3600 = 144,000 poplatky za spuštění na vyžádání (bez bezplatných grantů) 40 požadavků za sekundu rovnají 0,144 milionům spuštění za hodinu. Díky tomu jsou celkové (bez grantu) hodinové náklady na provádění 0.144 * $0.20, což je $0.0288 každou hodinu.
V tomto scénáři jsou $0.1152 + $0.0288 = $0.144 USDcelkové hodinové náklady na provoz na vyžádání na jedné instanci .
Další související náklady
Při odhadu celkových nákladů na provoz funkcí v jakémkoli plánu mějte na paměti, že modul runtime Functions používá několik dalších služeb Azure, které se účtují samostatně. Když odhadnete ceny pro aplikace funkcí, všechny triggery a vazby, které máte integrované s jinými službami Azure, vyžadují, abyste tyto další služby vytvořili a zaplatili za ně.
U funkcí běžících v plánu Consumption jsou celkové náklady na provádění vašich funkcí plus náklady na šířku pásma a další služby.
Při odhadu celkových nákladů na vaši aplikaci funkcí a souvisejících služeb použijte cenovou kalkulačku Azure.
Související náklady
Popis
Účet úložiště
Každá aplikace funkcí vyžaduje, abyste měli přidružený účet Azure Storage pro obecné účely, který se účtuje samostatně. Tento účet používá modul runtime Služby Functions interně, ale můžete ho také použít pro triggery a vazby úložiště. Pokud účet úložiště nemáte, vytvoří se pro vás při vytvoření aplikace funkcí. Další informace najdete v tématu Požadavky na účet úložiště.
Application Insights
Funkce spoléhají na Application Insights , aby poskytovaly vysoce výkonné prostředí pro monitorování vašich aplikací funkcí. I když to není nutné, měli byste povolit integraci Application Insights. Každý měsíc se zahrne bezplatné udělení telemetrických dat. Další informace najdete na stránce s cenami služby Azure Monitor.
Šířka pásma sítě
Náklady na přenos dat můžete mít v závislosti na směru a scénáři přesunu dat. Další informace najdete v tématu Podrobnosti o cenách šířky pásma.
Chování ovlivňující dobu provádění
Doba provádění může ovlivnit následující chování vašich funkcí:
Triggery a vazby: Doba potřebná ke čtení vstupu a zápisu do vazeb funkcí se počítá jako doba provádění. Pokud například vaše funkce používá výstupní vazbu k zápisu zprávy do fronty úložiště Azure, doba provádění zahrnuje čas potřebný k zápisu zprávy do fronty, která je součástí výpočtu nákladů na funkci.
Asynchronní spuštění: Doba, po kterou vaše funkce čeká na výsledky asynchronního požadavku (await v jazyce C#), se počítá jako doba provádění. Výpočet GB-sekund je založen na počátečním a koncovém čase funkce a využití paměti v daném období. Co se v daném čase děje z hlediska aktivity procesoru, se do výpočtu nezapočítá. Můžete být schopni snížit náklady během asynchronních operací pomocí Durable Functions. Neúčtují se vám časy strávené na operátorech čekajících ve funkcích orchestrátoru.
Zobrazení dat souvisejících s náklady
Na faktuře můžete zobrazit data související s náklady celkových spuštění – Funkce a doba provádění – Functions spolu se skutečnými fakturovanými náklady. Tato data faktury jsou však měsíční agregací za období poslední faktury.
Metriky na úrovni aplikace funkcí
Pokud chcete lépe porozumět dopadu vašich funkcí na náklady, můžete pomocí služby Azure Monitor zobrazit metriky související s náklady, které aktuálně generují vaše aplikace funkcí.
Na levém panelu se posuňte dolů na Monitorování a zvolte Metriky.
V metrikě zvolte Počet spuštění funkce a součet pro agregaci. Tím se do grafu přičte součet počtů spuštění během vybraného období.
Vyberte Přidat metriku a opakujte kroky 2 až 4 a přidejte do grafu jednotky provádění funkcí.
Výsledný graf obsahuje součty pro obě metriky spuštění ve zvoleném časovém rozsahu, což je v tomto případě dvě hodiny.
Vzhledem k tomu, že počet jednotek provádění je mnohem větší než počet spuštění, graf zobrazuje pouze jednotky provádění.
Tento graf zobrazuje celkem 1,11 miliardy Function Execution Units spotřebovaných v dvouhodinovém období měřeném v MB-milisekundách. Pokud chcete převést na GB sekund, vydělte 1024000. V tomto příkladu aplikace funkcí spotřebovala 1110000000 / 1024000 = 1083.98 GB sekund. Tuto hodnotu můžete vzít a vynásobit aktuální cenou doby provádění na stránce s cenami služby Functions, která poskytuje náklady na tyto dvě hodiny za předpokladu, že jste už využili jakékoli bezplatné granty doby provádění.
Azure CLI obsahuje příkazy pro načítání metrik. Rozhraní příkazového řádku můžete použít z místního příkazového prostředí nebo přímo z portálu pomocí Azure Cloud Shellu. Například následující příkaz az monitor metrics list vrátí hodinová data za stejné časové období použité dříve.
Spuštěním příkazu nezapomeňte nahradit <AZURE_SUBSCRIPTON_ID> ID předplatného Azure.
az monitor metrics list --resource /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption --metric FunctionExecutionUnits,FunctionExecutionCount --aggregation Total --interval PT1H --start-time 2019-09-11T21:46:00Z --end-time 2019-09-11T23:18:00Z
Tento příkaz vrátí datovou část JSON, která vypadá jako v následujícím příkladu:
Tato konkrétní odpověď ukazuje, že aplikace 2019-09-11T21:462019-09-11T23:18spotřebovala 1110000000 MB-milisekund (1083,98 GB-s).
Azure PowerShell obsahuje příkazy pro načítání metrik. Azure PowerShell můžete použít z místního příkazového prostředí nebo přímo z portálu pomocí Azure Cloud Shellu. Například následující příkaz Get-AzMetric vrátí hodinové data za stejné časové období použité dříve.
Spuštěním příkazu nezapomeňte nahradit <AZURE_SUBSCRIPTON_ID> ID předplatného Azure.
Tento příkaz vrátí výstup, který vypadá jako v následujícím příkladu:
Id : /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption/providers/Microsoft.Insights/metrics/FunctionExecutionUnits
Name :
LocalizedValue : Function Execution Units
Value : FunctionExecutionUnits
Type : Microsoft.Insights/metrics
Unit : Count
Data : {Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue,
Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue,
Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue,
Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue…}
Timeseries : {Microsoft.Azure.Management.Monitor.Models.TimeSeriesElement}
Id : /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption/providers/Microsoft.Insights/metrics/FunctionExecutionCount
Name :
LocalizedValue : Function Execution Count
Value : FunctionExecutionCount
Type : Microsoft.Insights/metrics
Unit : Count
Data : {Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue,
Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue,
Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue,
Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue…}
Timeseries : {Microsoft.Azure.Management.Monitor.Models.TimeSeriesElement}
Vlastnost Data obsahuje skutečné hodnoty metriky.
Metriky na úrovni funkce
Jednotky spouštění funkcí jsou kombinací doby provádění a využití paměti, což ztěžuje pochopení využití paměti. Data paměti nejsou aktuálně k dispozici prostřednictvím služby Azure Monitor. Pokud ale chcete optimalizovat využití paměti aplikace, můžete použít data čítače výkonu shromážděná službou Application Insights.
K získání dat metrik monitorování můžete použít Průzkumník metrik Azure Monitoru na webu Azure Portal nebo rozhraní REST API.
Určení využití paměti
V části Monitorování vyberte Protokoly (Analytics) a zkopírujte následující telemetrický dotaz a vložte ho do okna dotazu a vyberte Spustit. Tento dotaz vrátí celkové využití paměti v každém vzorkovaném čase.
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
Výsledky vypadají jako v následujícím příkladu:
časové razítko [UTC]
name
hodnota
9.12.2019, 1:05:14.947
Privátní bajty
209,932,288
12.9.2019, 1:06:14.994
Privátní bajty
212,189,184
12.9.2019, 1:06:30.010
Privátní bajty
231,714,816
12.9.2019, 1:07:15.040
Privátní bajty
210,591,744
12.9.2019, 1:12:16.285
Privátní bajty
216,285,184
12.9.2019, 1:12:31.376
Privátní bajty
235,806,720
Určení doby trvání
Azure Monitor sleduje metriky na úrovni prostředků, což je aplikace funkcí pro Functions. Integrace Application Insights generuje metriky na základě jednotlivých funkcí. Tady je příklad analytického dotazu pro získání průměrné doby trvání funkce:
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
