Compartilhar via

Estimativa de custos baseados no consumo

  • Artigo

Este artigo mostra como estimar os custos do plano para os planos de hospedagem Consumo Flexível e Consumo.

Atualmente, o Azure Functions oferece essas diferentes opções de hospedagem para seus aplicativos de funções, com cada opção tendo seu próprio modelo de preço de plano de hospedagem:

Planejar Descrição
Plano de Consumo Flexível Você paga pelo tempo de execução nas instâncias nas quais suas funções estão sendo executadas, além de quaisquer instâncias sempre prontas. As instâncias são adicionadas e removidas dinamicamente com base no número de eventos de entrada. Esse é o plano de escala dinâmica recomendado, que também dá suporte à integração de rede virtual.
Premium Fornece a você os mesmos recursos e mecanismo de escalonamento que o plano de Consumo, mas com desempenho aprimorado e integração com rede virtual. O custo é baseado no tipo de preço escolhido. Para saber mais, confira Plano Premium do Azure Functions.
Dedicado (Serviço de Aplicativo)
(camada básica ou superior)		 Quando você precisa executar em VMs dedicadas ou isoladamente, usar imagens personalizadas ou deseja usar o excesso de capacidade do Plano do Serviço de Aplicativo. Usa a cobrança regular do Plano do Serviço de Aplicativo. O custo é baseado no tipo de preço escolhido.
Aplicativos de Contêiner Crie e implante aplicativos de funções em contêineres em um ambiente totalmente gerenciado hospedado pelos Aplicativos de Contêiner do Azure, que permite executar suas funções junto com outros microsserviços, APIs, sites e fluxos de trabalho como programas hospedados em contêiner.
Consumo Você é cobrado apenas pelo tempo em que seu aplicativo de funções é executado. Esse plano inclui uma concessão gratuita com base em cada assinatura.

Importante

O plano de Consumo Flex está atualmente em versão preliminar.

Escolha sempre a opção que melhor apoia os requisitos de recursos, desempenho e custo para as execuções de suas funções. Para saber mais, confira Escala e hospedagem do Azure Functions.

Este artigo se concentra nos planos de Consumo Flexível e Consumo porque, nesses planos, a cobrança depende dos períodos ativos de execuções dentro de cada instância.

As Durable Functions também podem ser executadas em ambos os planos. Para saber mais sobre as considerações de custo ao usar o Durable Functions, confira Cobrança das Durable Functions.

Custos baseados no consumo

A forma como os custos baseados no consumo são calculados, incluindo concessões gratuitas, depende do plano específico. Para as informações de custo e concessão mais atualizadas, veja a página de preços do Azure Functions.

Existem dois modos pelos quais seus custos são determinados ao executar seus aplicativos no plano de Consumo Flexível. Cada modo é determinado por instância.

Modo de cobrança Descrição
Sob demanda Quando executado no modo sob demanda, você é cobrado apenas pelo tempo que o código da sua função está executando nas suas instâncias disponíveis. No modo sob demanda, não é necessário um número mínimo de instâncias. Você é cobrado por:

• A quantidade total de memória provisionada enquanto cada instância sob demanda está ativamente executando funções (em GB-segundos), menos uma concessão gratuita de GB-s por mês.
• O número total de execuções, menos uma concessão gratuita (número) de execuções por mês.
Sempre pronto Você pode configurar uma ou mais instâncias, atribuídas a tipos de gatilhos específicos (HTTP/Durable/Blob) e funções individuais, que estão sempre disponíveis para lidarem com solicitações. Quando você tem qualquer instância sempre pronta habilitada, você é cobrado por:

• A quantidade total de memória provisionada em todas as suas instâncias sempre prontas, conhecida como base (em GB-segundos).
• A quantidade total de memória provisionada durante o tempo que cada instância sempre pronta está ativamente executando funções (em GB-segundos).
• O número total de execuções.

Na cobrança sempre pronta, não há concessões gratuitas.

Este diagrama representa como os custos sob demanda são determinados neste plano:

Gráfico dos custos sob demanda do plano de Consumo Flexível baseado tanto na carga (contagem de instâncias) quanto no tempo.

Além do tempo de execução, ao usar uma ou mais instâncias sempre prontas, você também é cobrado a uma taxa base mais baixa pelo número de instâncias sempre prontas que você mantém. O tempo de execução para instâncias sempre prontas pode ser mais barato do que o tempo de execução em instâncias com execução sob demanda.

Importante

Neste artigo, os preços são fornecidos apenas para ajudar a entender cálculos de exemplo. Sempre verifique a página de preços do Azure Functions ao estimar os custos que você pode incorrer ao executar suas funções no plano de Consumo Flexível.

Para os exemplos desta seção, considere o preço de visualização com desconto nesta tabela para pagamento conforme o uso no Leste dos EUA.

