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 (fila e tópicos)

O dimensionamento baseado em destino substitui o modelo de dimensionamento incremental Azure Functions anterior como o 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 de execuções alvo por instância vêm dos SDKs (Software Development Kits) usadas 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.

Desativar

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:

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:

^* O padrão maxEventBatchSize 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, a configuração de execuções de destino por instância é definida usando um atributo de função:

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 é habilitado, as próprias extensões lidam com o dimensionamento dinâmico 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:

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 Barramento de Serviço, filas de armazenamento ou Kafka, você também pode habilitar a simultaneidade dinâmica. Nessa configuração, o valor de execução _target por instância é determinado automaticamente pela funcionalidade 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.

Barramento de Serviço filas e tópicos

A extensão Barramento de Serviço dá suporte a três modelos de execução, determinados pelos atributos IsBatched e IsSessionsEnabled do gatilho Barramento de Serviço. O valor padrão para IsBatched e IsSessionsEnabled é false.

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 Barramento de Serviço.

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

{
    "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 para o seu tópico ou fila do Barramento de Serviço, cada instância aluga uma ou mais sessões. A configuração específica depende da versão da extensão Barramento de Serviço.

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

{
    "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 Barramento de Serviço.

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

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

Hubs de Eventos

Para Hubs de Eventos do Azure, Azure Functions dimensiona com base no número de eventos não processados distribuídos em todas as partições no hub de eventos dentro de uma lista de contagens de instâncias válidas. 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.

Comportamento de Escalonamento e Estabilidade

Para Hubs de Eventos, operações frequentes de escalonamento para dentro e para fora podem disparar o reequilíbrio de partições, o que leva a atrasos no processamento e ao aumento da latência. Para atenuar isso:

• A plataforma usa uma lista predefinida de contagens de trabalho válidas para orientar decisões de dimensionamento.
• A plataforma garante que o dimensionamento seja estável e deliberado, evitando alterações disruptivas nas atribuições de partição.
• Se a contagem de trabalho desejada não estiver na lista válida, por exemplo, 17, o sistema selecionará automaticamente a próxima maior contagem válida, que nesse caso é 32. Além disso, para evitar escalonamento rápido e repetido, as solicitações de redução horizontal são limitadas a 3 minutos após a última escala vertical. Esse atraso ajuda a reduzir o rebalanceamento desnecessário e contribui para manter a eficiência da taxa de transferência.

Contagens de instância válidas para hubs de eventos

Para cada contagem de partições dos Hubs de Eventos, calculamos uma lista correspondente de contagens de instâncias válidas para garantir a distribuição ideal e o dimensionamento eficiente. Essas contagens são escolhidas para se alinharem bem aos requisitos de particionamento e simultaneidade:

Essas contagens predefinidas ajudam a garantir que as instâncias sejam distribuídas de maneira mais uniforme possível entre as partições, minimizando trabalhadores ociosos ou sobrecarregados.

Configurações dos Hubs de Eventos

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

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "maxEventBatchSize" : 100
        }
    }
}

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

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

{
    "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
        }
    }
}

Azure Cosmos DB

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.

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

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

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

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.

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

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

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

{
    "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"
        }
    ]
}

Próximas etapas

Para saber mais, leia os seguintes artigos:

• Prove o desempenho e a confiabilidade do Azure Functions
• Azure Functions processamento confiável de eventos