Escala controlada por eventos no Azure Functions
Nos planos Consumo e Premium, o Azure Functions escala os recursos de CPU e memória ao adicionar mais instâncias do host do Functions. O número de instâncias é determinado no número de eventos que disparam uma função.
Cada instância do host do Functions no plano de Consumo é limitada, tipicamente a 1,5 GB de memória e uma CPU. Uma instância do host é o aplicativo de funções inteiro, o que significa que todas as funções dentro de um aplicativo de funções compartilham recursos em uma instância e uma escala ao mesmo tempo. Aplicativos de função que compartilham o mesmo plano de Consumo são escalam de forma independente. No plano Premium, o tamanho do plano determina a memória e a CPU disponíveis para todos os aplicativos nesse plano nessa instância.
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
Depois que o aplicativo de funções ficar ocioso por alguns minutos, a plataforma poderá escalar o número de instâncias nas quais seu aplicativo é executado para zero. 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 frios estão afetando suas funções, considere executar em um plano Premium ou em um plano Dedicado com a configuração Always on 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. Uma única instância pode processar mais de uma mensagem ou solicitação por vez, portanto, não há um limite definido de número de execuções simultâneas. 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 sendo executada em um plano Premium.
- Dimensionamento baseado em destino: O dimensionamento baseado em destino fornece um modelo de dimensionamento rápido e intuitivo para clientes e atualmente tem suporte para Filas e Tópicos do Barramento de Serviço, Filas de Armazenamento, Hubs de Eventos e extensões do Cosmos DB. Examine o dimensionamento baseado em destino para entender o comportamento de dimensionamento.
Limitar expansão
Talvez você queira restringir o número máximo de instâncias que um aplicativo usou para escalar horizontalmente. Isso é mais comum para casos em que um componente downstream, como um banco de dados, tem taxa de transferência limitada. Por padrão, as funções do plano de Consumo são escaladas horizontalmente para até 200 instâncias, e as funções de plano Premium serão escaladas horizontalmente para até 100 instâncias. Você pode especificar um número máximo inferior para um aplicativo específico modificando o valor 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 sendo executadas no momento pode se estender por até 10 minutos para aplicativos do plano de consumo e até 60 minutos para aplicativos do plano 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 de função de plano de Consumo em execução no Windows, somente os aplicativos criados após maio de 2021 têm comportamentos de modo esvaziar 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.
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.
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.
Modelo de cobrança
A cobrança dos diferentes planos é descrita detalhadamente na página de preços do Azure Functions. O uso é agregado no nível do aplicativo de funções e conta apenas o tempo durante o qual o código de função é executado. Veja a seguir as unidades de cobrança:
- Consumo de recursos em GB/s (gigabyte por segundo). Calculado como uma combinação do tamanho da memória e o tempo de execução para todas as funções dentro de um aplicativo de Funções.
- Execuções. Contadas toda vez que uma função é executada em resposta a um gatilho de evento.
Consultas e informações úteis sobre como entender sua fatura de consumo podem ser encontradas nas perguntas frequentes sobre cobrança.
Próximas etapas
Para saber mais, leia os seguintes artigos: