Escala controlada por eventos no Azure Functions

Escalabilidade orientada a eventos não se aplica ao plano Dedicado (Serviço de Aplicativo). O plano dedicado não escala dinamicamente com base nos eventos. Para opções de escalabilidade no plano Dedicado, veja Escalar um aplicativo no Serviço de Aplicativo do Azure.

A escalabilidade orientada a eventos não se aplica ao executar funções no Aplicativos de Contêiner do Azure. Quando hospedado em Apps de Contêineres, o escalonamento é gerenciado pelo ambiente de Apps de Contêineres. Para saber mais, confira Definir regras de escala nos Aplicativos de Contêiner do Azure.

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 app de funções escala de forma ampliada, ele aloca mais recursos para rodar múltiplas instâncias do host do Azure Functions. Por outro lado, à medida que a demanda de computação diminui, o controlador de escala remove instâncias do host da 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.

Cada instância do host Functions no plano de Consumo é limitada, tipicamente a 1,5 GB de memória e uma CPU. Uma instância do host suporta todo o app de funções, então todas as funções de um app compartilham recursos e escalam ao mesmo tempo. Quando aplicativos de função compartilham o mesmo plano de Consumo, eles ainda escalam de forma independente.

O tamanho específico do plano Premium determina a memória e CPU disponíveis para todos os aplicativos desse plano naquela situação. 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.

Diferentemente dos outros planos dinâmicos, o plano Flex Consumption utiliza um modelo determinístico de escalonamento por função. Neste modelo, cada função é escalada independentemente com base no número de eventos e configurações de concorrência, exceto para funções disparadas por HTTP, Blob e orquestração (Durável), que escalam em seus próprios grupos. Para obter mais informações, confira Escala por função.

A plataforma gerencia a taxa com que adiciona instâncias (a curva de escala), separadamente do número máximo de instâncias. Para mais informações sobre como a curva de escala funciona, comportamento de limitação e melhores práticas para escalonamento de alta taxa, veja Taxa de escala.

Início frio

Se seu app de funções ficar inativo por alguns minutos, a plataforma pode reduzir o número de instâncias executando seu app para zero. A próxima solicitação sofre a latência adicional de escalonamento de zero para um. Essa latência é conhecida como um início a frio. O número de dependências que seu aplicativo de funções exige pode afetar o horário de início 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 partidas a frio estiverem afetando suas funções, considere usar um plano que apoie estratégias de mitigação:

Como você pode ver nesta tabela, tanto o Flex Consumption quanto o Premium oferecem maneiras de eliminar partidas a frio nos seus aplicativos.

Noções básicas dos comportamentos de dimensionamento

A escala pode variar com base em vários fatores. Os aplicativos escalam de forma diferente dependendo dos gatilhos e do idioma selecionado. Fique atento a estas complexidades dos comportamentos de escalonamento:

• Casos máximos: Um único aplicativo de função escala até o 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, a plataforma aloca novas instâncias no máximo uma vez por segundo. Para gatilhos não HTTP, a plataforma aloca novas instâncias 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 Barramento de Serviço, 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.

• Gatilhos máximos monitorados: Atualmente, o controlador de balança só pode monitorar até 100 gatilhos para tomar decisões de escalabilidade. Quando seu app tem mais de 100 gatilhos baseados em eventos, as decisões de escala são baseadas 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.

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 é 1 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.

A contagem máxima de instâncias se aplica a instâncias sob demanda em cada grupo de escala por função (grupo de funções), e não às instâncias combinadas do app. Instâncias sempre prontas não são limitadas pelo número máximo de instâncias e não contam para ela.

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-account <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

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>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

Taxa de escalonamento

No plano Flex Consumption, a plataforma também gerencia a taxa com que adiciona instâncias (a curva de escala), separadamente da contagem máxima de instâncias. Para saber como a curva de escala funciona, comportamento de limitação e melhores práticas para escalonamento de alta taxa, veja Escala de escala.

Taxa de escalonamento

Nos planos Consumo e Premium, o controlador de balança gerencia a taxa com que novas instâncias são adicionadas. Para os gatilhos HTTP, as 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.

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

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:

Neste exemplo:

• As duas funções disparadas por HTTP (function1 e function2) são executadas juntas em suas próprias instâncias e escaladas juntas de acordo com as configurações de simultaneidade de HTTP.
• As duas funções Durable (function3 e function4) são executadas juntas em suas próprias instâncias e escaladas juntas com base nos limites de simultaneidade configurados.
• A função disparada do Barramento de Serviço function5 é executada por conta própria e é escalada independentemente de acordo com as regras de escala baseadas em destino para filas e tópicos do Barramento de Serviço.
• A função disparada do Barramento de Serviço function6 é executada por conta própria e é escalada independentemente de acordo com as regras de escala baseadas em destino para filas e tópicos do Barramento de Serviço.
• O gatilho dos Hubs de Eventos (function7) é executado em suas próprias instâncias e é escalado independentemente de acordo com as regras de escala baseadas em destino para Hubs de Eventos.

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

Muitos aspectos de um aplicativo de funções impactam como ele escala, incluindo configuração do host, pegada em tempo de execução e eficiência de 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 app tem mais de 100 funções que usam gatilhos baseados em eventos, considere dividir o app em um ou mais apps, onde cada app 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.