Zielbasierte Skalierung

  • Artikel

Zielbasierte Skalierung bietet ein schnelles und intuitives Skalierungsmodell für Kunden und wird derzeit für die folgenden Erweiterungen unterstützt:

Zielbasierte Skalierung ersetzt das vorherige inkrementelle Skalierungsmodell von Azure Functions als Standard für diese Erweiterungstypen. Inkrementelle Skalierung hat maximal einen Worker bei jeder neuen Instanzrate mit komplexen Entscheidungen bezüglich der Skalierung hinzugefügt oder entfernt. Im Gegensatz dazu ermöglicht zielbasierte Skalierung das gleichzeitige Hochskalieren von vier Instanzen, und die Skalierungsentscheidung basiert auf einer einfachen zielbasierten Gleichung:

Illustration of the equation: desired instances = event source length / target executions per instance.

Die Standardwerte für Zielausführungen pro Instanz stammen aus den SDKs, die von den Azure Functions-Erweiterungen verwendet werden. Sie müssen keine Änderungen vornehmen, damit zielbasierte Skalierung funktioniert.

Überlegungen

Berücksichtigen Sie Folgendes, wenn Sie zielbasierte Skalierung verwenden:

  • Die zielbasierte Skalierung ist standardmäßig für Funktions-Apps im Verbrauchsplan oder für Premium-Pläne aktiviert, sie können sich jedoch abmelden. Die ereignisgesteuerte Skalierung wird bei der Ausführung in dedizierten Plänen (App Service) nicht unterstützt.
  • Die zielbasierte Skalierung ist bei Funktions-App Runtime 4.19.0 oder einer späteren Version standardmäßig aktiviert.
  • Bei Verwendung der zielbasierten Skalierung wird die Standorteinstellung für functionAppScaleLimit weiterhin berücksichtigt. Weitere Informationen finden Sie unter Begrenzen des horizontalen Hochskalierens.
  • Um eine möglichst genaue Skalierung basierend auf Metriken zu erzielen, verwenden Sie nur eine zielbasierte ausgelöste Funktion pro Funktions-App.
  • Wenn mehrere Funktionen in derselben Funktions-App gleichzeitig eine horizontale Skalierung anfordern, wird eine Summe für diese Funktionen verwendet, um die Änderung in den gewünschten Instanzen zu bestimmen. Funktionen, die das Aufskalieren anfordern, setzen Funktionen außer Kraft, die das Abskalieren anfordern.
  • Wenn keine Anforderung zum horizontalen Herunterskalieren vorhanden ist, Anforderungen jedoch horizontal skaliert werden, wird der Wert für das maximale Herunterskalieren verwendet.

Deaktivieren

Die zielbasierte Skalierung ist standardmäßig für Funktions-Apps aktiviert, die in einem Verbrauchsplan oder in Premium-Plänen gehostet werden. Um zielbasierte Skalierung zu deaktivieren und erneut inkrementelle Skalierung zu verwenden, fügen Sie der Funktions-App die folgende App-Einstellung hinzu:

App-Einstellung Wert
TARGET_BASED_SCALING_ENABLED 0

Anpassen von zielbasierter Skalierung

Sie können das Skalierungsverhalten basierend auf der Workload Ihrer App mehr oder weniger aggressiv gestalten, indem Sie die Zielausführungen pro Instanz anpassen. Jede Erweiterung verfügt über unterschiedliche Einstellungen, mit denen Sie die Zielausführungen pro Instanz festlegen können.

In dieser Tabelle werden die host.json-Werte zusammengefasst, die für die Zielausführungen pro Instanz und verwendet werden, sowie die Standardwerte:

Durchwahl host.json-Werte Standardwert
Event Hubs (Erweiterung v5.x oder höher) extensions.eventHubs.maxEventBatchSize 100*
Event Hubs (Erweiterung v3.x oder höher) extensions.eventHubs.eventProcessorOptions.maxBatchSize 10
Event Hubs (sofern definiert) extensions.eventHubs.targetUnprocessedEventThreshold –
Service Bus (Erweiterung v5.x oder höher, Single Dispatch) extensions.serviceBus.maxConcurrentCalls 16
Service Bus (Erweiterung v5.x oder höher, sitzungsbasiert) extensions.serviceBus.maxConcurrentSessions 8
Service Bus (Erweiterung v5.x oder höher, Batchverarbeitung) extensions.serviceBus.maxMessageBatchSize 1000
Service Bus (Functions v2.x oder höher, Single Dispatch) extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls 16
Service Bus (Functions v2.x oder höher, Single Dispatch, sitzungsbasiert) extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions 2000
Service Bus (Functions v2.x oder höher, Batchverarbeitung) extensions.serviceBus.batchOptions.maxMessageCount 1.000
Speicherwarteschlange extensions.queues.batchSize 16

* Der Standardwert maxEventBatchSize wurde in Version 6.0.0 des Pakets Microsoft.Azure.WebJobs.Extensions.EventHubs geändert. In früheren Versionen war dieser Wert 10.

Bei einigen Bindungserweiterungen wird die Zielausführung pro Instanz mithilfe eines Funktionsattributes festgelegt:

Erweiterung Funktionstriggereinstellung Standardwert
Apache Kafka lagThreshold 1.000
Azure Cosmos DB maxItemsPerInvocation 100

Weitere Informationen finden Sie in den Beispielkonfigurationen für die unterstützten Erweiterungen.

Premium-Plan mit aktivierter Überwachung von Laufzeitskalierung

Wenn die Überwachung der Laufzeitskalierung aktiviert ist, verarbeiten die Erweiterungen selbst die dynamische Skalierung. Dies liegt daran, dass der Skalierungscontroller keinen Zugriff auf Dienste hat, die durch ein virtuelles Netzwerk geschützt sind. Nachdem Sie die Überwachung der Laufzeitskalierung aktiviert haben, müssen Sie Ihre Erweiterungspakete auf diese Mindestversionen aktualisieren, um die zusätzliche zielbasierte Skalierungsfunktionalität zu entsperren:

Name der Erweiterung Erforderliche Mindestversion
Apache Kafka 3.9.0
Azure Cosmos DB 4.1.0
Event Hubs 5.2.0
Service Bus 5.9.0
Speicherwarteschlange 5.1.0

Unterstützung für dynamische Parallelität

Zielbasierte Skalierung führt zu einer schnelleren Skalierung und verwendet Standardwerte für Zielausführungen pro Instanz. Wenn Sie Service Bus, Storage-Warteschlangen oder Kafka verwenden, können Sie auch dynamische Parallelität aktivieren. In dieser Konfiguration wird der Wert für Zielausführungen pro Instanz automatisch durch das Feature für dynamische Parallelität bestimmt. Begonnen wird mit eingeschränkter Parallelität, dann wird im Laufe der Zeit die beste Einstellung identifiziert.

Unterstützte Erweiterungen

Wie Sie zielbasierte Skalierung in der Datei „host.json“ konfigurieren, hängt vom jeweiligen Erweiterungstyp ab. Dieser Abschnitt enthält die Konfigurationsdetails für die Erweiterungen, die derzeit zielbasierte Skalierung unterstützen.

Service Bus-Warteschlangen und -Themen

Die Service Bus-Erweiterung unterstützt drei Ausführungsmodelle, die durch die IsBatched- und IsSessionsEnabled-Attribute ihres Service Bus-Triggers bestimmt werden. Der Standardwert für IsBatched und IsSessionsEnabled ist false.

Ausführungsmodell IsBatched IsSessionsEnabled Für Zielausführungen pro Instanz verwendete Einstellung
Single Dispatch-Verarbeitung false false maxConcurrentCalls
Single Dispatch-Verarbeitung (sitzungsbasiert) false true maxConcurrentSessions
Batchverarbeitung true false maxMessageBatchSize or maxMessageCount

Hinweis

Skalierungseffizienz: Verwenden Sie für die Service Bus-Erweiterung Verwaltungsrechte für Ressourcen, um eine möglichst effiziente Skalierung zu erreichen. Mit Lauschrechten wird die Skalierung auf inkrementelle Skalierung zurückgesetzt, weil die Länge der Warteschlange oder des Themas nicht in Skalierungsentscheidungen einbezogen werden kann. Weitere Informationen zum Festlegen von Berechtigungen in Service Bus-Zugriffsrichtlinien finden Sie unter SAS-Autorisierungsrichtlinien.

Single Dispatch-Verarbeitung

In diesem Modell verarbeitet jeder Aufruf Ihrer Funktion eine einzelne Nachricht. Die maxConcurrentCalls-Einstellung steuert die Zielausführungen pro Instanz. Die spezifische Einstellung hängt von der Version der Service Bus-Erweiterung ab.

Ändern Sie die host.json-Einstellung maxConcurrentCalls wie im folgenden Beispiel gezeigt:

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

Single Dispatch-Verarbeitung (sitzungsbasiert)

In diesem Modell verarbeitet jeder Aufruf Ihrer Funktion eine einzelne Nachricht. Abhängig von der Anzahl der aktiven Sitzungen für Ihr Service Bus-Thema bzw. Ihre -Warteschlange least jede Instanz jedoch mindestens eine Sitzung. Die spezifische Einstellung hängt von der Version der Service Bus-Erweiterung ab.

