Dela via

Målbaserad skalning

  • Artikel

Målbaserad skalning ger kunderna en snabb och intuitiv skalningsmodell och stöds för närvarande för dessa bindningstillägg:

Målbaserad skalning ersätter den tidigare inkrementella skalningsmodellen i Azure Functions som standard för dessa tilläggstyper. Inkrementell skalning har lagts till eller tagits bort som högst en arbetare vid varje ny instansfrekvens, med komplexa beslut om när du ska skala. Däremot tillåter målbaserad skalning uppskalning av fyra instanser i taget, och skalningsbeslutet baseras på en enkel målbaserad ekvation:

Bild av ekvationen: önskade instanser = händelsekällans längd/målkörningar per instans.

Standardvärdena för målkörningar per instans kommer från de SDK:er som används av Azure Functions-tilläggen. Du behöver inte göra några ändringar för att målbaserad skalning ska fungera.

Att tänka på

Följande överväganden gäller när du använder målbaserad skalning:

  • Målbaserad skalning är aktiverad som standard för funktionsappar i förbrukningsplanen, Flex Consumption-planen och Elastic Premium-abonnemangen. Händelsedriven skalning stöds inte när du kör dedikerade planer (App Service).
  • Målbaserad skalning är aktiverad som standard från och med version 4.19.0 av Functions-körningen.
  • När du använder målbaserad skalning respekteras fortfarande skalningsgränser. Mer information finns i Begränsa utskalning.
  • För att uppnå den mest exakta skalningen baserat på mått använder du bara en målbaserad utlöst funktion per funktionsapp. Du bör också överväga att köra i en Flex Consumption-plan som erbjuder skalning per funktion.
  • När flera funktioner i samma funktionsapp begär att skalas ut samtidigt används en summa för dessa funktioner för att fastställa ändringen i önskade instanser. Funktioner som begär att skala ut åsidosättningsfunktioner som begär att skalas in.
  • När det finns inskalningsbegäranden utan utskalningsbegäranden används den maximala skalningen i värdet.

Avregistrera dig

Målbaserad skalning är aktiverad som standard för funktionsappar som finns i en förbrukningsplan eller i ett Premium-abonnemang. Om du vill inaktivera målbaserad skalning och återgå till inkrementell skalning lägger du till följande appinställning i funktionsappen:

Programinställning Värde
TARGET_BASED_SCALING_ENABLED 0

Anpassa målbaserad skalning

Du kan göra skalningsbeteendet mer eller mindre aggressivt baserat på appens arbetsbelastning genom att justera målkörningar per instans. Varje tillägg har olika inställningar som du kan använda för att ange målkörningar per instans.

Den här tabellen sammanfattar de host.json värden som används för målkörningarna per instansvärden och standardvärdena:

Anknytning host.json värden Standardvärde
Event Hubs (tillägg v5.x+) extensions.eventHubs.maxEventBatchSize 100*
Event Hubs (tillägg v3.x+) extensions.eventHubs.eventProcessorOptions.maxBatchSize 10
Event Hubs (om det definieras) extensions.eventHubs.targetUnprocessedEventThreshold saknas
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 (tillägg v5.x+, batchbearbetning) extensions.serviceBus.maxMessageBatchSize 1000
Service Bus (Functions v2.x+, Single Dispatch) extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls 16
Service Bus (Functions v2.x+, Single Dispatch Sessions Based) extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions 2000
Service Bus (Functions v2.x+, Batch Processing) extensions.serviceBus.batchOptions.maxMessageCount 1000
Lagringskö extensions.queues.batchSize 16

* Standardvärdet maxEventBatchSize ändrades i v6.0.0 i Microsoft.Azure.WebJobs.Extensions.EventHubs paketet. I tidigare versioner var det här värdet 10.

För vissa bindningstillägg anges målkörningar per instans med hjälp av ett funktionsattribut:

Anknytning Inställning för funktionsutlösare Standardvärde
Apache Kafka lagThreshold 1000
Azure Cosmos DB maxItemsPerInvocation 100

Mer information finns i exempelkonfigurationerna för tillägg som stöds.

Premium-plan med körningsskalningsövervakning aktiverat

När körningsskalningsövervakning är aktiverat hanterar själva tilläggen dynamisk skalning. Det beror på att skalningskontrollanten inte har åtkomst till tjänster som skyddas av ett virtuellt nätverk. När du har aktiverat körningsskalningsövervakning måste du uppgradera tilläggspaketen till de här lägsta versionerna för att låsa upp de extra målbaserade skalningsfunktionerna:

Tilläggets namn Lägsta version som krävs
Apache Kafka 3.9.0
Azure Cosmos DB 4.1.0
Event Hubs 5.2.0
Service Bus 5.9.0
Lagringskö 5.1.0

Stöd för dynamisk samtidighet

Målbaserad skalning ger snabbare skalning och använder standardvärden för målkörningar per instans. När du använder Service Bus, Lagringsköer eller Kafka kan du också aktivera dynamisk samtidighet. I den här konfigurationen bestäms målkörningarna per instansvärde automatiskt av funktionen för dynamisk samtidighet. Den börjar med begränsad samtidighet och identifierar den bästa inställningen över tid.

Tillägg som stöds

