Compartilhar via

Escala controlada por eventos no Azure Functions

Nos planos Consumo, Consumo Flexível e Premium, o Azure Functions escala os recursos adicionando mais instâncias com base no número de eventos que disparam uma função.

A maneira como seu aplicativo de funções é escalado depende do plano de hospedagem:

  • Plano Consumo: Cada instância do host Functions no plano de consumo é limitada, normalmente a 1,5 GB de memória e uma CPU. Uma instância do host dá suporte a todo o aplicativo de funções. Dessa forma, todas as funções em um aplicativo de funções que compartilham recursos em uma instância são dimensionadas ao mesmo tempo. Quando os aplicativos de funções compartilham o mesmo plano Consumo, eles ainda são escalados de forma independente.

  • Plano de consumo flex: O plano usa uma estratégia determinística de dimensionamento por função. Cada função é dimensionada de forma independente, exceto para funções disparadas por HTTP, Blob e Durable Functions que são dimensionadas em seus próprios grupos. Para obter mais informações, confira Escala por função. Essas instâncias são então escaladas com base na simultaneidade de suas solicitações.

  • Plano Premium: O tamanho específico do plano Premium determina a memória e a CPU disponíveis para todos os aplicativos desse plano nessa instância. O plano escala horizontalmente suas instâncias com base nas necessidades de escala dos aplicativos no plano e os aplicativos são escalados dentro do plano conforme necessário.

Os arquivos do código de função são armazenados em compartilhamentos dos Arquivos do Azure na conta de armazenamento principal da função. Ao excluir a conta de armazenamento principal do aplicativo de funções, os arquivos de código de função serão excluídos e não poderão ser recuperados.

Escalonamento de runtime

O Azure Functions usa um componente chamado controlador de escala para monitorar a taxa de eventos e determinar se deve aumentar ou reduzir. O controlador de escala usa heurística para cada tipo de gatilho. Por exemplo, quando você está usando um Gatilho do Armazenamento de Filas do Azure, ele usa dimensionamento baseado em destino.

A unidade de escala para o Azure Functions é o aplicativo de funções. Quando o aplicativo de funções é dimensionado na horizontal, mais recursos são alocados para executar várias instâncias do host do Azure Functions. Em contrapartida, quando a demanda por computação é reduzida, o controlador de escala remove as instâncias do host de função. O número de instâncias é eventualmente "reduzido horizontalmente" quando nenhuma função está em execução em um aplicativo de funções.

Diagrama mostrando o controlador de escala monitorando eventos e criando instâncias.

Inicialização a frio

Se o seu aplicativo de funções ficar ocioso por alguns minutos, a plataforma poderá decidir escalar a zero o número de instâncias nas quais o aplicativo é executado. A próxima solicitação tem a latência adicionada de escala de zero para um. Essa latência é conhecida como um início a frio. O número de dependências exigidas pelo aplicativo de funções poderá afetar o tempo de inicialização a frio. A inicialização a frio é mais um problema para operações síncronas, como gatilhos HTTP que devem retornar uma resposta. Se as inicializações a frio estiverem afetando suas funções, considere usar um plano diferente do Consumo. Os outros planos oferecem essas estratégias para atenuar ou eliminar inicializações a frio:

  • Plano Premium: Suporta instâncias pré-aquecidas e instâncias sempre prontas, com um mínimo de uma instância.

  • Plano Consumo Flexível: Suporta um número opcional de instâncias sempre prontas, que pode ser definido com base no escalonamento de cada instância.

  • Plano dedicado: o plano em si não é dimensionado dinamicamente, mas você pode executar seu aplicativo continuamente quando a configuração Always On está habilitada.

Noções básicas dos comportamentos de dimensionamento

A escala pode variar com base em vários fatores e os aplicativos são escalados de maneira diferente com base nos gatilhos e no idioma selecionados. Há algumas complexidades de comportamentos de escala que você deve estar ciente:

  • Máximo de instâncias: Um aplicativo de função única só pode ser dimensionado até um máximo permitido pelo plano. No entanto, uma única instância pode processar mais de uma mensagem ou solicitação por vez. Você pode especificar um máximo inferior para restringir a escala conforme necessário.
  • Nova taxa de instância: Para gatilhos HTTP, novas instâncias são alocadas, no máximo, uma vez por segundo. Para gatilhos não HTTP, novas instâncias são alocadas, no máximo, uma vez a cada 30 segundos. A escala é mais rápida quando executada em um plano Premium.
  • Dimensionamento baseado em destino: O dimensionamento baseado em destino fornece um modelo de dimensionamento rápido e intuitivo para os clientes. Atualmente, esse método de dimensionamento tem suporte para filas e tópicos do Service Bus, filas de armazenamento, Event Hubs, Apache Kafka e extensões do Azure Cosmos DB. Examine a escala baseada em destino para entender o comportamento de escala.
  • Dimensionamento por função: Com algumas exceções notáveis, as funções executadas no plano de Consumo Flexível são dimensionadas em instâncias independentes. As exceções incluem gatilhos HTTP e gatilhos do Armazenamento de Blobs (Grade de Eventos). Cada um desses tipos de gatilho é escalado como um grupo nas mesmas instâncias. Da mesma forma, os gatilhos de todas as Funções Duráveis também compartilham instâncias e são dimensionados em conjunto. Para obter mais informações, confira a escala por função.
  • Número máximo de gatilhos monitorados: Atualmente, o controlador de escala só consegue monitorar até 100 gatilhos para tomar decisões de dimensionamento. Quando seu aplicativo possui mais de 100 gatilhos baseados em eventos, as decisões de dimensionamento são tomadas com base apenas nos primeiros 100 gatilhos que são executados. Para obter mais informações, consulte Práticas recomendadas e padrões para aplicativos escalonáveis.

Limitar expansão

Você pode decidir restringir o número máximo de instâncias que um aplicativo pode usar para expansão. Essa limitação é mais comum para casos em que um componente downstream como um banco de dados tem taxa de transferência limitada. Para obter os limites máximos de escala ao executar os vários planos de hospedagem, confira Limites de escala.

Plano de Consumo Flexível

Por padrão, os aplicativos em execução em um plano Consumo Flex têm um limite de 100 instâncias gerais. Atualmente, o menor valor máximo de contagem de instâncias é 40 e o valor máximo de contagem de instâncias com suporte mais alto é 1000. Ao usar o comando az functionapp create para criar um aplicativo de funções no Plano de Consumo Flex, use o parâmetro --maximum-instance-count para definir essa contagem máxima de instâncias do seu aplicativo.

Embora seja possível alterar o número máximo de instâncias de aplicativos de Consumo Flexível para até 1.000, o limite de cota para seus aplicativos será atingido antes de alcançar esse número. Consulte Cotas de memória de assinatura por região para obter mais detalhes.

Este exemplo cria um aplicativo com uma contagem máxima de instâncias de 200:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

Este exemplo usa o comando az functionapp scale config set para alterar a contagem máxima de instâncias de um aplicativo existente para 150:

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

Planos Consumo e Premium

Em um plano Consumo ou Elastic Premium, você pode especificar um limite máximo menor para seu aplicativo modificando o valor da configuração do site functionAppScaleLimit. O functionAppScaleLimit pode ser definido como 0 ou null para irrestrito ou um valor válido entre 1 e o máximo do aplicativo.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

Comportamentos de redução horizontal

O dimensionamento controlado por eventos reduz automaticamente a capacidade quando a demanda por suas funções é reduzida. Essa redução é feita esvaziando as instâncias de suas execuções de função atuais e, em seguida, removendo essas instâncias. Esse comportamento é registrado como modo esvaziar. O período de tolerância para funções que estão sendo executadas pode se estender por até 10 minutos para aplicativos do plano de Consumo e por até 60 minutos para aplicativos dos planos de Consumo Flexível e Premium. O dimensionamento controlado por eventos e esse comportamento não se aplicam a aplicativos de planos Dedicados.

As seguintes considerações se aplicam aos comportamentos de redução horizontal:

  • Para aplicativos em execução no Windows em um plano de consumo, somente os aplicativos criados após maio de 2021 têm comportamentos de modo de drenagem habilitados por padrão.
  • Para habilitar o desligamento normal para funções usando o gatilho do Barramento de Serviço, use a versão 4.2.0 ou posterior da Extensão do Barramento de Serviço.

Escala por função

Aplica-se somente ao plano de Consumo Flexível.

O plano Consumo Flexível é exclusivo, pois implementa um comportamento de escala por função. Na escala por função, exceto para gatilhos HTTP, gatilhos de Blob (Grade de Eventos) e Durable Functions, todos os outros tipos de gatilho de função na escala do aplicativo em instâncias independentes. Os gatilhos HTTP em seu aplicativo são escalados juntos como um grupo nas mesmas instâncias, assim como todos os Blobs (Grade de Eventos) e todos os gatilhos do Durable Functions, que têm suas próprias instâncias compartilhadas.

Considere um aplicativo de funções hospedado por um plano de Consumo Flex que tenha as seguintes funções:

function1 function2 function3 function4 function5 function6 function7
Gatilho HTTP Gatilho HTTP Gatilho de orquestração (Durable) Gatilho de atividade (Durable) Gatilho de Barramento de Serviço Gatilho de Barramento de Serviço Gatilho dos Hubs de Eventos

Neste exemplo:

Melhores práticas e padrões para aplicativos escalonáveis

Há muitos aspectos de um aplicativo de funções que afetarão a qualidade das escalas, incluindo a configuração do host, o volume de runtime e a eficiência dos recursos. Para obter mais informações, consulte a seção de escalabilidade do artigo sobre considerações de desempenho. Adicionalmente, é necessário que você saiba como as conexões se comportam na medida em que o aplicativo de funções é dimensionado. Para saber mais, confira Como gerenciar conexões no Azure Functions.

Se seu aplicativo tiver mais de 100 funções que usam gatilhos baseados em eventos, considere dividi-lo em um ou mais aplicativos, onde cada aplicativo tenha menos de 100 funções baseadas em eventos.

Para obter mais informações sobre o dimensionamento em Python e Node.js, consulte a seção Dimensionamento e desempenho do guia de desenvolvedor do Python do Azure Functions e a seção Dimensionamento e simultaneidade do guia do desenvolvedor do Azure Functions Node.js.

Próximas etapas

Para saber mais, leia os seguintes artigos:

  • Last updated on