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.

v5.x+

Modifique a configuração host.jsonmaxConcurrentCalls, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentCalls": 16
        }
    }
}

v2.x+

Modifique a configuração host.jsonmaxConcurrentCalls em messageHandlerOptions, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "messageHandlerOptions": {
                "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.

v5.x+

Modifique a configuração host.jsonmaxConcurrentSessions para definir execuções de destino por instância, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentSessions": 8
        }
    }
}

v2.x+

Modifique a configuração host.jsonmaxConcurrentSessions em sessionHandlerOptions para definir as execuções de destino por instância, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "sessionHandlerOptions": {
                "maxConcurrentSessions": 2000
            }
        }
    }
}

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.

v5.x+

Modifique a configuração host.jsonmaxMessageBatchSize para definir execuções de destino por instância, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxMessageBatchSize": 1000
        }
    }
}

v2.x+

Modifique a configuração host.jsonmaxMessageCount em batchOptions para definir as execuções de destino por instância, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "batchOptions": {
                "maxMessageCount": 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.

v5.x+

Modifique a configuração host.jsonmaxEventBatchSize 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
        }
    }
}

v3.x+

Para v3.x+ da extensão do Hubs de Eventos, modifique a configuração host.jsonmaxBatchSize em eventProcessorOptions para definir as execuções de destino por instância:

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "eventProcessorOptions": {
                "maxBatchSize": 10
            }
        }
    }
}

Quando definido em host.json, targetUnprocessedEventThreshold é usado como execuções de destino por instância em vez de maxBatchSize, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 23
        }
    }
}

Filas de Armazenamento

Para v2.x+ da extensão de Armazenamento, modifique a configuração host.jsonbatchSize 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.

C#

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}");
            }
        }
    }
}

Java

Exemplo de Java pendente.

Python

Para linguagens de funções que utilizam function.json, o parâmetro MaxItemsPerInvocation é definido na associação específica, como neste exemplo de gatilho do Azure Cosmos DB:

{
    "scriptFile": "main.py",
    "bindings": [
        {
          "type": "cosmosDBTrigger",
          "maxItemsPerInvocation": 100,
          "connection": "MyCosmosDb",
          "leaseContainerName": "leases",
          "containerName": "collectionName",
          "databaseName": "databaseName",
          "leaseDatabaseName": "databaseName",
          "createLeaseContainerIfNotExists": false,
          "startFromBeginning": false,
          "name": "input"
        }
    ]
}

Os exemplos do modelo de programação do Python v2 ainda não estão disponíveis.

JavaScript/PowerShell/TypeScript

Para linguagens de funções que utilizam function.json, o parâmetro MaxItemsPerInvocation é definido na associação específica, como neste exemplo de gatilho do Azure Cosmos DB:

{
  "bindings": [
    {
      "type": "cosmosDBTrigger",
      "maxItemsPerInvocation": 100,
      "connection": "MyCosmosDb",
      "leaseContainerName": "leases",
      "containerName": "collectionName",
      "databaseName": "databaseName",
      "leaseDatabaseName": "databaseName",
      "createLeaseContainerIfNotExists": false,
      "startFromBeginning": false,
      "name": "input"
    }
  ]
}

Os exemplos do modelo de programação do Node.js v4 ainda não estão disponíveis.

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.

C#

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}");
}

Java

public class KafkaTriggerMany {
    @FunctionName("KafkaTriggerMany")
    public void runMany(
            @KafkaTrigger(
                name = "kafkaTriggerMany",
                topic = "topic",  
                brokerList="%BrokerList%",
                consumerGroup="$Default", 
                username = "$ConnectionString", 
                password = "EventHubConnectionString",
                authenticationMode = BrokerAuthenticationMode.PLAIN,
                protocol = BrokerProtocol.SASLSSL,
                LagThreshold = 100,
                // sslCaLocation = "confluent_cloud_cacert.pem", // Enable this line for windows.
                cardinality = Cardinality.MANY,
                dataType = "string"
             ) String[] kafkaEvents,
            final ExecutionContext context) {
            for (String kevent: kafkaEvents) {
                context.getLogger().info(kevent);
            }

Python

Para linguagens do Functions que usam function.json, o parâmetro LagThreshold é definido na associação específica, como neste exemplo de gatilho dos Hubs de Eventos do Kafka:

{
      "scriptFile": "main.py",
      "bindings": [
        {
          "type": "kafkaTrigger",
          "name": "kevent",
          "topic": "topic",
          "brokerList": "%BrokerList%",
          "username": "$ConnectionString",
          "password": "EventHubConnectionString",
          "consumerGroup" : "functions",
          "protocol": "saslSsl",
          "authenticationMode": "plain",
          "lagThreshold": "100"
        }
    ]
}

Atualmente, não há suporte para o modelo de programação do Python v2 na extensão do Kafka.

JavaScript/PowerShell/TypeScript

Para linguagens do Functions que usam function.json, o parâmetro LagThreshold é definido na associação específica, como neste exemplo de gatilho dos Hubs de Eventos do Kafka:

{
    "bindings": [
      {
            "type": "kafkaTrigger",
            "name": "kafkaEvent",
            "direction": "in",
            "protocol" : "SASLSSL",
            "password" : "EventHubConnectionString",
            "dataType" : "string",
            "topic" : "topic",
            "authenticationMode" : "PLAIN",
            "consumerGroup" : "$Default",
            "username" : "$ConnectionString",
            "brokerList" : "%BrokerList%",
            "sslCaLocation": "confluent_cloud_cacert.pem",
            "lagThreshold": "100"
        }
    ]
}

Atualmente, não há suporte para o modelo de programação do Node.js v4 na extensão do Kafka.

Próximas etapas

Para saber mais, leia os seguintes artigos:

• Melhore o desempenho e a confiabilidade do Azure Functions
• Processamento confiável de eventos do Azure Functions