Hur du konfigurerar målbaserad skalning i din host.json-fil beror på den specifika tilläggstypen. Det här avsnittet innehåller konfigurationsinformation för de tillägg som för närvarande stöder målbaserad skalning.

Service Bus-köer och -ämnen

Service Bus-tillägget stöder tre körningsmodeller som bestäms av attributen IsBatched och IsSessionsEnabled för Din Service Bus-utlösare. Standardvärdet för IsBatched och IsSessionsEnabled är false.

Körningsmodell IsBatched IsSessionsEnabled Inställning som används för målkörningar per instans
Bearbetning av enskild sändning falskt falskt maxConcurrentCalls
Bearbetning av enskild sändning (sessionsbaserad) falskt true maxConcurrentSessions
Batchbearbetning true falskt maxMessageBatchSize eller maxMessageCount

Kommentar

Skalningseffektivitet: För Service Bus-tillägget använder du Hantera behörigheter för resurser för den mest effektiva skalningen. Med lyssningsrättigheter återgår skalning till inkrementell skala eftersom kön eller ämneslängden inte kan användas för att informera skalningsbeslut. Mer information om hur du anger rättigheter i Service Bus-åtkomstprinciper finns i Auktoriseringsprincip för delad åtkomst.

Bearbetning av enskild sändning

I den här modellen bearbetar varje anrop av funktionen ett enda meddelande. Inställningen maxConcurrentCalls styr målkörningar per instans. Den specifika inställningen beror på versionen av Service Bus-tillägget.

Ändra inställningen host.jsonmaxConcurrentCalls, som i följande exempel:

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

Bearbetning av enskild sändning (sessionsbaserad)

I den här modellen bearbetar varje anrop av funktionen ett enda meddelande. Beroende på antalet aktiva sessioner för ditt Service Bus-ämne eller din kö hyr varje instans dock en eller flera sessioner. Den specifika inställningen beror på versionen av Service Bus-tillägget.

Ändra inställningen host.jsonmaxConcurrentSessions för att ange målkörningar per instans, som i följande exempel:

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

Batchbearbetning

I den här modellen bearbetar varje anrop av funktionen en uppsättning meddelanden. Den specifika inställningen beror på versionen av Service Bus-tillägget.

Ändra inställningen host.jsonmaxMessageBatchSize för att ange målkörningar per instans, som i följande exempel:

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

Event Hubs

För Azure Event Hubs skalar Azure Functions baserat på antalet obearbetade händelser som distribueras över alla partitioner i händelsehubben. Som standard är maxEventBatchSize attributen host.json som används för målkörningar per instans och maxBatchSize. Men om du väljer att finjustera målbaserad skalning kan du definiera en separat parameter targetUnprocessedEventThreshold som åsidosätter för att ange målkörningar per instans utan att ändra batchinställningarna. Om targetUnprocessedEventThreshold anges divideras det totala antalet obearbetade händelser med det här värdet för att fastställa antalet instanser, som sedan avrundas upp till ett antal arbetsinstanser som skapar en balanserad partitionsdistribution.

Kommentar

Eftersom Event Hubs är en partitionerad arbetsbelastning begränsas antalet målinstanser för Event Hubs av antalet partitioner i händelsehubben.

Den specifika inställningen beror på versionen av Event Hubs-tillägget.

Ändra inställningen host.jsonmaxEventBatchSize för att ange målkörningar per instans, som i följande exempel:

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

När det definieras i targetUnprocessedEventThresholdhost.jsonanvänds som målkörningar per instans i stället för maxEventBatchSize, som i följande exempel:

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

Lagringsköer

För v2.x+ för Lagringstillägget ändrar du host.json inställningen batchSize för att ange målkörningar per instans:

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

Kommentar

Skalningseffektivitet: För lagringskötillägget räknas meddelanden med synlighetTimeout fortfarande i händelsekällans längd av API:erna för lagringskö. Detta kan orsaka överskalning av funktionsappen. Överväg att använda Service Bus-köer för schemalagda meddelanden, begränsa utskalning eller inte använda synlighetTimeout för din lösning.

Azure Cosmos DB

Azure Cosmos DB använder ett attribut på funktionsnivå, MaxItemsPerInvocation. Hur du anger det här attributet på funktionsnivå beror på ditt funktionsspråk.

För en kompilerad C#-funktion anger du MaxItemsPerInvocation i utlösardefinitionen enligt följande exempel för en processbaserad C#-funktion:

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

Kommentar

Eftersom Azure Cosmos DB är en partitionerad arbetsbelastning begränsas antalet målinstanser för databasen av antalet fysiska partitioner i containern. Mer information om Azure Cosmos DB-skalning finns i fysiska partitioner och ägarskap för lån.

Apache Kafka

Apache Kafka-tillägget använder ett attribut på funktionsnivå, LagThreshold. För Kafka beräknas antalet önskade instanser baserat på den totala konsumentfördröjningen LagThreshold dividerat med inställningen. För en viss fördröjning ökar sänkningen av fördröjningströskeln antalet önskade instanser.

Hur du anger det här attributet på funktionsnivå beror på ditt funktionsspråk. I det här exemplet anges tröskelvärdet till 100.

För en kompilerad C#-funktion anger du LagThreshold i utlösardefinitionen, enligt följande exempel för en processbaserad C#-funktion för en Kafka Event Hubs-utlösare:

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

Nästa steg

Mer information finns i följande artiklar: