Dela via


Målbaserad skalning

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.

I den här ekvationen refererar händelsekällans längd till antalet händelser som måste bearbetas. Standardvärdena för målexekveringar per instans kommer från de SDK:er (Software Development Kits) 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+, Enkel Dispatch Sessions-baserad) 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 (Funktioner v2.x+, Baseras på individuella avsändarsessioner) 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örningarna per instanskonfiguration 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 aktiverad hanterar tilläggen i sig själva den dynamiska skalningen. Detta 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ålutförandevärde per instans automatiskt av dynamisk samtidighetsfunktion. 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 skalningen till inkrementell skalning eftersom kö- eller ämneslängden inte kan användas för att fatta beslut om skalning. 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 i en lista över giltiga instansantal. Som standard är host.json attributen som används för maxEventBatchSize 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.

Skalningsbeteende och stabilitet

För Event Hubs kan frekventa in- och utskalningsåtgärder utlösa partitionsombalansering, vilket leder till bearbetningsfördröjningar och ökad svarstid. Så här åtgärdar du detta:

  • Plattformen använder en fördefinierad lista över giltiga antal arbetare för att vägleda skalningsbeslut.
  • Plattformen säkerställer att skalningen är stabil och avsiktlig och undviker störande ändringar i partitionstilldelningar.
  • Om det önskade antalet arbetare inte finns i den giltiga listan, till exempel 17, väljer systemet automatiskt det näst största giltiga antalet, vilket i det här fallet är 32. För att förhindra snabb upprepad skalning begränsas dessutom inskalningsbegäranden i 3 minuter efter den senaste uppskalningen. Den här fördröjningen bidrar till att minska onödig ombalansering och bidrar till att upprätthålla genomflödeseffektiviteten.

Giltiga instansantal för Event Hubs

För varje antal Event Hubs-partitioner beräknar vi en motsvarande lista över giltiga instansantal för att säkerställa optimal distribution och effektiv skalning. Dessa antal väljs för att passa bra med partitionerings- och samtidighetskrav:

Antal partitioner Antal giltiga instanser
1 [1]
2 [1, 2]
4 [1, 2, 4]
8 [1, 2, 3, 4, 8]
10 [1, 2, 3, 4, 5, 10]
16 [1, 2, 3, 4, 5, 6, 8, 16]
32 [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 16, 32]

Dessa fördefinierade antal hjälper till att säkerställa att instanser distribueras så jämnt som möjligt mellan partitioner, vilket minimerar inaktiva eller överbelastade arbetare.

Kommentar

Obs! För premium- och dedikerade händelsehubbnivåer kan partitionsantalet överskrida 32, vilket möjliggör större giltiga antal instansuppsättningar. De här nivåerna har stöd för högre dataflöde och skalbarhet, och listan över giltiga antal arbetare utökas i enlighet med detta för att fördela händelsehubbspartitioner jämnt mellan instanser. Eftersom Event Hubs är en partitionerad arbetsbelastning är antalet partitioner i händelsehubben gränsen för det maximala antalet målinstanser.

Inställningar för Event Hubs

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 host.jsontargetUnprocessedEventThresholdanvä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 är antalet fysiska partitioner i containern gränsen för antalet målinstanser. 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: