Ereignisgesteuerte Skalierung in Azure Functions

Ereignisgesteuerte Skalierung gilt nicht für den dedizierten (App Service)-Plan. Der dedizierte Plan skaliert nicht dynamisch basierend auf Ereignissen. Für Skalierungsoptionen im Dedicated Plan siehe Scale up an App in Azure App Service.

Ereignisgesteuerte Skalierung gilt nicht, wenn Funktionen in Azure Container Apps ausgeführt werden. Wenn sie auf Container Apps gehostet werden, wird die Skalierung von der Container Apps-Umgebung verwaltet. Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln in Azure Container Apps.

Laufzeitskalierung

Azure Functions verwendet die Komponente Skalierungscontroller, um die Rate der Ereignisse zu überwachen und zu bestimmen, ob eine horizontale Hoch- oder Herunterskalierung erforderlich ist. Der Skalierungscontroller verwendet Heuristik für jeden Triggertyp. Wenn Sie beispielsweise einen Azure Queue Storage-Trigger verwenden, wird die zielbasierte Skalierung verwendet.

Die Skalierungseinheit für Azure Functions ist die Funktions-App. Wenn die Funktions-App skaliert, werden mehr Ressourcen bereitgestellt, um mehrere Instanzen des Azure Functions-Hosts auszuführen. Umgekehrt entfernt der Scale Controller bei sinkendem Rechenbedarf die Funktionshost-Instanzen. Die Anzahl von Instanzen wird schließlich „abskaliert“, wenn in einer Funktions-App keine Funktionen ausgeführt werden.

Jede Instanz des Functions-Hosts im Consumption-Plan ist typischerweise auf 1,5 GB Speicher und eine CPU begrenzt. Eine Instanz des Hosts unterstützt die gesamte Funktions-App, sodass alle Funktionen in einer App Ressourcen teilen und gleichzeitig skalieren. Wenn Funktions-Apps denselben Konsumplan teilen, skalieren sie weiterhin unabhängig voneinander.

Die genaue Größe des Premium-Tarifs bestimmt den verfügbaren Speicher und die CPU für alle Apps in diesem Tarif in dieser Instanz. Der Plan skaliert seine Instanzen basierend auf den Skalierungsanforderungen der Apps im Plan auf, und die Apps werden nach Bedarf innerhalb des Plans skaliert.

Im Gegensatz zu den anderen dynamischen Plänen verwendet der Flex-Konsum-Plan ein deterministisches Skalierungsmodell pro Funktion. In diesem Modell wird jede Funktion unabhängig basierend auf der Anzahl der Ereignisse und Nebenläufigkeitseinstellungen skaliert, mit Ausnahme von HTTP-, Blob- und Orchestrierungsfunktionen (Durable), die in eigenen Gruppen skalieren. Weitere Informationen finden Sie unter Skalierung pro Funktion.

Die Plattform verwaltet die Rate , mit der sie Instanzen addiert (die Skalierungskurve), getrennt von der maximalen Instanzanzahl. Weitere Informationen zur Funktionsweise der Skalierungskurve, zum Throttling-Verhalten und bewährten Verfahren für Hochgeschwindigkeitsskalierung finden Sie unter Skalierungsrate (Scale-out rate).

Kaltstart

Wenn deine Funktions-App ein paar Minuten ungenutzt bleibt, könnte die Plattform die Anzahl der Instanzen, die deine App ausführen, auf null reduzieren. Die nächste Anfrage erlebt die zusätzliche Latenz durch Skalieren von null auf eins. Diese Latenz wird als Kaltstart bezeichnet. Die Anzahl der Abhängigkeiten, die Ihre Funktions-App benötigt, kann die Kaltstartzeit beeinflussen. Kaltstart ist eher ein Problem für synchrone Vorgänge, wie z. B. HTTP-Trigger, die eine Antwort zurückgeben müssen. Wenn Kaltstarts Ihre Funktionen beeinträchtigen, sollten Sie einen Plan in Betracht ziehen, der Strategien zur Minderung unterstützt:

Wie Sie in dieser Tabelle sehen können, bieten sowohl Flex Consumption- als auch Premium-Tarife Möglichkeiten, Kaltstarts in Ihren Apps zu vermeiden.

Grundlegendes zum Verhalten von Skalierungen

Die Skalierung kann von mehreren Faktoren abhängen. Apps skalieren unterschiedlich je nach Trigger und gewählter Sprache. Seien Sie sich dieser Feinheiten des Skalierungsverhaltens bewusst:

• Maximale Beispiele: Eine Single Function App wird auf ein Maximum ausgeweitet, das der Plan erlaubt. Eine einzelne Instanz kann jedoch mehrere Meldungen oder Anforderungen gleichzeitig verarbeiten. Sie können ein niedrigeres Maximum angeben, um die Skalierung nach Bedarf zu drosseln.

• Neue Instanzrate: Bei HTTP-Triggern weist die Plattform neue Instanzen höchstens einmal pro Sekunde zu. Bei Nicht-HTTP-Triggern weist die Plattform höchstens alle 30 Sekunden neue Instanzen zu. Die Skalierung ist schneller, wenn sie in einem Premium-Plan ausgeführt wird.

• Zielbasierte Skalierung: Zielbasierte Skalierung bietet ein schnelles und intuitives Skalierungsmodell für Kunden. Derzeit wird diese Skalierungsmethode für Service Bus-Warteschlangen und -Themen, Speicherwarteschlangen, Event Hubs, Apache Kafka und Azure Cosmos DB-Erweiterungen unterstützt. Informieren Sie sich über die zielbasierte Skalierung, um ihr Skalierungsverhalten zu verstehen.

• Skalierung pro Funktion: Mit einigen wichtigen Ausnahmen werden Funktionen, die im Flex-Verbrauchsplan ausgeführt werden, auf unabhängigen Instanzen skaliert. Zu den Ausnahmen gehören HTTP-Trigger und Blob Storage-Trigger (Event Grid). Jeder dieser Triggertypen wird auf den gleichen Instanzen als Gruppe skaliert. Ebenso nutzen die Trigger aller dauerhaften Funktionen Instanzen gemeinsam und skalieren zusammen. Weitere Informationen finden Sie unter Skalierung pro Funktion.

• Maximal überwachte Auslöser: Derzeit kann der Skalierungscontroller nur bis zu 100 Trigger überwachen, um Skalierungsentscheidungen zu treffen. Wenn Ihre App mehr als 100 ereignisbasierte Trigger hat, basieren Skalierungsentscheidungen nur auf den ersten 100 ausgeführten Triggern. Weitere Informationen finden Sie unter Bewährte Methoden und Muster für skalierbare Apps.

Begrenzen der horizontalen Skalierung

Sie können die maximale Anzahl von Instanzen einschränken, die eine App zum Skalieren verwenden kann. Diese Einschränkung gilt am häufigsten für Fälle, in denen eine nachgelagerte Komponente wie eine Datenbank einen begrenzten Durchsatz aufweist. Informationen zu den maximalen Skalierungsgrenzen beim Ausführen der verschiedenen Hostingpläne finden Sie unter Skalierungsgrenzen.

Standardmäßig weisen Apps, die in einem Flex-Verbrauchsplan ausgeführt werden, insgesamt maximal 100 Instanzen auf. Derzeit ist der niedrigste Maximalwert für die Instanzenanzahl 1, und der höchste unterstützte Maximalwert für die Instanzenanzahl ist 1000. Wenn Sie den Befehl az functionapp create verwenden, um eine Funktions-App im Flex-Verbrauchsplan zu erstellen, verwenden Sie den Parameter --maximum-instance-count, um diese maximale Instanzenanzahl für Ihre App festzulegen.

Die maximale Anzahl an Instanzen gilt für On-Demand-Instanzen in jeder Skalengruppe pro Funktion (Funktionsgruppe) und nicht für die kombinierten Instanzen der App. Always-Ready-Instanzen sind nicht durch die maximale Anzahl an Instanzen begrenzt und zählen auch nicht dazu.

Sie können zwar die maximale Anzahl von Flex Consumption-Apps auf bis zu 1000 ändern; das Kontingentlimit für Ihre Apps wird jedoch noch erreicht, bevor diese Zahl erreicht wird. Ausführlichere Informationen finden Sie unter Speicherkontingente für regionale Abonnements.

In diesem Beispiel wird eine App mit einer maximalen Instanzenanzahl von 200 erstellt:

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

In diesem Beispiel wird der Befehl az functionapp scale config set verwendet, um die maximale Instanzenanzahl für eine vorhandene App in 150 zu ändern:

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

In einem Verbrauchs- oder Elastic Premium-Plan können Sie einen niedrigeren Höchstwert für Ihre App angeben, indem Sie den Wert der Standortkonfigurationseinstellung functionAppScaleLimit ändern. Der functionAppScaleLimit-Wert kann auf 0 oder null festgelegt werden, wenn keine Einschränkungen erforderlich sind, oder auf einen gültigen Wert zwischen 1 und dem App-Maximum.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

Skalierungsrate

Im Flex Consumption-Plan verwaltet die Plattform auch die Rate , mit der sie Instanzen hinzufügt (die Skalierungskurve), getrennt von der maximalen Instanzanzahl. Wie die Skalierungskurve funktioniert, das Drosselverhalten und Best Practices für Hochgeschwindigkeitsskalierung finden Sie unter Skalierungsrate (Scale-out rate).

Skalierungsrate

In den Consumption- und Premium-Tarifen steuert der Scale-Controller die Geschwindigkeit, mit der neue Instanzen hinzugefügt werden. Bei HTTP-Triggern werden neue Instanzen höchstens einmal pro Sekunde zugeordnet. Bei Nicht-HTTP-Triggern werden neue Instanzen höchstens alle 30 Sekunden einmal zugewiesen. Die Skalierung ist schneller, wenn sie in einem Premium-Plan ausgeführt wird.

Horizontales Herunterskalieren

Die ereignisgesteuerte Skalierung reduziert automatisch die Kapazität, wenn die Nachfrage nach Ihren Funktionen sinkt. Bei der Reduzierung werden die aktuellen Funktionsausführungen in den Instanzen ausgeglichen und die Instanzen dann entfernt. Dieses Verhalten wird als Ausgleichsmodus protokolliert. Die Karenzzeit für Funktionen, die derzeit ausgeführt werden, kann für Apps im Verbrauchstarif bis zu 10 Minuten und für Apps im Verbrauch- und Premium-Tarif bis zu 60 Minuten betragen. Ereignisgesteuerte Skalierung und dieses Verhalten gelten nicht für Apps im Dedicated-Tarif.

Die folgenden Überlegungen gelten für horizontales Herunterskalieren:

• Bei Apps, die im Verbrauchstarif unter Windows ausgeführt werden, sind nur Apps, die nach Mai 2021 erstellt wurden, standardmäßig aktiviert.
• Verwenden Sie Version 4.2.0 oder eine neuere Version der Service Bus-Erweiterung, um ordnungsgemäßes Herunterfahren für Funktionen zu aktivieren, die den Service Bus-Trigger verwenden.

Skalierung pro Funktion

Der Flex-Verbrauchsplan ist einzigartig, da er das Verhalten Skalierung pro Funktion implementiert. Bei der Skalierung pro Funktion, mit Ausnahme von HTTP-Triggern, Blob-Triggern (Event Grid) und Durable Functions, werden alle anderen Funktionstriggertypen in Ihrer App auf unabhängigen Instanzen skaliert. HTTP-Trigger in Ihrer App werden zusammen als Gruppe auf den gleichen Instanzen skaliert. Dies gilt auch für alle Blob-Trigger (Event Grid) und alle Durable Functions, die über eigene freigegebene Instanzen verfügen.

Betrachten Sie eine Funktions-App, die von einem Flex Consumption-Plan gehostet wird, der die folgenden Funktionen umfasst:

In diesem Beispiel:

• Die beiden von HTTP ausgelösten Funktionen (function1 und function2) werden beide gemeinsam auf ihren eigenen Instanzen ausgeführt und entsprechend den HTTP-Parallelitätseinstellungen zusammen skaliert.
• Die beiden Durable Functions (function3 und function4) werden beide gemeinsam auf ihren eigenen Instanzen ausgeführt und basierend auf konfigurierten Parallelitätsdrosselungen zusammen skaliert.
• Die von Service Bus ausgelöste Funktion function5 wird auf ihrer eigenen Instanz ausgeführt und unabhängig nach den zielbasierten Skalierungsregeln für Service Bus-Warteschlangen und -Themen skaliert.
• Die von Service Bus ausgelöste Funktion function6 wird auf ihrer eigenen Instanz ausgeführt und unabhängig nach den zielbasierten Skalierungsregeln für Service Bus-Warteschlangen und -Themen skaliert.
• Der Event Hubs-Trigger (function7) wird auf eigenen Instanzen ausgeführt und unabhängig entsprechend den zielbasierten Skalierungsregeln für Event Hubs skaliert.

Bewährte Methoden und Muster für skalierbare Apps

Viele Aspekte einer Funktionsanwendung beeinflussen, wie sie skaliert, darunter Host-Konfiguration, Laufzeitaufwand und Ressourceneffizienz. Weitere Informationen finden Sie im Abschnitt zur Skalierbarkeit im Artikel zum Thema Leistung. Sie sollten auch das Verhalten von Verbindungen beim Skalieren Ihrer Funktions-App beachten. Weitere Informationen finden Sie unter How to manage connections in Azure Functions (Verwalten von Verbindungen in Azure Functions).

Wenn Ihre App mehr als 100 Funktionen mit ereignisbasierten Triggern hat, sollten Sie in Erwägung ziehen, die App in eine oder mehrere Apps aufzuteilen, wobei jede App weniger als 100 ereignisbasierte Funktionen hat.

Weitere Informationen zur Skalierung in Python und Node.jsfinden Sie im Abschnitt "Skalierung und Leistung " des Entwicklerhandbuchs für Azure Functions Python sowie im Abschnitt "Skalierung und Parallelität " des Entwicklerhandbuchs für Azure Functions Node.js.