Dimensionamento controlado por eventos no Azure Functions

  • Artigo

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.

Importante

O plano Flex Consumption está atualmente em pré-visualizaçã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. Como tal, todas as funções dentro de um recurso de compartilhamento de aplicativo de função em uma instância são dimensionadas 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 usa uma estratégia determinística de dimensionamento por função, onde cada função é dimensionada independentemente, exceto para funções acionadas por HTTP, Blob e funções duráveis que são dimensionadas em 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.

Dimensione eventos de monitoramento do controlador e crie 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 é dimensionado dinamicamente, mas você pode executar seu aplicativo continuamente com a configuração Sempre ativado 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 .
  • Dimensionamento baseado em destino: o dimensionamento baseado em destino fornece um modelo de dimensionamento rápido e intuitivo para clientes e atualmente é suportado para filas e tópicos do Service Bus, filas de armazenamento, Hubs de Eventos, Apache Kafka e extensões do 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, todos os gatilhos de Funções Duráveis também compartilham instâncias e são dimensionados juntos. 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

Você pode decidir restringir o número máximo de instâncias que um aplicativo pode usar para expansão. Isso é mais comum para casos em que um componente a jusante, 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, 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.

Observe que, embora você possa alterar a contagem máxima de instâncias de aplicativos Flex Consumption até 1000, seus aplicativos atingirão um limite de cota 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. Ele faz isso drenando instâncias de suas execuções de função atuais e, em seguida, remove 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 aplicativos executados no Windows em um plano de consumo, apenas 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 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 (pré-visualização).

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 um aplicativo funcional hospedado em um plano Flex Consumption que tenha estas 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 obter mais informações sobre dimensionamento em Python e Node.js, consulte Guia do desenvolvedor Python do Azure Functions - Dimensionamento e simultaneidade e Guia do desenvolvedor do Azure Functions Node.js - Dimensionamento e simultaneidade.

Próximos passos

Para saber mais, leia os artigos seguintes: