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.
Importante
O plano de Consumo Flex está atualmente em versão preliminar.
A maneira como seu aplicativo de funções é escalado depende do plano de hospedagem:
Plano Consumo: cada instância de host do Functions no plano Consumo é limitada, tipicamente 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 recurso de compartilhamento de aplicativo de funções em uma instância são escaladas ao mesmo tempo. Quando os aplicativos de funções compartilham o mesmo plano Consumo, eles ainda são escalados de forma independente.
Plano Consumo Flexível: o plano usa uma estratégia determinística de escala por função, em que cada função é escalada de forma independente, exceto para funções disparadas por HTTP, Blob e Durable Functions que são escaladas 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 do plano determina a memória e a CPU disponíveis para todos os aplicativos nesse 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.
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: dá suporte a instâncias pré-ativadas e instâncias sempre prontas, com no mínimo uma instância.
Plano Consumo Flexível: dá suporte a um número opcional de instâncias sempre prontas, que podem ser definidas em uma base de escala por instância.
Plano Dedicado: o plano em si não é escalado dinamicamente, mas você pode executar seu aplicativo continuamente se a configuração Always On estiver 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 único aplicativo de funções só é escalado horizontalmente para 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, 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.
- Escala baseada em destino: A escala baseada em destino fornece um modelo de escala rápido e intuitivo para clientes e atualmente tem suporte para filas e tópicos do Barramento de Serviço, filas do Armazenamento, Hubs de Eventos, Apache Kafka e extensões do Cosmos DB. Examine a escala baseada em destino para entender o comportamento de escala.
- Escala por função: com algumas exceções notáveis, as funções em execução na escala do plano Consumo Flexível 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, todos os gatilhos do Durable Functions também compartilham instâncias e são escalados juntos. Para obter mais informações, confira a escala 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 escala são tomadas com base apenas nos primeiros 100 gatilhos executados. Para obter mais informações, consulte Melhores práticas 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. Isso é 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.
Observe que, embora você possa alterar a contagem máxima de instâncias de aplicativos de Consumo Flex para até 1000, seus aplicativos atingirão um limite de cota antes de alcançar esse número. Consulte 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 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. 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 esvaziar. O período de carência para funções que estão em execução pode ser estendido em até 10 minutos para aplicativos do plano Consumo e em até 60 minutos para aplicativos dos planos Consumo Flex 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 executados no Windows em um plano 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 Consumo Flexível (versão prévia).
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 em um plano Consumo Flexível que tenha estas 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:
- As duas funções disparadas por HTTP (
function1efunction2) 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 (
function3efunction4) 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
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 o seu aplicativo tiver mais de 100 funções que usam gatilhos baseados em eventos, considere dividir o aplicativo em um ou mais aplicativos, em que cada aplicativo tenha menos de 100 funções baseadas em eventos.
Para obter mais informações sobre a colocação em escala no Python e Node.js, consulte Guia do desenvolvedor do Python no Azure Functions – escala e simultaneidade e Guia do desenvolvedor do Node.js no Azure Functions – escala e simultaneidade.
Próximas etapas
Para saber mais, leia os seguintes artigos: