Partilhar via

Dimensionamento controlado por eventos no Azure Functions

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

A maneira como seu aplicativo de função é dimensionado depende do plano de hospedagem:

  • Plano de 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 suporta todo o aplicativo de função. Assim, todas as funções dentro de uma aplicação de funções que partilham recursos numa instância são escaladas ao mesmo tempo. Quando os aplicativos de função compartilham o mesmo plano de consumo, eles ainda são dimensionados de forma independente.

  • Plano de Consumo Flexível: O plano utiliza uma estratégia determinística de escalabilidade por função. Cada função é escalada de forma independente, exceto as funções desencadeadas por HTTP, Blob e Funções Duradouras, que escalam nos seus próprios grupos. Para obter mais informações, consulte Dimensionamento por função. Essas instâncias são então dimensionadas 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 dimensiona suas instâncias com base nas necessidades de dimensionamento dos aplicativos no plano, e os aplicativos são dimensionados dentro do plano conforme necessário.

Os arquivos de código de função são armazenados em compartilhamentos de Arquivos do Azure na conta de armazenamento principal da função. Quando você exclui a conta de armazenamento principal do aplicativo de função, os arquivos de código de função são excluídos e não podem ser recuperados.

Dimensionamento de runtime

O Azure Functions usa um componente chamado controlador de escala para monitorar a taxa de eventos e determinar se a expansão deve ser dimensionada ou ampliada. O controlador de dimensionamento utiliza heurística para cada tipo de acionador. Por exemplo, quando você está usando um gatilho de armazenamento de fila do Azure, ele usa o dimensionamento baseado em destino.

A unidade de dimensionamento para as Funções do Azure é a aplicação de funções. Quando o aplicativo de função é expandido, mais recursos são alocados para executar várias instâncias do host do Azure Functions. Por outro lado, à medida que a procura de computação é reduzida, o controlador de dimensionamento remove as instâncias do anfitrião de funções. O número de instâncias é eventualmente "dimensionado" quando nenhuma função está sendo executada em um aplicativo de função.

Diagrama que mostra o controlador de escala a monitorizar eventos e a criar instâncias.

Arranque a frio

Se seu aplicativo de função ficar ocioso por alguns minutos, a plataforma pode decidir dimensionar o número de instâncias nas quais seu aplicativo é executado para zero. A próxima solicitação tem a latência adicional de dimensionamento de zero para um. Esta latência é referida como arranque a frio. O número de dependências exigidas pelo seu aplicativo de função pode afetar o tempo de início a frio. O início a frio é mais um problema para operações síncronas, como gatilhos HTTP que devem retornar uma resposta. Se os arranques a frio estiverem a afetar as suas funções, considere utilizar um plano diferente do de Consumo. Os outros planos oferecem estas estratégias para mitigar ou eliminar arranques a frio:

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

  • Plano Flex Consumption: suporta um número opcional de instâncias sempre prontas, que podem ser definidas com base no dimensionamento por instância.

  • Plano dedicado: o plano em si não escala dinamicamente, mas pode correr a sua aplicação continuamente quando a opção de Sempre ligado estiver ativada.

Compreender comportamentos de dimensionamento

O dimensionamento pode variar com base em vários fatores, e os aplicativos são dimensionados de forma diferente com base nos gatilhos e no idioma selecionados. Existem algumas complexidades de comportamentos de dimensionamento a ter em conta:

  • Instâncias máximas: um aplicativo de função única só é dimensionado para um máximo permitido pelo plano. No entanto, uma única instância pode processar mais de uma mensagem ou solicitação ao mesmo tempo. Você pode especificar um máximo mais baixo para a escala de aceleração, conforme necessário.
  • Nova taxa de instância: para gatilhos HTTP, novas instâncias são alocadas, no máximo, uma vez por segundo. Relativamente a acionadores não HTTP, as instâncias novas serão alocadas uma vez a cada 30 segundos, no máximo. O dimensionamento é mais rápido se for executado num plano Premium .
  • Escalonamento baseado em alvos: A escalabilidade baseada em alvos proporciona um modelo de escalabilidade rápido e intuitivo para os clientes. Atualmente, este método de escalabilidade é suportado para filas e tópicos do Service Bus, filas de armazenamento, Event Hubs, Apache Kafka e extensões Azure Cosmos DB. Certifique-se de revisar o dimensionamento baseado em destino para entender seu comportamento de dimensionamento.
  • Dimensionamento por função: com algumas exceções notáveis, as funções executadas no plano Flex Consumption são dimensionadas em instâncias independentes. As exceções incluem gatilhos HTTP e gatilhos de armazenamento de Blob (Grade de Eventos). Cada um desses tipos de gatilho escala juntos como um grupo nas mesmas instâncias. Da mesma forma, os gatilhos de todas as Funções Duráveis também partilham instâncias e escalam em conjunto. Para obter mais informações, consulte Dimensionamento por função.
  • Máximo de gatilhos monitorados: Atualmente, o controlador de escala só pode monitorar até 100 gatilhos para tomar decisões de escala. Quando seu aplicativo tem mais de 100 gatilhos baseados em eventos, as decisões de dimensionamento são tomadas com base apenas nos primeiros 100 gatilhos executados. Para obter mais informações, consulte Práticas recomendadas e padrões para aplicativos escaláveis.

Limitar a expansão

Pode decidir restringir o número máximo de instâncias que uma aplicação pode usar para expansão horizontal. Esta limitação é mais comum em casos em que um componente a jusante, como uma base de dados, possui uma capacidade de processamento limitada. Para obter os limites máximos de escala ao executar os vários planos de hospedagem, consulte Limites de escala.

Plano de consumo Flex

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

Embora possa alterar o número máximo de instâncias das aplicações Flex Consumption para até 1000, o limite de quota para as suas aplicações é atingido antes de atingir esse número. Consulte as cotas de memória de assinatura regional 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 az functionapp scale config set comando 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 de Consumo/Premium

Em um plano Consumo ou Elastic Premium, você pode especificar um limite máximo inferior para seu aplicativo modificando o valor da definição de configuração do functionAppScaleLimit site. 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 scale-in

O dimensionamento controlado por eventos reduz automaticamente a capacidade quando a demanda por suas funções é reduzida. Faz esta redução ao drenar instâncias das suas execuções de funções atuais, removendo essas instâncias. Esse comportamento é registrado como modo de drenagem. O período de carência para funções que estão sendo executadas atualmente pode se estender por até 10 minutos para aplicativos do plano de consumo e até 60 minutos para aplicativos do plano Flex Consumption e Premium. O dimensionamento controlado por eventos e esse comportamento não se aplicam aos aplicativos de plano dedicado.

As seguintes considerações se aplicam a comportamentos de expansão:

  • Para aplicações a correr no Windows num plano de Consumo, apenas as aplicações criadas após maio de 2021 têm comportamentos de modo de drenagem ativados por defeito.
  • Para habilitar o desligamento normal para funções usando o gatilho do Service Bus, use a versão 4.2.0 ou uma versão posterior da Extensão do Service Bus.

Dimensionamento por função

Aplica-se apenas ao plano Flex Consumption.

O plano Flex Consumption é único na medida em que implementa um comportamento de dimensionamento por função. No dimensionamento por função, exceto para gatilhos HTTP, Blob (Grade de Eventos) e Funções Duráveis, todos os outros tipos de gatilho de função em seu aplicativo são dimensionados em instâncias independentes. Todos os gatilhos HTTP em seu aplicativo são dimensionados como um grupo nas mesmas instâncias, assim como todos os gatilhos de Blob (Grade de Eventos) e todos os gatilhos de Funções Duráveis, que têm suas próprias instâncias compartilhadas.

Considere uma aplicação de funções alojada por um plano Flex Consumption que tem as seguintes funções:

função1 função2 função3 função4 função5 função6 função7
Acionador HTTP Acionador HTTP Gatilho de orquestração (durável) Gatilho de atividade (durável) Gatilho do Service Bus Gatilho do Service Bus Os Hubs de Eventos disparam

Neste exemplo:

Práticas recomendadas e padrões para aplicativos escaláveis

Há muitos aspetos de um aplicativo de função que afetam a forma como ele é dimensionado, incluindo a configuração do host, o espaço ocupado pelo tempo de execução e a eficiência de recursos. Para obter mais informações, consulte a seção escalabilidade do artigo Considerações sobre desempenho. Você também deve estar ciente de como as conexões se comportam à medida que seu aplicativo de função é dimensionado. Para obter mais informações, consulte Como gerenciar conexões no Azure Functions.

Se o seu aplicativo tiver mais de 100 funções que usam gatilhos baseados em eventos, considere dividir o aplicativo em um ou mais aplicativos, onde cada aplicativo tem menos de 100 funções baseadas em eventos.

Para mais informações sobre escalabilidade em Python e Node.js, consulte a secção Escalabilidade e desempenho do guia para programadores Azure Functions Python e a secção de Escalabilidade e concorrência do guia para desenvolvedores Azure Functions Node.js.

Próximos passos

Para saber mais, leia os artigos seguintes:

  • Last updated on