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 standaarddoeluitvoeringen per exemplaar zijn afkomstig van de SDK's (Software Development Kits) 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:

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:

^* 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 de doeluitvoeringen per exemplaar ingesteld met behulp van een functie-attribuut:

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 dynamische schaalaanpassing omdat de schaalcontroller geen toegang heeft tot services die zijn 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:

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 wordt de _target uitvoering 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.

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.

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

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

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

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

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

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

Event Hubs

Voor Azure Event Hubs schaalt Azure Functions op basis van het aantal niet-verwerkte gebeurtenissen dat is verdeeld over alle partities in de Event Hub binnen een lijst met een aantal geldige instanties. Standaard zijn host.json de kenmerken die worden gebruikt voor maxEventBatchSize 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.

Schaalgedrag en stabiliteit

Voor Event Hubs kunnen frequente in- en uitschaalbewerkingen partitieherverdeling activeren, wat leidt tot verwerkingsvertragingen en verhoogde latentie. U kunt dit als volgt verhelpen:

• Het platform maakt gebruik van een vooraf gedefinieerde lijst met geldige werkrollen om beslissingen over schaalaanpassing te begeleiden.
• Het platform zorgt ervoor dat schalen stabiel en opzettelijk is, waardoor verstorende wijzigingen in partitietoewijzingen worden vermeden.
• Als het gewenste aantal werknemers zich niet in de geldige lijst bevindt, bijvoorbeeld 17, selecteert het systeem automatisch het dichtstbijzijnde grotere geldige aantal, dat in dit geval 32 is. Om snelle herhaalde schaalaanpassingen te voorkomen, worden afschalingsverzoeken 3 minuten vertraagd na de laatste schaalvergroting. Deze vertraging helpt onnodige herverdeling te verminderen en draagt bij aan het handhaven van de doorvoerefficiëntie.

Geldige aantal exemplaren voor Event Hubs

Voor ieder Event Hubs-partitieaantal berekenen we een bijbehorende lijst met geldige instantieaantallen om een optimale verdeling en efficiënte schaalbaarheid te garanderen. Deze aantallen worden gekozen om goed af te stemmen op de vereisten voor partitionering en gelijktijdigheid:

Deze vooraf gedefinieerde aantallen helpen om ervoor te zorgen dat instanties zo gelijkmatig mogelijk worden verdeeld over partities, waardoor niet-actieve of overbelaste werkers worden geminimaliseerd.

Event Hubs-instellingen

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

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

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

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.

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

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.

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

Volgende stappen

Zie de volgende artikelen voor meer informatie:

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