Dimensionamento controlado por eventos no Funções do Azure

A escalabilidade orientada a eventos não se aplica ao plano Dedicado (App Service). O plano dedicado não escala dinamicamente com base nos eventos. Para opções de escalabilidade no plano Dedicado, veja Escalar uma aplicação no Serviço de Aplicações do Azure.

A escalabilidade orientada a eventos não se aplica ao executar funções no Azure Container Apps. Quando alojado em Aplicações Container, a escalabilidade é gerida pelo ambiente Aplicações Container. Para obter mais informações, veja Definir regras de dimensionamento no Azure Container Apps.

Dimensionamento de Runtime

O Funções do Azure usa um componente chamado controlador de escalonamento para monitorar a taxa de eventos e determinar se deve aumentar ou reduzir a escala. O controlador de dimensionamento utiliza heurística para cada tipo de acionador. Por exemplo, ao utilizar um acionador de armazenamento de filas do Azure, é usado o dimensionamento baseado em destino.

A unidade de dimensionamento para as Funções do Azure é a aplicação de funções. Quando a function app expande, aloca mais recursos para executar múltiplas instâncias do host do Funções do Azure. Por outro lado, à medida que a procura de computação diminui, o controlador de escala remove instâncias do host da função. O número de instâncias é eventualmente reduzido quando nenhuma função está a ser executada numa aplicação de funções.

Cada instância do host Functions no plano de Consumo é limitada, tipicamente a 1,5 GB de memória e um CPU. Uma instância do host suporta toda a aplicação de funções, por isso todas as funções numa aplicação partilham recursos e escalam ao mesmo tempo. Quando as aplicações de funções partilham o mesmo plano de Consumo, continuam a escalar de forma independente.

O tamanho específico do plano Premium determina a memória e CPU disponíveis para todas as aplicações 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.

Ao contrário 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 nas definições de concorrência, exceto para funções desencadeadas por HTTP, Blob e orquestração (Durável), que escalam nos seus próprios grupos. Para obter mais informações, consulte Dimensionamento por função.

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

Arranque a frio

Se a sua aplicação de funções ficar inativa durante alguns minutos, a plataforma pode reduzir o número de instâncias a executar a sua aplicação para zero. O pedido seguinte sofre a latência acrescida de escalar de zero para um. Esta latência é conhecida como arranque a frio. O número de dependências que a sua aplicação de funções exige pode afetar o tempo de arranque a frio. O início a frio é particularmente problemático para operações síncronas, como gatilhos HTTP que devem retornar uma resposta. Se arranques a frio estiverem a afetar as suas funções, considere usar um plano que apoie estratégias de mitigação:

Como pode ver nesta tabela, tanto os planos Flex Consumption como os Premium oferecem formas de eliminar arranques a frio nas suas aplicações.

Compreender comportamentos de dimensionamento

O dimensionamento pode variar com base em vários fatores. As aplicações escalam de forma diferente consoante os gatilhos e a língua selecionada. Esteja atento a estas complexidades dos comportamentos de escalabilidade:

• Número máximo de casos: Uma única aplicação de função escala até ao 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 triggers 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. 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 metas para entender o 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 Blob storage (Event Grid). 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.

• Gatilhos máximos monitorizados: Atualmente, o controlador de balança só pode monitorizar até 100 gatilhos para tomar decisões de escalabilidade. Quando a sua aplicação tem mais de 100 gatilhos baseados em eventos, as decisões de escala baseiam-se apenas nos primeiros 100 gatilhos que são 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.

Por padrão, os aplicativos executados em um plano Flex Consumption têm limite de 100 instâncias no total. Atualmente, o menor valor máximo de contagem de instâncias é 1, 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.

O número máximo de instâncias aplica-se a instâncias sob demanda em cada grupo de escala por função (grupo de funções), em vez das instâncias combinadas da aplicação. As instâncias sempre prontas não são limitadas pelo número máximo de instâncias nem contam para ele.

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 Cotas de memória de assinatura regional para 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 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

Num plano de Consumo ou Elastic Premium, pode-se especificar um limite máximo inferior para a sua aplicação ao modificar o valor da 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>

$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 gere a taxa a que adiciona instâncias (a curva da escala), separadamente do número máximo de instâncias. Para saber como funciona a curva de escala, comportamento de limitação e melhores práticas para escalabilidade de alta taxa, veja Escala de escala.

Taxa de escalonamento

Nos planos de Consumo e Premium, o controlador de balança gere a taxa a que são adicionadas novas instâncias. Relativamente a acionadores HTTP, as instâncias novas são alocadas uma vez por segundo, no máximo. Para gatilhos não HTTP, novas instâncias são alocadas no máximo uma vez a cada 30 segundos. O dimensionamento é mais rápido se for executado num plano Premium .

Comportamentos de redução de escala

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 encerramento gracioso para funções que utilizam o disparador 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

O Plano Flex Consumption é único na medida em que implementa um escalonamento 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 na sua aplicação são dimensionados em instâncias independentes. Todos os gatilhos HTTP na sua aplicação são dimensionados como um grupo nas mesmas instâncias, tal como todos os gatilhos de Blob (Grelha de Eventos) e todos os gatilhos de Funções Duráveis, que possuem as suas próprias instâncias partilhadas.

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

Neste exemplo:

• As duas funções acionadas por HTTP (function1 e function2) são executadas juntas em suas próprias instâncias e dimensionadas juntas de acordo com as configurações de simultaneidade HTTP.
• As duas funções Durable (function3 e function4) são executadas juntas nas suas próprias instâncias e dimensionadas juntas com base em limites de simultaneidade configurados.
• A função function5 acionada pelo Service Bus é executada de forma autónoma e dimensionada independentemente segundo as regras de dimensionamento orientadas por objetivos para filas e tópicos do Service Bus.
• A função function6 acionada pelo Service Bus é executada de forma autónoma e dimensionada independentemente segundo as regras de dimensionamento orientadas por objetivos para filas e tópicos do Service Bus.
• O desencadeador de Hubs de Eventos (function7) é executado nas suas próprias instâncias e é dimensionado de forma independente segundo as regras de escalonamento baseadas em destino para Hubs de Eventos.

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

Muitos aspetos de uma aplicação de funções influenciam a sua escala, incluindo a configuração do host, a pegada em tempo de execução e a eficiência dos 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 quando a sua aplicação de funções é escalada. Para obter mais informações, consulte Como gerenciar conexões no Funções do Azure.

Se a sua aplicação tiver mais de 100 funções que usam gatilhos baseados em eventos, considere dividir a aplicação em uma ou mais aplicações, onde cada aplicação 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 Funções do Azure Python e a secção de Escalabilidade e concorrência do guia para desenvolvedores Funções do Azure Node.js.