Mode Medidor Concessões mensais gratuitas Taxas de consumo
Sob demanda Tempo de execução (GB-s) 100,000 $0.000016 por GB
Sob demanda Execuções (contagem) 250,000 $0.20 por milhões de execuções
Sempre pronto Tempo de base (ocioso) (GB-s) - $0.000004 por GB
Sempre pronto Tempo de execução (GB-s) - $0.000009 por GB
Sempre pronto Execuções (contagem) - $0.20 por milhões de execuções

Considere um aplicativo de função composto apenas de gatilhos HTTP com estes fatos básicos:

  • Os gatilhos HTTP lidam com 40 solicitações constantes por segundo.
  • Os gatilhos HTTP lidam com 10 solicitações simultâneas.
  • O tamanho da memória da instância é 2048 MB.
  • Não há instâncias sempre prontas configuradas, o que significa que o aplicativo pode escalar para zero.

Em uma situação como esta, o preço depende mais do tipo de trabalho sendo feito durante a execução do código. Vamos ver dois cenários de carga de trabalho:

  • Carga de trabalho limitada por CPU: Em uma carga de trabalho limitada por CPU, não há vantagem em processar várias solicitações em paralelo na mesma instância. Isso significa que é melhor distribuir cada solicitação para sua própria instância para que as solicitações sejam concluídas o mais rapidamente possível, sem contenção. Neste cenário, você deve definir uma baixa concorrência de gatilho HTTP de 1. Com 10 solicitações simultâneas, o aplicativo escala para um estado estável de aproximadamente 10 instâncias, e cada instância está continuamente ativa processando uma solicitação por vez.

    Como o tamanho de cada instância é de ~2 GB, o consumo para uma única instância continuamente ativa é 2 GB * 3600 s = 7200 GB-s, que na taxa de execução sob demanda assumida (sem nenhuma concessão gratuita aplicada) é $0.1152 USD por hora por instância. Como o aplicativo limitado por CPU está escalado para 10 instâncias, a taxa horária total para o tempo de execução é $1.152 USD.

    Da mesma forma, a cobrança por execução sob demanda (sem nenhuma concessão gratuita) de 40 solicitações por segundo é igual a 40 * 3600 = 144,000 ou 0,144 milhões de execuções por hora. O custo horário total (sem concessões) das execuções é então 0.144 * $0.20, que é $0.0288 por hora.

    Neste cenário, o custo horário total de execução sob demanda em 10 instâncias é $1.152 + $0.0288 = $1.1808 USD.

  • Carga de trabalho limitada por IO: Em uma carga de trabalho limitada por IO, a maior parte do tempo de aplicação é gasta esperando a solicitação de entrada, que pode ser limitada pela taxa de transferência da rede ou outros fatores upstream. Devido às entradas limitadas, o código pode processar várias operações simultaneamente sem impactos negativos. Neste cenário, suponha que você possa processar todas as 10 solicitações simultâneas na mesma instância.

    Como os encargos de consumo são baseados apenas na memória de cada instância ativa, o cálculo do encargo de consumo é simplesmente 2 GB * 3600 s = 7200 GB-s, que na taxa de execução sob demanda assumida (sem concessões gratuitas aplicadas) é $0.1152 USD por hora para a instância única.

    Como no cenário limitado por CPU, a cobrança por execução sob demanda (sem concessões gratuitas) de 40 solicitações por segundo é igual a 40 * 3600 = 144,000 ou 0,144 milhões de execuções por hora. Isso faz com que o custo horário total (sem concessões) das execuções seja 0.144 * $0.20, que é $0.0288 por hora.

    Neste cenário, o custo horário total de execução sob demanda em uma única instância é $0.1152 + $0.0288 = $0.144 USD.

Ao estimar o custo geral da execução de suas funções em algum plano, lembre-se de que o tempo de execução do Functions usa vários outros serviços do Azure, cada um cobrado separadamente. Ao estimar os preços para aplicativos de função, quaisquer gatilhos e associações que você tenha que se integrem com outros serviços do Azure exigem que você crie e pague por esses outros serviços.

Para funções executadas em um plano de Consumo, o custo total é o custo de execução de suas funções, além do custo da largura de banda e outros serviços.

Ao estimar os custos gerais do seu aplicativo de funções e dos serviços relacionados, use a calculadora de preços do Azure.

Custo relacionado Descrição
Conta de armazenamento Cada aplicativo de funções requer que você tenha uma conta de Armazenamento do Microsoft Azure de Uso Geral associada, que é cobrada separadamente. Essa conta é usada internamente pelo tempo de execução do Functions, mas você também pode usá-la para gatilhos e associações do Armazenamento. Se não tiver uma conta de armazenamento, uma será criada para você quando o aplicativo de funções for criado. Para saber mais, confira Requisitos de uma conta de armazenamento.
Application Insights As funções dependem do Application insights para fornecer uma experiência de monitoramento de alto desempenho em seus aplicativos de funções. Embora não seja necessário, você deve habilitar a integração do Application Insights. Uma concessão gratuita de dados de telemetria é incluída todos os meses. Para saber mais, confira a página de preços do Azure Monitor.
Largura de banda da rede Você pode incorrer em custos de transferência de dados dependendo da direção e do cenário da movimentação de dados. Para saber mais, confira Detalhes de preços de Largura de Banda.

Comportamentos que afetam o tempo de execução

Os seguintes comportamentos de suas funções podem afetar o tempo de execução:

  • Gatilhos e associações: o tempo que leva para ler entradas e gravar saídas de suas associações de funções é contado como tempo de execução. Por exemplo, quando sua função usa uma associação de saída para gravar uma mensagem em uma fila de armazenamento do Azure, o tempo de execução inclui o tempo necessário para gravar a mensagem na fila, que está incluído no cálculo do custo da função.

  • Execução assíncrona o tempo que sua função aguarda pelos resultados de uma solicitação assíncrona (await em C#) é contado como tempo de execução. O cálculo de GB por segundo é baseado na hora de início e de término da função e no uso de memória nesse período. O que acontece nesse tempo em termos de atividade de CPU não é acrescentado ao cálculo. Talvez seja possível reduzir os custos durante operações assíncronas usando as Durable Functions. Você não é cobrado pelo tempo gasto em espera em funções de orquestrador.

Na sua fatura, você pode exibir os dados relacionados ao custo de Execuções Totais - Functions e Tempo de Execução - Functions, juntamente com os custos de cobrança reais. No entanto, esses dados da fatura são uma agregação mensal de um período de fatura anterior.

Métricas no nível do aplicativo de função

Para entender melhor o impacto de custos de suas funções, você pode usar o Azure Monitor para exibir as métricas de custo que estão sendo geradas atualmente por seus aplicativos de funções.

Use o Azure Monitor Metrics Explorer para exibir dados relacionados ao custo de seus aplicativos de função do plano de Consumo em um formato gráfico.

  1. No portal do Azure, navegue até o aplicativo de funções.

  2. No painel esquerdo, role para baixo até Monitoramento e escolha Métricas.

  3. Em Métrica, escolha Contagem de Execuções de Função e Soma para Agregação. Isso adiciona a soma das contagens de execução durante o período escolhido ao gráfico.

    Definir uma métrica de aplicativo de funções para adicionar ao gráfico

  4. Selecione Adicionar métrica e repita as etapas 2 a 4 para adicionar Unidades de Execução de Função ao gráfico.

O gráfico resultante contém os totais para ambas as métricas de execução no intervalo de tempo escolhido, que nesse caso é de duas horas.

Grafo de contagens de execução de função e unidades de execução

Como o número de unidades de execução é muito maior do que a contagem de execuções, o gráfico mostra apenas as unidades de execução.

Esse gráfico mostra um total de 1,11 bilhão de Function Execution Units consumidas em um período de duas horas, medido em MB-milissegundos. Para converter em GB-segundos, divida por 1024000. Neste exemplo, o aplicativo de funções consumiu 1110000000 / 1024000 = 1083.98 GB-segundos. Você pode usar esse valor e multiplicar pelo preço atual do tempo de execução na página de preços do Functions, que mostra o custo dessas duas horas, supondo que você já tenha usado alguma concessão gratuita de tempo de execução.

Métricas no nível da função

As unidades de execução de função são uma combinação de tempo de execução e seu uso de memória, o que a torna uma métrica difícil para entender o uso de memória. No momento, os dados de memória não são uma métrica disponível no Azure Monitor. No entanto, caso queira otimizar o uso de memória de seu aplicativo, será possível usar os dados do contador de desempenho coletados pelo Application Insights.

Se você ainda não tiver feito isso, habilite o Application insights em seu aplicativo de funções. Com essa integração habilitada, você pode consultar esses dados de telemetria no portal.

Você pode usar o Azure Monitor Metrics Explorer no portal do Azure ou APIs REST para obter dados de Métrica do Monitor.

Determinar o uso de memória flash

Em Monitoramento, selecione Logs (análise) , em seguida, copie a seguinte consulta de telemetria e cole-a na janela de consulta e selecione Executar. Essa consulta retorna o uso de memória total em cada tempo de amostra.

performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value

Os resultados são similares ao exemplo a seguir:

carimbo de data/hora [UTC] name value
9/12/2019, 1:05:14.947 AM Bytes Particulares 209.932.288
9/12/2019, 1:06:14.994 AM Bytes Particulares 212.189.184
9/12/2019, 1:06:30.010 AM Bytes Particulares 231.714.816
9/12/2019, 1:07:15.040 AM Bytes Particulares 210.591.744
9/12/2019, 1:12:16.285 AM Bytes Particulares 216.285.184
9/12/2019, 1:12:31.376 AM Bytes Particulares 235.806.720

Determinar duração

Azure Monitor acompanha as métricas no nível de recurso, o que, para Functions, é o aplicativo de funções. A integração do Application Insights emite métricas de acordo com a função. Aqui está um exemplo de consulta de análise para obter a duração média de uma função:

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

Próximas etapas

Saiba mais sobre como monitorar os aplicativos de funções