Ändern Sie die host.json-Einstellung maxConcurrentSessions, um Zielausführungen pro Instanz festzulegen, wie im folgenden Beispiel gezeigt:

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

Batchverarbeitung

In diesem Modell verarbeitet jeder Aufruf Ihrer Funktion einen Batch von Nachrichten. Die spezifische Einstellung hängt von der Version der Service Bus-Erweiterung ab.

Ändern Sie die host.json-Einstellung maxMessageBatchSize, um Zielausführungen pro Instanz festzulegen, wie im folgenden Beispiel gezeigt:

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

Event Hubs

Für Azure Event Hubs wird Azure Functions basierend auf der Anzahl der nicht verarbeiteten Ereignisse skaliert, die auf alle Partitionen im Event Hub verteilt sind. Standardmäßig sind die für Zielausführungen pro Instanz verwendeten host.json-Attribute maxEventBatchSize und maxBatchSize. Wenn Sie sich jedoch dafür entscheiden, zielbasierte Skalierung zu optimieren, können Sie einen separaten Parameter targetUnprocessedEventThreshold definieren, der ein Überschreibung vornimmt, um Zielausführungen pro Instanz festzulegen, ohne die Batcheinstellungen zu ändern. Wenn targetUnprocessedEventThreshold festgelegt ist, wird die Gesamtzahl der unverarbeiteten Ereignisse durch diesen Wert geteilt, um die Anzahl der Instanzen zu bestimmen, die auf eine Anzahl von Workerinstanzen aufgerundet wird, die eine ausgewogene Partitionsverteilung ergibt.

Hinweis

Da es sich bei Event Hubs um eine partitionierte Workload handelt, wird die Anzahl der Zielinstanzen für Event Hubs durch die Anzahl der Partitionen in Ihrem Event Hub begrenzt.

Die spezifische Einstellung hängt von der Version der Event Hubs-Erweiterung ab.

Ändern Sie die host.json-Einstellung maxEventBatchSize, um Zielausführungen pro Instanz festzulegen, wie im folgenden Beispiel gezeigt:

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

Wenn in host.json definiert, wird targetUnprocessedEventThreshold als Zielausführungen pro Instanz anstelle von maxEventBatchSize verwendet, wie im folgenden Beispiel gezeigt:

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

Storage-Warteschlangen

Ändern Sie für v2.x oder höher der Speichererweiterung die host.json-Einstellung batchSize, um Zielausführungen pro Instanz festzulegen:

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

Hinweis

Skalierungseffizienz: Für die Speicherwarteschlangenerweiterung werden Nachrichten mit visibilityTimeout weiterhin von den Speicherwarteschlangen-APIs in der Länge der Ereignisquelle gezählt. Dies kann zu einer Überskalierung Ihrer Funktions-App führen. Erwägen Sie die Verwendung von Service Bus-Warteschlangen mit geplanten Nachrichten, das Einschränken der horizontalen Skalierung oder die Verwendung von visibilityTimeout für Ihre Lösung.

Azure Cosmos DB

Azure Cosmos DB verwendet ein Attribut auf Funktionsebene: MaxItemsPerInvocation. Wie Sie dieses Attribut auf Funktionsebene festlegen, hängt von Ihrer Funktionssprache ab.

Legen Sie für eine kompilierte C#-Funktion in Ihrer Triggerdefinition MaxItemsPerInvocation fest, wie in den folgenden Beispielen für eine prozessinterne C#-Funktion gezeigt:

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

Hinweis

Da es sich bei Azure Cosmos DB um eine partitionierte Workload handelt, wird die Anzahl der Zielinstanzen für die Datenbank durch die Anzahl der physischen Partitionen in Ihrem Container begrenzt. Weitere Informationen zur Skalierung von Azure Cosmos DB finden Sie unter physische Partitionen und Leasebesitz.

Apache Kafka

Die Apache Kafka-Erweiterung verwendet ein Attribut auf Funktionsebene: LagThreshold. Bei Kafka wird die Anzahl der gewünschten Instanzen basierend auf der Gesamtverzögerung der Consumer dividiert durch die LagThreshold-Einstellung berechnet. Bei einer bestimmten Verzögerung erhöht die Verringerung der Verzögerungsschwelle die Anzahl der gewünschten Instanzen.

Wie Sie dieses Attribut auf Funktionsebene festlegen, hängt von Ihrer Funktionssprache ab. In diesem Beispiel wird der Schwellenwert auf 100 festgelegt.

Legen Sie für eine kompilierte C#-Funktion in Ihrer Triggerdefinition LagThreshold fest, wie in den folgenden Beispielen für eine prozessinterne C#-Funktion für einen Kafka-Event Hubs-Trigger gezeigt:

[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ächste Schritte

Weitere Informationen erhalten Sie in den folgenden Artikeln: