Escala baseada em destino
O dimensionamento baseado em destino fornece um modelo de dimensionamento rápido e intuitivo para os clientes e atualmente tem suporte para essas extensões de associação:
- Apache Kafka
- Azure Cosmos DB
- Hubs de eventos do Azure
- Armazenamento de Filas do Azure
- Barramento de Serviço do Azure (filas e tópicos)
A escala baseada em destino substitui o modelo da escala incremental do Azure Functions anterior como padrão para esses tipos de extensão. A escala incremental adicionou ou removeu no máximo um trabalhador a cada nova taxa de instância , com decisões complexas para quando colocar em escala. Em contraste, a escala baseada em destino permite escalar verticalmente quatro instâncias por vez, e a decisão de colocação em escala é baseada em uma equação simples baseada em destino:
Nessa equação, comprimento da fonte do evento refere-se ao número de eventos que devem ser processados. Os valores padrão das execuções de destino por instância vêm dos SDKs usados pelas extensões do Azure Functions. Você não precisa fazer nenhuma alteração para que a escala baseada em destino funcione.
Considerações
As seguintes considerações se aplicam ao usar a escala baseada em destino:
- O dimensionamento baseado em destino é habilitado por padrão para aplicativos de funções no Plano de Consumo, Plano de Consumo Flexe Planos Elastic Premium. Não há suporte para dimensionamento controlado por eventos durante a execução nos Planos Dedicados (Serviço de Aplicativo).
- O dimensionamento baseado em destino é habilitado por padrão, começando com a versão 4.19.0 do runtime do Functions.
- Quando você usa o dimensionamento baseado em destino, os limites de escala ainda são respeitados. Para obter mais informações, consulte Limite o escalonamento horizontal.
- Para obter a escala mais precisa com base em métricas, use somente uma função de gatilho com base em destino por aplicativo de funções. Você também deve considerar a execução em um Plano de Consumo Flex, que oferece dimensionamento por função.
- Quando várias funções no mesmo aplicativo de funções estão solicitando escalar horizontalmente ao mesmo tempo, uma soma entre essas funções é usada para determinar a alteração nas instâncias desejadas. As funções que solicitam a escala horizontal substituem as funções que solicitam a redução horizontal.
- Quando há solicitações de redução horizontal sem solicitações de expansão, a escala máxima no valor é usada.
Recusa
A escala baseada em destino é habilitado por padrão para aplicativos de funções hospedados em um plano de Consumo ou em planos Premium. Para desativar a escala baseada em destino e reverter para a escala incremental, adicione a seguinte configuração de aplicativo ao seu aplicativo de funções:
Configurações de Aplicativo | Valor |
---|---|
TARGET_BASED_SCALING_ENABLED |
0 |
Personalização da escala baseada em destino
Você pode tornar o comportamento da escala mais ou menos agressivo com base na carga de trabalho do seu aplicativo ajustando as execuções de destino por instância. Cada extensão tem configurações diferentes que você pode usar para definir as execuções de destino por instância.
Esta tabela resume os valores host.json
sados para os valores de execuções de destino por instância e os padrões:
Extensão | valores host.json | Valor padrão |
---|---|---|
Hubs de Eventos do Azure (Extensão v5.x+) | extensions.eventHubs.maxEventBatchSize | 100* |
Hubs de Eventos do Azure (Extensão v3.x+) | extensions.eventHubs.eventProcessorOptions.maxBatchSize | 10 |
Hubs de Eventos do Azure (se definido) | extensions.eventHubs.targetUnprocessedEventThreshold | N/D |
Barramento de Serviço do Azure (Extensão v5.x+, Expedição Única) | extensions.serviceBus.maxConcurrentCalls | 16 |
Barramento de Serviço do Azure (Extensão v5.x+, Baseado em Sessões de Expedição Única) | extensions.serviceBus.maxConcurrentSessions | 8 |
Barramento de Serviço do Azure (Extensão v5.x+, Processamento em Lote) | extension.serviceBus.maxMessageBatchSize | 1000 |
Barramento de Serviço do Azure (Funções v2.x+, Expedição Única) | extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls | 16 |
Barramento de Serviço do Azure (Funções v2.x+, Baseado em Sessões de Expedição Única) | extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions | 2000 |
Barramento de Serviço do Azure (Funções v2.x+, Processamento em Lote) | extensions.serviceBus.batchOptions.maxMessageCount | 1000 |
Fila de Armazenamento | extensions.queues.batchSize | 16 |
* O maxEventBatchSize
padrão foi alterado na v6.0.0 do pacote Microsoft.Azure.WebJobs.Extensions.EventHubs
. Nas versões anteriores, esse valor era 10.
Para algumas extensões de associação, as execuções de destino por instância são definidas por meio de um atributo de função:
Extensão | Configuração do gatilho da função | Valor padrão |
---|---|---|
Apache Kafka | lagThreshold |
1000 |
Azure Cosmos DB | maxItemsPerInvocation |
100 |
Para saber mais, confira as configurações de exemplo para as extensões suportadas.
Plano Premium com monitoramento de escala em runtime habilitado
Quando o monitoramento de escala de runtime está habilitado, as próprias extensões cuidam do dimensionamento dinâmico. Isso ocorre porque o controlador de escala não tem acesso aos serviços protegidos por uma rede virtual. Depois de habilitar o monitoramento de escala de runtime, atualize seus pacotes de extensão para estas versões mínimas, a fim de desbloquear a funcionalidade extra de escala baseada em destino:
Nome da extensão | Versão Mínima Necessária |
---|---|
Apache Kafka | 3.9.0 |
Azure Cosmos DB | 4.1.0 |
Hubs de Eventos | 5.2.0 |
Barramento de Serviço | 5.9.0 |
Fila de Armazenamento | 5.1.0 |
O suporte a simultaneidade dinâmica
A escala baseada em destino introduz a colocação em escala mais rápida e usa padrões para execuções de destino por instância. Ao usar o Barramento de Serviço, as filas de Armazenamento ou o Kafka, você também pode habilitar a simultaneidade dinâmica. Nessa configuração, o valor de execuções de destino por instância é determinado automaticamente pelo recurso de simultaneidade dinâmica. Ele começa com uma simultaneidade limitada e identifica a melhor configuração ao longo do tempo.
Extensões com suporte
A maneira como você configura a escala baseada em destino no arquivo host.json depende do tipo de extensão específico. Esta seção fornece os detalhes da configuração para as extensões que atualmente suportam a escala baseada em destino.
Filas e tópicos do Barramento de Serviço
A extensão do Barramento de Serviço do Azure suporta três modelos de execução, determinados pelos atributos IsBatched
e IsSessionsEnabled
do seu gatilho do Barramento de Serviço do Azure. O valor padrão para IsBatched
e IsSessionsEnabled
é false
.
Modelo de execução | IsBatched | IsSessionsEnabled | A Configuração Usada para as execuções de destino por instância |
---|---|---|---|
Processamento de expedição única | false | false | maxConcurrentCalls |
Processamento de expedição única (baseado em sessão) | false | true | maxConcurrentSessions |
Processamento em lotes | true | false | maxMessageBatchSize ou maxMessageCount |
Observação
Eficiência da escala: para a extensão do Barramento de Serviço do Azure, use os direitos de Gerenciar em recursos para a colocação em escala mais eficiente. Com Ouvir, a escala de direitos é revertida para uma escala incremental porque a fila ou o tamanho do tópico não podem ser usados para informar as decisões de colocação em escala. Para saber mais sobre como definir direitos nas políticas de acesso do Barramento de Serviço, consulte Política de autorização de acesso Compartilhado.
Processamento de expedição única
Neste modelo, cada invocação da sua função processa uma única mensagem. A configuração maxConcurrentCalls
governa as execuções de destino por instância. A configuração específica depende da versão da extensão do Barramento de Serviço do Azure.
Modifique a configuração host.json
maxConcurrentCalls
, como no exemplo a seguir:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentCalls": 16
}
}
}
Processamento de expedição única (baseado em sessão)
Neste modelo, cada invocação da sua função processa uma única mensagem. No entanto, dependendo do número de sessões ativas no tópico ou fila do Barramento de Serviço do Azure, cada instância concede uma ou mais sessões. A configuração específica depende da versão da extensão do Barramento de Serviço do Azure.
Modifique a configuração host.json
maxConcurrentSessions
para definir execuções de destino por instância, como no exemplo a seguir:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentSessions": 8
}
}
}
Processamento em lotes
Nesse modelo, cada invocação da sua função processa um lote de mensagens. A configuração específica depende da versão da extensão do Barramento de Serviço do Azure.
Modifique a configuração host.json
maxMessageBatchSize
para definir execuções de destino por instância, como no exemplo a seguir:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxMessageBatchSize": 1000
}
}
}
Hubs de Eventos
Para o Hubs de Eventos do Azure, as escalas do Azure Functions são baseadas no número de eventos não processados distribuídos em todas as partições no hub de eventos. Por padrão, os atributos host.json
usados para execuções de destino por instância são maxEventBatchSize
e maxBatchSize
. No entanto, se você optar por ajustar a escala baseada em destino, poderá definir um parâmetro separado targetUnprocessedEventThreshold
que seja substituído para definir execuções de destino por instância sem alterar as configurações do lote. Se targetUnprocessedEventThreshold
for definido, a contagem total de eventos não processados será dividida por esse valor para determinar o número de instâncias, que será então arredondado para uma contagem de instâncias de trabalho que criará uma distribuição balanceada de partições.
Observação
Como os Hubs de Eventos são uma carga de trabalho particionada, a contagem de instâncias de destino para os Hubs de Eventos é limitada pelo número de partições no seu hub de eventos.
A configuração específica depende da versão da extensão Hubs de Eventos.
Modifique a configuração host.json
maxEventBatchSize
para definir execuções de destino por instância, como no exemplo a seguir:
{
"version": "2.0",
"extensions": {
"eventHubs": {
"maxEventBatchSize" : 100
}
}
}
Quando definido em host.json
, targetUnprocessedEventThreshold
é usado como execuções de destino por instância em vez de maxEventBatchSize
, como no exemplo a seguir:
{
"version": "2.0",
"extensions": {
"eventHubs": {
"targetUnprocessedEventThreshold": 153
}
}
}
Filas de Armazenamento
Para v2.x+ da extensão de Armazenamento, modifique a configuração host.json
batchSize
para definir as execuções de destino por instância:
{
"version": "2.0",
"extensions": {
"queues": {
"batchSize": 16
}
}
}
Observação
Eficiência de escala: Para a extensão da fila de armazenamento, as mensagens com visibilityTimeout ainda são contadas na duração da origem do evento pelas APIs da Fila de Armazenamento. Isso pode causar o superdimensionamento do seu aplicativo de funções. Considere usar as filas do Barramento de Serviço que consultam mensagens agendadas, limitando a escala horizontal ou deixando de usar o visibilityTimeout na sua solução.
Azure Cosmos DB
O Azure Cosmos DB usa um atributo de nível de função, MaxItemsPerInvocation
. A maneira como você define esse atributo de nível de função depende da sua linguagem de função.
Para uma função C# compilada, defina MaxItemsPerInvocation
na sua definição de gatilho, conforme mostrado nos exemplos a seguir para uma função C# em processo:
namespace CosmosDBSamplesV2
{
public static class CosmosTrigger
{
[FunctionName("CosmosTrigger")]
public static void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
collectionName: "Items",
MaxItemsPerInvocation: 100,
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases",
CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
ILogger log)
{
if (documents != null && documents.Count > 0)
{
log.LogInformation($"Documents modified: {documents.Count}");
log.LogInformation($"First document Id: {documents[0].Id}");
}
}
}
}
Observação
Como o Azure Cosmos DB é uma carga de trabalho particionada, a contagem de instâncias de destino do banco de dados é limitada pelo número de partições físicas no seu contêiner. Para saber mais sobre a escala do Azure Cosmos DB, confira partições físicas e propriedade de concessão.
Apache Kafka
A extensão do Apache Kafka usa um atributo de nível de função, LagThreshold
. Para o Kafka, o número de instâncias desejadas é calculado com base no retardo total do consumidor dividido pela configuração LagThreshold
. No caso de um determinado retardo, a redução do limite de retardo aumenta o número de instâncias desejadas.
A maneira como você define esse atributo de nível de função depende da sua linguagem de função. Este exemplo define o limite como 100
.
Para uma função C# compilada, defina LagThreshold
na definição de gatilho, conforme mostrado nos seguintes exemplos para uma função C# em processo referente a um gatilho dos Hubs de Eventos do Kafka:
[FunctionName("KafkaTrigger")]
public static void Run(
[KafkaTrigger("BrokerList",
"topic",
Username = "$ConnectionString",
Password = "%EventHubConnectionString%",
Protocol = BrokerProtocol.SaslSsl,
AuthenticationMode = BrokerAuthenticationMode.Plain,
ConsumerGroup = "$Default",
LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{
log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}
Próximas etapas
Para saber mais, leia os seguintes artigos: