Partilhar via

Hospedagem do plano Azure Functions Flex Consumption

  • Artigo

O Flex Consumption é um plano de hospedagem do Azure Functions baseado em Linux que se baseia no modelo de cobrança Consumo pago pelo que você usa sem servidor. Ele oferece mais flexibilidade e personalização, introduzindo redes privadas, seleção de tamanho de memória de instância e recursos de expansão rápida/grande ainda baseados em um modelo sem servidor.

Importante

O plano Flex Consumption está atualmente em pré-visualização. Para obter uma lista das limitações atuais ao usar este plano de hospedagem, consulte Considerações. Para obter informações atuais sobre faturamento durante a visualização, consulte Faturamento.

Você pode revisar amostras de ponta a ponta que apresentam o plano Flex Consumption no repositório de amostras do plano Flex Consumption.

Benefícios

O plano Flex Consumption baseia-se nos pontos fortes do plano Consumption, que incluem escalonamento dinâmico e faturamento baseado em execução. Com o Flex Consumption, você também obtém estes recursos extras:

Esta tabela ajuda você a comparar diretamente os recursos do Flex Consumption com o plano de hospedagem Consumption:

Caraterística Consumo Consumo flexível
Escala até zero ✅ Sim ✅ Sim
Comportamento da escala Impulsionado por eventos Impulsionado por eventos (rápido)
Redes virtuais ❌ Não suportado ✅ Suportado
Computação dedicada (atenuar arranques a frio) ❌ Nenhum ✅ Instâncias sempre prontas (opcional)
Faturação Apenas tempo de execução Tempo de execução + instâncias sempre prontas
Instâncias de expansão (máx.) 200 1000

Para obter uma comparação completa do plano Flex Consumption com o plano Consumo e todos os outros tipos de plano e hospedagem, consulte Escala de funções e opções de hospedagem.

Integração da rede virtual

O Flex Consumption expande os benefícios tradicionais do plano Consumption adicionando suporte para integração de rede virtual. Quando seus aplicativos são executados em um plano Flex Consumption, eles podem se conectar a outros serviços do Azure protegidos em uma rede virtual. Tudo isso enquanto ainda permite que você aproveite o faturamento e a escala sem servidor, juntamente com os benefícios de escala e taxa de transferência do plano Flex Consumption. Para obter mais informações, consulte Habilitar integração de rede virtual.

Memória de instância

Ao criar seu aplicativo de função em um plano Flex Consumption, você pode selecionar o tamanho da memória das instâncias nas quais seu aplicativo é executado. Consulte Faturamento para saber como os tamanhos de memória da instância afetam os custos do seu aplicativo funcional.

Atualmente, o Flex Consumption oferece opções de tamanho de memória de instância de 2.048 MB e 4.096 MB.

Ao decidir qual tamanho de memória de instância usar com seus aplicativos, aqui estão algumas coisas a considerar:

  • O tamanho da memória da instância de 2.048 MB é o padrão e deve ser usado para a maioria dos cenários. Use o tamanho de memória de instância de 4.096 MB para cenários em que seu aplicativo requer mais simultaneidade ou maior poder de processamento. Para obter mais informações, consulte Configurar a memória da instância.
  • Você pode alterar o tamanho da memória da instância a qualquer momento. Para obter mais informações, consulte Configurar a memória da instância.
  • Os recursos da instância são compartilhados entre o código da função e o host Functions.
  • Quanto maior o tamanho da memória da instância, mais cada instância pode lidar com execuções simultâneas ou cargas de trabalho de CPU ou memória mais intensivas. As decisões de escala específicas são específicas da carga de trabalho.
  • A simultaneidade padrão de gatilhos HTTP depende do tamanho da memória da instância. Para obter mais informações, consulte Simultaneidade de gatilho HTTP.
  • As CPUs disponíveis e a largura de banda da rede são fornecidas proporcionalmente a um tamanho de instância específico.

Dimensionamento por função

A simultaneidade é um fator-chave que determina como os aplicativos da função Flex Consumption são dimensionados. Para melhorar o desempenho de escala de aplicativos com vários tipos de gatilho, o plano Flex Consumption fornece uma maneira mais determinística de dimensionar seu aplicativo por função.

Esse comportamento de dimensionamento por função faz parte da plataforma de hospedagem, portanto, você não precisa configurar seu aplicativo ou alterar o código. Para obter mais informações, consulte Dimensionamento por função no artigo Dimensionamento controlado por eventos.

No dimensionamento por função, as decisões são tomadas para determinados gatilhos de função com base em agregações de grupo. Esta tabela mostra o conjunto definido de grupos de escala de funções:

Grupos de escala Gatilhos em grupo Valor das configurações
Gatilhos HTTP Acionador HTTP
Gatilho SignalR		 http
Gatilhos de armazenamento de Blob
(Baseado em grade de eventos)		 Gatilho de armazenamento de Blob blob
Funções Duráveis Gatilho de orquestração
Gatilho de atividade
Gatilho da entidade		 durable

Todas as outras funções no aplicativo são dimensionadas individualmente em seu próprio conjunto de instâncias, que são referenciadas usando a convenção function:<NAMED_FUNCTION>.

Instâncias sempre prontas

O Flex Consumption inclui um recurso sempre pronto que permite escolher instâncias que estão sempre em execução e atribuídas a cada um dos grupos ou funções de escala por função. Essa é uma ótima opção para cenários em que você precisa ter um número mínimo de instâncias sempre prontas para lidar com solicitações, por exemplo, para reduzir a latência de inicialização a frio do seu aplicativo. O padrão é 0 (zero).

Por exemplo, se você definir sempre pronto como 2 para seu grupo de funções HTTP, a plataforma manterá duas instâncias sempre em execução e atribuídas ao seu aplicativo para suas funções HTTP no aplicativo. Essas instâncias estão processando suas execuções de função, mas, dependendo das configurações de simultaneidade, a plataforma pode ser dimensionada além dessas duas instâncias com instâncias sob demanda.

Para saber como configurar instâncias sempre prontas, consulte Definir contagens de instâncias sempre prontas.

Simultaneidade

Simultaneidade refere-se ao número de execuções paralelas de uma função em uma instância do seu aplicativo. Você pode definir um número máximo de execuções simultâneas que cada instância deve manipular a qualquer momento. Para obter mais informações, consulte Simultaneidade de gatilho HTTP.

A simultaneidade tem um efeito direto sobre a forma como seu aplicativo é dimensionado porque, em níveis mais baixos de simultaneidade, você precisa de mais instâncias para lidar com a demanda orientada por eventos para uma função. Embora você possa controlar e ajustar a simultaneidade, fornecemos padrões que funcionam para a maioria dos casos. Para saber como definir limites de simultaneidade para funções de gatilho HTTP, consulte Definir limites de simultaneidade HTTP.

Implementação

As implantações no plano Flex Consumption seguem um único caminho. Depois que o código do projeto é criado e compactado em um pacote de aplicativo, ele é implantado em um contêiner de armazenamento de blob. Na inicialização, seu aplicativo obtém o pacote e executa seu código de função a partir desse pacote. Por padrão, a mesma conta de armazenamento usada para armazenar metadados de host interno (AzureWebJobsStorage) também é usada como contêiner de implantação. No entanto, você pode usar uma conta de armazenamento alternativa ou escolher seu método de autenticação preferido definindo as configurações de implantação do seu aplicativo. Ao simplificar o caminho de implantação, não há mais a necessidade de as configurações do aplicativo influenciarem o comportamento da implantação.

Faturação

Há dois modos pelos quais seus custos são determinados ao executar seus aplicativos no plano Flex Consumption. Cada modo é determinado por instância.

Modo de faturação Description
Sob Demanda Ao executar no modo sob demanda , você é cobrado apenas pela quantidade de tempo que o código da função está sendo executado em suas instâncias disponíveis. No modo sob demanda, nenhuma contagem mínima de instâncias é necessária. Você é cobrado por:

• A quantidade total de memória provisionada enquanto cada instância sob demanda está executando ativamente 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 gatilho específicos (HTTP/Durable/Blob) e funções individuais, que estão sempre disponíveis para lidar com solicitações. Quando você tiver instâncias sempre prontas habilitadas, será cobrado por:

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

Na faturação sempre pronta, não há subvenções gratuitas.

O período mínimo de execução faturável para ambos os modos de execução é de 1.000 ms. Passado isso, o período de atividade faturável é arredondado para os 100 ms mais próximos. Você pode encontrar detalhes sobre os medidores de faturamento do plano Flex Consumption na referência Monitoramento.

Para obter detalhes sobre como os custos são calculados quando você executa em um plano Flex Consumption, incluindo exemplos, consulte Custos baseados no consumo.

Para obter as informações mais atualizadas sobre preços de execução, custos de linha de base sempre prontos e concessões gratuitas para execuções sob demanda, consulte a página de preços do Azure Functions.

Versões de pilha de idiomas suportadas

Esta tabela mostra as versões da pilha de idiomas atualmente suportadas para aplicativos Flex Consumption:

Pilha de idiomas Versão necessária
C# (modo de processo isolado)1 .NET 82
Java Java 11, Java 17
Node.js Nó 20
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11

1 O modo em processo C# não é suportado. Em vez disso, você precisa migrar seu projeto de código .NET para ser executado no modelo de trabalho isolado.
2 Requer a versão 1.20.0 ou posterior do Microsoft.Azure.Functions.Worker e a versão 1.16.2 ou posterior do Microsoft.Azure.Functions.Worker.Sdk.

Cotas regionais de memória de assinatura

Atualmente, em visualização, cada região de uma determinada assinatura tem um limite de memória para 512,000 MB todas as instâncias de aplicativos executados em planos Flex Consumption. Isso significa que, em uma determinada assinatura e região, você pode ter qualquer combinação de tamanhos e contagens de memória de instância, desde que permaneçam abaixo do limite de cota. Por exemplo, cada um dos exemplos a seguir significaria que a cota foi atingida e os aplicativos parariam de dimensionar:

  • Você tem um aplicativo de 2.048 MB dimensionado para 100 e um segundo aplicativo de 2.048 MB dimensionado para 150 instâncias
  • Você tem um aplicativo de 2.048 MB que foi expandido para 250 instâncias
  • Você tem um aplicativo de 4.096 MB que foi expandido para 125 instâncias
  • Você tem um aplicativo de 4.096 MB dimensionado para 100 e um aplicativo de 2.048 MB dimensionado para 50 instâncias

Essa cota pode ser aumentada para permitir que seus aplicativos Flex Consumption sejam dimensionados ainda mais, dependendo de suas necessidades. Se seus aplicativos exigirem uma cota maior, crie um tíquete de suporte.

Propriedades e configurações preteridas

No Flex Consumption, muitas das configurações padrão do aplicativo e das propriedades de configuração do site usadas no Bicep, nos modelos ARM e no plano de controle geral foram preteridas ou foram movidas e não devem ser usadas ao automatizar a criação de recursos de aplicativo de função. Para obter mais informações, consulte Descontinuações do plano Flex Consumption.

Considerações

Tenha estas outras considerações em mente ao usar o plano Flex Consumption durante a visualização atual:

  • Host: há um tempo limite de 30 segundos para a inicialização do aplicativo. Se o seu aplicativo de função demorar mais de 30 segundos para iniciar, você verá entradas System.TimeoutException relacionadas ao gRPC. Esse tempo limite será configurável e uma exceção mais clara será implementada como parte deste item de trabalho do host.
  • Funções duráveis: Devido à natureza de dimensionamento por função do Flex Consumption, para garantir o melhor desempenho para funções duráveis, recomendamos definir a contagem de instâncias Always Ready para o durable grupo como 1. Além disso, com o provedor de Armazenamento do Azure, considere reduzir o intervalo de sondagem da fila para 10 segundos ou menos. Somente o Armazenamento do Azure é suportado como um provedor de armazenamento de back-end para funções duráveis hospedadas pelo Flex Consumption.
  • Integração de VNet Certifique-se de que o provedor de recursos do Azure está habilitado Microsoft.App para sua assinatura seguindo estas instruções. A delegação de sub-rede exigida pelos aplicativos Flex Consumption é Microsoft.App/environments.
  • Triggers: todos os triggers são totalmente suportados, exceto os gatilhos Kafka e Azure SQL. O gatilho de armazenamento de Blob suporta apenas a origem da Grade de Eventos. Os aplicativos de função não-C# devem usar a versão [4.0.0, 5.0.0) do pacote de extensão ou uma versão posterior.
  • Regiões: Nem todas as regiões são suportadas atualmente. Para saber mais, consulte Exibir regiões atualmente suportadas.
  • Implantações: Atualmente, não há suporte para slots de implantação.
  • Escala: A escala máxima mais baixa na pré-visualização é 40. O valor mais alto suportado atualmente é 1000.
  • Dependências gerenciadas: as dependências gerenciadas no PowerShell não são suportadas pelo Flex Consumption. Em vez disso, você deve definir seus próprios módulos personalizados.
  • Configurações de diagnóstico: as configurações de diagnóstico não são suportadas no momento.
  • Certificados: no momento, não há suporte para o carregamento de certificados com a configuração do aplicativo WEBSITE_LOAD_CERTIFICATES.
  • Referências do Cofre da Chave: as referências do Cofre da Chave nas configurações do aplicativo não funcionam quando o Cofre da Chave é restrito ao acesso à rede, mesmo que o aplicativo de função tenha integração com a Rede Virtual. A solução atual é fazer referência direta ao Cofre da Chave no código e ler os segredos necessários.
  • Montagem de compartilhamento de arquivos de Arquivos do Azure: montar um compartilhamento de arquivos de Arquivos do Azure não funciona quando o aplicativo de função tem integração de Rede Virtual.

Opçõesde hospedagem do Azure Functions Criar e gerenciar aplicativos de função no plano Flex Consumption