Schaalaanpassing op basis van doel

Op doel gebaseerde schaalaanpassing biedt een snel en intuïtief schaalmodel voor klanten en wordt momenteel ondersteund voor deze bindingsextensies:

• Apache Kafka
• Azure Cosmos DB
• Azure Event Hubs
• Azure Queue Storage
• Azure Service Bus (wachtrij en onderwerpen)

Op doel gebaseerde schaalaanpassing vervangt het vorige incrementele schaalmodel van Azure Functions als de standaardwaarde voor deze extensietypen. Incrementeel schalen heeft een maximum van één werkrol toegevoegd of verwijderd bij elke nieuwe instantiesnelheid, met complexe beslissingen voor het schalen van de schaal. Met op doel gebaseerde schaalaanpassing kunt u daarentegen maximaal vier exemplaren tegelijk schalen en is de schaalbeslissing gebaseerd op een eenvoudige vergelijking op basis van een doel:

In deze vergelijking verwijst de lengte van de gebeurtenisbron naar het aantal gebeurtenissen dat moet worden verwerkt. De standaarduitvoeringen per exemplaar zijn afkomstig van de SDK's die worden gebruikt door de Azure Functions-extensies. U hoeft geen wijzigingen aan te brengen voor schaalaanpassing op basis van doel.

Overwegingen

De volgende overwegingen zijn van toepassing bij het gebruik van schaalaanpassing op basis van doel:

• Schalen op basis van doel is standaard ingeschakeld voor functie-apps in het Verbruiksabonnement, Flex Consumption-abonnement en Elastic Premium-abonnementen. Gebeurtenisgestuurd schalen wordt niet ondersteund bij het uitvoeren van toegewezen (App Service)-abonnementen.
• Schalen op basis van doel is standaard ingeschakeld vanaf versie 4.19.0 van de Functions-runtime.
• Wanneer u schaalaanpassing op basis van doel gebruikt, worden schaallimieten nog steeds gehonoreerd. Zie Uitschalen van limieten voor meer informatie.
• Als u de meest nauwkeurige schaal wilt bereiken op basis van metrische gegevens, gebruikt u slechts één op doel gebaseerde geactiveerde functie per functie-app. U moet ook overwegen om te worden uitgevoerd in een Flex Consumption-abonnement, dat schaalaanpassing per functie biedt.
• Wanneer meerdere functies in dezelfde functie-app allemaal tegelijk worden aangevraagd om uit te schalen, wordt een som van deze functies gebruikt om de wijziging in gewenste exemplaren te bepalen. Functies die aanvragen om uit te schalen, overschrijven functies die worden aangevraagd om in te schalen.
• Wanneer er inschalingsaanvragen zijn zonder uitschaalaanvragen, wordt de maximale schaalwaarde gebruikt.

Afmelden

Schalen op basis van doel is standaard ingeschakeld voor functie-apps die worden gehost in een verbruiksabonnement of in een Premium-abonnement. Als u het schalen op basis van doel wilt uitschakelen en wilt terugvallen op incrementeel schalen, voegt u de volgende app-instelling toe aan uw functie-app:

App-instelling	Weergegeven als
TARGET_BASED_SCALING_ENABLED	0

Aanpassen van schaalaanpassing op basis van doel

U kunt het schaalgedrag meer of minder agressief maken op basis van de workload van uw app door doeluitvoeringen per exemplaar aan te passen. Elke extensie heeft verschillende instellingen die u kunt gebruiken om doeluitvoeringen per exemplaar in te stellen.

Deze tabel bevat een overzicht van de host.json waarden die worden gebruikt voor de doeluitvoeringen per exemplaar en de standaardwaarden:

Toestel	waarden voor host.json	Standaardwaarde
Event Hubs (extensie v5.x+)	extensions.eventHubs.maxEventBatchSize	100*
Event Hubs (extension v3.x+)	extensions.eventHubs.eventProcessorOptions.maxBatchSize	10
Event Hubs (indien gedefinieerd)	extensions.eventHubs.targetUnprocessedEventThreshold	N.v.t.
Service Bus (Extension v5.x+, Single Dispatch)	extensions.serviceBus.maxConcurrentCalls	16
Service Bus (Extension v5.x+, Single Dispatch Sessions Based)	extensions.serviceBus.maxConcurrentSessions	8
Service Bus (Extension v5.x+, Batch Processing)	extensions.serviceBus.maxMessageBatchSize	1000
Service Bus (Functions v2.x+, Single Dispatch)	extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls	16
Service Bus (Functions v2.x+, op basis van enkelvoudige verzendingssessies)	extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions	2000
Service Bus (Functions v2.x+, Batch Processing)	extensions.serviceBus.batchOptions.maxMessageCount	1000
Opslagwachtrij	extensions.queues.batchSize	16

^* De standaardwaarde maxEventBatchSize is gewijzigd in v6.0.0 van het Microsoft.Azure.WebJobs.Extensions.EventHubs pakket. In eerdere versies was deze waarde 10.

Voor sommige bindingsextensies worden doeluitvoeringen per exemplaar ingesteld met behulp van een functiekenmerk:

Toestel	Instelling voor functietrigger	Standaardwaarde
Apache Kafka	lagThreshold	1000
Azure Cosmos DB	maxItemsPerInvocation	100

Zie de voorbeeldconfiguraties voor de ondersteunde extensies voor meer informatie.

Premium-abonnement waarbij bewaking van runtimeschaal is ingeschakeld

Wanneer bewaking van runtimeschaal is ingeschakeld, verwerken de extensies zelf dynamisch schalen. Dit komt doordat de schaalcontroller geen toegang heeft tot services die worden beveiligd door een virtueel netwerk. Nadat u runtimeschaalbewaking hebt ingeschakeld, moet u uw extensiepakketten upgraden naar deze minimale versies om de extra schaalfunctionaliteit op basis van doel te ontgrendelen:

Extensienaam	Minimale versie vereist
Apache Kafka	3.9.0
Azure Cosmos DB	4.1.0
Event Hubs	5.2.0
Service Bus	5.9.0
Opslagwachtrij	5.1.0

Ondersteuning voor dynamische gelijktijdigheid

Schaalaanpassing op basis van doel introduceert snellere schaalaanpassing en maakt gebruik van standaardwaarden voor doeluitvoeringen per exemplaar. Wanneer u Service Bus, Opslagwachtrijen of Kafka gebruikt, kunt u ook dynamische gelijktijdigheid inschakelen. In deze configuratie worden de doeluitvoeringen per exemplaarwaarde automatisch bepaald door de functie voor dynamische gelijktijdigheid. Het begint met beperkte gelijktijdigheid en identificeert de beste instelling in de loop van de tijd.

Ondersteunde extensies

De manier waarop u schaalaanpassing op basis van doel configureert in uw host.json-bestand, is afhankelijk van het specifieke extensietype. Deze sectie bevat de configuratiedetails voor de extensies die momenteel ondersteuning bieden voor schaalaanpassing op basis van doel.

Service Bus-wachtrijen en -onderwerpen

De Service Bus-extensie ondersteunt drie uitvoeringsmodellen, die worden bepaald door de IsBatched en IsSessionsEnabled kenmerken van uw Service Bus-trigger. De standaardwaarde voor IsBatched en IsSessionsEnabled is false.

Uitvoeringsmodel	IsBatched	IsSessionsEnabled	Instelling gebruikt voor doeluitvoeringen per exemplaar
Verwerking van één verzending	false	false	maxConcurrentCalls
Verwerking van één verzending (op sessie gebaseerd)	false	true	maxConcurrentSessions
Batchverwerking	true	false	maxMessageBatchSize of maxMessageCount

Notitie

Schaalefficiëntie: gebruik voor de Service Bus-extensie Beheerrechten voor resources voor de meest efficiënte schaalaanpassing. Als de schaal van listen-rechten wordt teruggezet naar incrementele schaal omdat de wachtrij- of onderwerplengte niet kan worden gebruikt om beslissingen over schaalaanpassing te informeren. Zie Autorisatiebeleid voor gedeelde toegang voor meer informatie over het instellen van rechten in Service Bus-toegangsbeleid.

Verwerking van één verzending

In dit model verwerkt elke aanroep van uw functie één bericht. De maxConcurrentCalls instelling bepaalt doeluitvoeringen per exemplaar. De specifieke instelling is afhankelijk van de versie van de Service Bus-extensie.

v5.x+

Wijzig de host.json instelling maxConcurrentCalls, zoals in het volgende voorbeeld:

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

v2.x+

Wijzig de host.json instelling maxConcurrentCalls in messageHandlerOptions, zoals in het volgende voorbeeld:

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

Verwerking van één verzending (op sessie gebaseerd)

In dit model verwerkt elke aanroep van uw functie één bericht. Afhankelijk van het aantal actieve sessies voor uw Service Bus-onderwerp of -wachtrij, leaset elk exemplaar echter een of meer sessies. De specifieke instelling is afhankelijk van de versie van de Service Bus-extensie.

v5.x+

Wijzig de host.json instelling maxConcurrentSessions om doeluitvoeringen per exemplaar in te stellen, zoals in het volgende voorbeeld:

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

v2.x+

Wijzig de host.json instelling maxConcurrentSessions om sessionHandlerOptions doeluitvoeringen per exemplaar in te stellen, zoals in het volgende voorbeeld:

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

Batchverwerking

In dit model verwerkt elke aanroep van uw functie een batch berichten. De specifieke instelling is afhankelijk van de versie van de Service Bus-extensie.

v5.x+

Wijzig de host.json instelling maxMessageBatchSize om doeluitvoeringen per exemplaar in te stellen, zoals in het volgende voorbeeld:

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

v2.x+

Wijzig de host.json instelling maxMessageCount om batchOptions doeluitvoeringen per exemplaar in te stellen, zoals in het volgende voorbeeld:

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

Event Hubs

Voor Azure Event Hubs wordt Azure Functions geschaald op basis van het aantal niet-verwerkte gebeurtenissen dat is gedistribueerd over alle partities in de Event Hub. Standaard zijn maxEventBatchSize de host.json kenmerken die worden gebruikt voor doeluitvoeringen per exemplaar en maxBatchSize. Als u er echter voor kiest om schaalaanpassing op basis van doel af te stemmen, kunt u een afzonderlijke parameter targetUnprocessedEventThreshold definiëren die overschrijft om doeluitvoeringen per exemplaar in te stellen zonder de batchinstellingen te wijzigen. Als targetUnprocessedEventThreshold dit is ingesteld, wordt het totale aantal niet-verwerkte gebeurtenissen gedeeld door deze waarde om het aantal exemplaren te bepalen, dat vervolgens wordt afgerond op een aantal werkrollen dat een evenredige partitiedistributie maakt.

Notitie

Omdat Event Hubs een gepartitioneerde workload is, wordt het aantal doelexemplaren voor Event Hubs beperkt door het aantal partities in uw Event Hub.

De specifieke instelling is afhankelijk van de versie van de Event Hubs-extensie.

v5.x+

Wijzig de host.json instelling maxEventBatchSize om doeluitvoeringen per exemplaar in te stellen, zoals in het volgende voorbeeld:

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

Wanneer dit is gedefinieerd in host.json, targetUnprocessedEventThreshold wordt gebruikt als doeluitvoeringen per exemplaar in plaats van maxEventBatchSize, zoals in het volgende voorbeeld:

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

v3.x+

Wijzig voor v3.x+ van de Event Hubs-extensie de host.json instelling maxBatchSize onder eventProcessorOptions om doeluitvoeringen per exemplaar in te stellen:

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

Wanneer dit is gedefinieerd in host.json, targetUnprocessedEventThreshold wordt gebruikt als doeluitvoeringen per exemplaar in plaats van maxBatchSize, zoals in het volgende voorbeeld:

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

Opslagwachtrijen

Wijzig voor v2.x+ van de opslagextensie de host.json instelling batchSize om doeluitvoeringen per exemplaar in te stellen:

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

Notitie

Schaalefficiëntie: Voor de opslagwachtrijextensie worden berichten met visibilityTimeout nog steeds geteld in de lengte van de gebeurtenisbron door de Storage Queue-API's. Dit kan leiden tot een te grote schaalaanpassing van uw functie-app. Overweeg het gebruik van Service Bus-wachtrijen in wachtrijen voor geplande berichten, het beperken van uitschalen of het gebruik van visibilityTimeout voor uw oplossing.

Azure Cosmos DB

Azure Cosmos DB maakt gebruik van een kenmerk op functieniveau. MaxItemsPerInvocation De manier waarop u dit kenmerk op functieniveau instelt, is afhankelijk van uw functietaal.

C#

Stel voor een gecompileerde C#-functie in uw triggerdefinitie in, MaxItemsPerInvocation zoals wordt weergegeven in de volgende voorbeelden voor een in-process C#-functie:

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

Java-voorbeeld in behandeling.

Python

Voor Functions-talen die worden gebruikt function.json, wordt de MaxItemsPerInvocation parameter gedefinieerd in de specifieke binding, zoals in dit Azure Cosmos DB-triggervoorbeeld:

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

Voorbeelden voor het Python v2-programmeermodel zijn nog niet beschikbaar.

JavaScript/PowerShell/TypeScript

Voor Functions-talen die worden gebruikt function.json, wordt de MaxItemsPerInvocation parameter gedefinieerd in de specifieke binding, zoals in dit Azure Cosmos DB-triggervoorbeeld:

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

Voorbeelden voor het Node.js v4-programmeermodel zijn nog niet beschikbaar.

Notitie

Omdat Azure Cosmos DB een gepartitioneerde workload is, wordt het aantal doelexemplaren voor de database beperkt door het aantal fysieke partities in uw container. Zie fysieke partities en eigendom van leases voor meer informatie over schalen van Azure Cosmos DB.

Apache Kafka

De Apache Kafka-extensie maakt gebruik van een kenmerk op functieniveau. LagThreshold Voor Kafka wordt het aantal gewenste exemplaren berekend op basis van de totale consumentenvertraging gedeeld door de LagThreshold instelling. Voor een bepaalde vertraging verhoogt het verminderen van de vertragingsdrempel het aantal gewenste exemplaren.

De manier waarop u dit kenmerk op functieniveau instelt, is afhankelijk van uw functietaal. In dit voorbeeld wordt de drempelwaarde ingesteld op 100.

C#

Stel voor een gecompileerde C#-functie in uw triggerdefinitie in, LagThreshold zoals wordt weergegeven in de volgende voorbeelden voor een in-process C#-functie voor een Kafka Event Hubs-trigger:

[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

Voor Functions-talen die gebruikmaken function.json, wordt de LagThreshold parameter gedefinieerd in de specifieke binding, zoals in dit Kafka Event Hubs-triggervoorbeeld:

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

Het Python v2-programmeermodel wordt momenteel niet ondersteund door de Kafka-extensie.

JavaScript/PowerShell/TypeScript

Voor Functions-talen die gebruikmaken function.json, wordt de LagThreshold parameter gedefinieerd in de specifieke binding, zoals in dit Kafka Event Hubs-triggervoorbeeld:

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

Het Node.js v4-programmeermodel wordt momenteel niet ondersteund door de Kafka-extensie.

Volgende stappen

Zie de volgende artikelen voor meer informatie:

• De prestaties en betrouwbaarheid van Azure Functions verbeteren
• Betrouwbare gebeurtenisverwerking van Azure Functions