Dimensionamento controlado por eventos no Azure Functions
Nos planos Consumo e Premium, o Azure Functions dimensiona recursos de CPU e memória adicionando mais instâncias do host do Functions. O número de instâncias é determinado pelo número de eventos que acionam uma função.
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 é o aplicativo de função inteiro, o que significa que todas as funções dentro de um aplicativo de função compartilham recursos dentro de uma instância e são dimensionadas ao mesmo tempo. Os aplicativos de função que compartilham o mesmo plano de consumo são dimensionados de forma independente. No plano Premium, o tamanho do plano determina a memória disponível e a CPU para todos os aplicativos desse plano nessa instância.
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.
Arranque a frio
Depois que seu aplicativo de função ficar ocioso por alguns minutos, a plataforma poderá 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 executar num plano Premium ou num plano Dedicado com a definição Sempre ativada 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. Contudo, cada instância individual pode processar mais de uma mensagem ou pedido de cada vez, pelo que não existe um limite definido quanto ao número de execuções simultâneas. 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 os clientes e atualmente é suportado para Filas e Tópicos do Service Bus, Filas de Armazenamento, Hubs de Eventos e extensões do Cosmos DB. Certifique-se de revisar o dimensionamento baseado em destino para entender seu comportamento de dimensionamento.
Limitar a expansão
Você pode querer restringir o número máximo de instâncias que um aplicativo usou para dimensionar. Isso é mais comum para casos em que um componente a jusante, como um banco de dados, tem taxa de transferência limitada. Por padrão, as funções do plano de consumo são dimensionadas para até 200 instâncias e as funções do plano Premium são dimensionadas para até 100 instâncias. Você pode especificar um máximo inferior para um aplicativo específico modificando o functionAppScaleLimit valor. O functionAppScaleLimit pode ser definido como 0 ou para irrestrito, ou null 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 em execução 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 aos aplicativos de plano dedicado.
As seguintes considerações se aplicam a comportamentos de expansão:
- Para aplicativos da função Plano de consumo executados no Windows, apenas 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 Service Bus, use a versão 4.2.0 ou uma versão posterior da Extensão do Service Bus.
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.
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.
Modelo de faturação
A cobrança dos diferentes planos é descrita em detalhes na página de preços do Azure Functions. O uso é agregado no nível do aplicativo de função e conta apenas o tempo em que o código da função é executado. A seguir estão as unidades para faturamento:
- Consumo de recursos em gigabytes-segundos (GB-s). Calculado como uma combinação de tamanho de memória e tempo de execução para todas as funções dentro de um aplicativo de função.
- Execuções. Contado cada vez que uma função é executada em resposta a um gatilho de evento.
Dúvidas e informações úteis sobre como entender sua conta de consumo podem ser encontradas nas Perguntas frequentes sobre faturamento.
Próximos passos
Para saber mais, leia os artigos seguintes: