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 estas extensões de vinculação:

• Apache Kafka
• BD do Cosmos para o Azure
• Azure Event Hubs
• Armazenamento de Filas do Azure
• Barramento de Serviço do Azure (fila e tópicos)

O dimensionamento baseado em destino substitui o modelo de escalonamento incremental anterior do Azure Functions como o padrão para esses tipos de extensão. O dimensionamento incremental adicionou ou removeu um máximo de um trabalhador em cada nova taxa de instância, com decisões complexas sobre quando dimensionar. Por outro lado, o dimensionamento baseado no destino permite o aumento da escala de quatro instâncias de cada vez, e a decisão de dimensionamento é baseada em uma equação simples baseada no destino:

Nesta equação, o comprimento da fonte do evento refere-se ao número de eventos que devem ser processados. As execuções de destino padrão por valores de instância vêm dos SDKs usados pelas extensões do Azure Functions. Não é necessário fazer alterações para que o dimensionamento baseado em destino funcione.

Considerações

As seguintes considerações se aplicam ao usar o dimensionamento baseado em destino:

• O dimensionamento baseado em destino é habilitado por padrão para aplicativos funcionais nos planos Plano de consumo, Plano Flex Consumption e Elastic Premium. O dimensionamento controlado por eventos não é suportado quando executado em planos Dedicados (Serviço de Aplicativo).
• O dimensionamento baseado em destino é habilitado por padrão a partir da versão 4.19.0 do tempo de execução do Functions.
• Quando você usa o dimensionamento baseado em destino, os limites de escala ainda são respeitados. Para obter mais informações, consulte Limitar a expansão.
• Para obter o dimensionamento mais preciso com base em métricas, use apenas uma função acionada baseada em destino por aplicativo de função. Você também deve considerar a execução em um plano Flex Consumption, que oferece escalonamento por função.
• Quando várias funções no mesmo aplicativo de função estão todas solicitando a expansão ao mesmo tempo, uma soma entre essas funções é usada para determinar a alteração nas instâncias desejadas. Funções que solicitam dimensionamento, substituem funções que solicitam dimensionamento.
• Quando há solicitações de expansão sem nenhuma solicitação de expansão, a escala máxima no valor é usada.

Optar por não participar

O dimensionamento baseado em destino é habilitado por padrão para aplicativos de função hospedados em um plano de consumo ou em um plano Premium. Para desativar o dimensionamento baseado em destino e voltar ao dimensionamento incremental, adicione a seguinte configuração de aplicativo ao seu aplicativo de função:

Definição da Aplicação	Value
TARGET_BASED_SCALING_ENABLED	0

Personalizando o dimensionamento baseado em destino

Você pode tornar o comportamento de dimensionamento 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 execuções de destino por instância.

Esta tabela resume os host.json valores usados para as execuções de destino por valores de instância e os padrões:

Extensão	host.json valores	Valor Predefinido
Hubs de Eventos (Extensão v5.x+)	extensões.eventHubs.maxEventBatchSize	100*
Hubs de Eventos (Extensão v3.x+)	extensões.eventHubs.eventProcessorOptions.maxBatchSize	10
Hubs de Eventos (se definidos)	extensions.eventHubs.targetUnprocessedEventThreshold	n/d
Service Bus (Extensão v5.x+, Despacho Único)	extensions.serviceBus.maxConcurrentCalls	16
Service Bus (extensão v5.x+, baseada em sessões de despacho único)	extensions.serviceBus.maxConcurrentSessions	8
Service Bus (extensão v5.x+, processamento em lote)	extensions.serviceBus.maxMessageBatchSize	1000
Service Bus (Funções v2.x+, Despacho Único)	extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls	16
Service Bus (funções v2.x+, baseadas em sessões de despacho único)	extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions	2000
Service Bus (Funções v2.x+, processamento em lote)	extensions.serviceBus.batchOptions.maxMessageCount	1000
Fila de Armazenamento	extensions.queues.batchSize	16

^* O padrão maxEventBatchSize foi alterado na v6.0.0 do Microsoft.Azure.WebJobs.Extensions.EventHubs pacote. Nas versões anteriores, esse valor era 10.

Para algumas extensões de vinculação, as execuções de destino por instância são definidas usando um atributo de função:

Extensão	Configuração do gatilho de função	Valor Predefinido
Apache Kafka	lagThreshold	1000
Azure Cosmos DB	maxItemsPerInvocation	100

Para saber mais, consulte os exemplos de configurações para as extensões suportadas.

Plano Premium com monitoramento de escala de tempo de execução habilitado

Quando o monitoramento da escala de tempo de execução está habilitado, as próprias extensões lidam com o dimensionamento dinâmico. Isso ocorre porque o controlador de escala não tem acesso a serviços protegidos por uma rede virtual. Depois de habilitar o monitoramento da escala de tempo de execução, você precisará atualizar seus pacotes de extensão para estas versões mínimas para desbloquear a funcionalidade extra de dimensionamento 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
Service Bus	5.9.0
Fila de Armazenamento	5.1.0

Suporte de simultaneidade dinâmica

O dimensionamento baseado em destino introduz um dimensionamento mais rápido e usa padrões para execuções de destino por instância. Ao usar o Service Bus, filas de armazenamento ou Kafka, você também pode habilitar a simultaneidade dinâmica. Nessa configuração, as execuções de destino por valor de instância são determinadas automaticamente pelo recurso de simultaneidade dinâmica. Começa com simultaneidade limitada e identifica a melhor configuração ao longo do tempo.

Extensões suportadas

A maneira como você configura o dimensionamento baseado em destino em seu arquivo host.json depende do tipo de extensão específico. Esta seção fornece os detalhes de configuração para as extensões que atualmente oferecem suporte ao dimensionamento baseado em destino.

Filas e tópicos do Barramento de Serviço

A extensão do Service Bus suporta três modelos de execução, determinados pelos atributos e IsSessionsEnabled do gatilho IsBatched do Service Bus. O valor padrão para IsBatched e IsSessionsEnabled é false.

Modelo de Execução	IsBatched	IsSessionsEnabled	Configuração: Usado para execuções de destino por instância
Processamento de expedição única	false	false	maxConcurrentCalls
Processamento de envio único (baseado em sessão)	false	verdadeiro	maxConcurrentSessions
Processamento em lotes	verdadeiro	false	maxMessageBatchSize ou maxMessageCount

Nota

Eficiência de escala: para a extensão do Service Bus, use Gerenciar direitos em recursos para obter o dimensionamento mais eficiente. Com os direitos de escuta , o dimensionamento reverte para a escala incremental porque o comprimento da fila ou do tópico não pode ser usado para informar decisões de dimensionamento. Para saber mais sobre como definir direitos nas políticas de acesso do Service Bus, 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 maxConcurrentCalls configuração rege as execuções de destino por instância. A configuração específica depende da versão da extensão do Service Bus.

v5.x+

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

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

v2.x+

Modifique a host.json configuração maxConcurrentCalls no messageHandlerOptions, como no exemplo a seguir:

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

Processamento de envio único (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 para o tópico ou fila do Service Bus, cada instância aluga uma ou mais sessões. A configuração específica depende da versão da extensão do Service Bus.

v5.x+

Modifique a host.json configuração maxConcurrentSessions 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 host.json configuração maxConcurrentSessions para sessionHandlerOptions definir execuções de destino por instância, como no exemplo a seguir:

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

Processamento em lotes

Neste 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 Service Bus.

v5.x+

Modifique a host.json configuração maxMessageBatchSize 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 host.json configuração maxMessageCount para batchOptions definir execuções de destino por instância, como no exemplo a seguir:

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "batchOptions": {
                "maxMessageCount": 1000
            }
        }
    }
}

Hubs de Eventos

Para Hubs de Eventos do Azure, o Azure Functions é dimensionado com base no número de eventos não processados distribuídos por todas as partições no hub de eventos. Por padrão, os host.json atributos usados para execuções de destino por instância são maxEventBatchSize e maxBatchSize. No entanto, se você optar por ajustar o dimensionamento baseado em destino, poderá definir um parâmetro targetUnprocessedEventThreshold separado que substituirá para definir execuções de destino por instância sem alterar as configurações de 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á arredondado para uma contagem de instâncias de trabalho que cria uma distribuição de partição balanceada.

Nota

Como os Hubs de Eventos são uma carga de trabalho particionada, a contagem de instâncias de destino para Hubs de Eventos é limitada pelo número de partições no hub de eventos.

A configuração específica depende da versão da extensão Hubs de Eventos.

v5.x+

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

v3.x+

Para v3.x+ da extensão Hubs de Eventos, modifique a host.json configuração maxBatchSize em eventProcessorOptions para definir 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 Storage, modifique a host.json configuração batchSize para definir execuções de destino por instância:

{
    "version": "2.0",
    "extensions": {
        "queues": {
            "batchSize": 16
        }
    }
}

Nota

Eficiência de escala: para a extensão da fila de armazenamento, as mensagens com visibilityTimeout ainda são contadas no comprimento da fonte do evento pelas APIs da fila de armazenamento. Isso pode causar o dimensionamento excessivo do seu aplicativo de função. Considere usar filas do Barramento de Serviço que mensagens agendadas, limitar a expansão ou não usar visibilityTimeout para 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 linguagem da função.

C#

Para uma função C# compilada, defina MaxItemsPerInvocation 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 Functions que usam function.json, o MaxItemsPerInvocation parâmetro é 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"
        }
    ]
}

Exemplos para o modelo de programação Python v2 ainda não estão disponíveis.

JavaScript/PowerShell/TypeScript

Para linguagens Functions que usam function.json, o MaxItemsPerInvocation parâmetro é 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"
    }
  ]
}

Exemplos para o modelo de programação Node.js v4 ainda não estão disponíveis.

Nota

Como o Azure Cosmos DB é uma carga de trabalho particionada, a contagem de instâncias de destino para o banco de dados é limitada pelo número de partições físicas em seu contêiner. Para saber mais sobre o dimensionamento do Azure Cosmos DB, consulte partições físicas e propriedade de locação.

Apache Kafka

A extensão Apache Kafka usa um atributo de nível de função, LagThreshold. Para Kafka, o número de instâncias desejadas é calculado com base no atraso total do consumidor dividido pela LagThreshold configuração. Para um determinado atraso, a redução do limite de atraso aumenta o número de instâncias desejadas.

A maneira como você define esse atributo de nível de função depende da linguagem da função. Este exemplo define o limite como 100.

C#

Para uma função C# compilada, defina LagThreshold sua definição de gatilho, conforme mostrado nos exemplos a seguir para uma função C# em processo para um gatilho de Hubs de Eventos 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 Functions que usam function.json, o LagThreshold parâmetro é definido na associação específica, como neste exemplo de gatilho de Hubs de Eventos 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"
        }
    ]
}

O modelo de programação Python v2 não é atualmente suportado pela extensão Kafka.

JavaScript/PowerShell/TypeScript

Para linguagens Functions que usam function.json, o LagThreshold parâmetro é definido na associação específica, como neste exemplo de gatilho de Hubs de Eventos 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"
        }
    ]
}

O modelo de programação Node.js v4 não é suportado atualmente pela extensão Kafka.

Próximos passos

Para saber mais, leia os artigos seguintes:

• Melhorar o desempenho e a fiabilidade do Azure Functions
• Processamento de eventos confiável do Azure Functions