Ereignisgesteuerte Skalierung in Azure Functions

  • Artikel

In den Verbrauchs-, Flex-Verbrauchs- und Premium-Plänen skaliert Azure Functions Ressourcen, indem weitere Instanzen basierend auf der Anzahl der Ereignisse, die eine Funktion auslösen, hinzugefügt werden.

Wichtig

Der Flex-Verbrauchsplan befindet sich derzeit in der Vorschau.

Die Art und Weise, mit der Ihre Funktions-App skaliert wird, hängt vom Hostingplan ab:

  • Verbrauchsplan: Jede Instanz des Functions-Hosts im Verbrauchsplan ist in der Regel auf 1,5 GB Arbeitsspeicher und eine CPU beschränkt. Eine Instanz des Hosts unterstützt die gesamte Funktions-App. Daher werden alle Funktionen in einer Funktions-App-Freigaberessource in einer Instanz gleichzeitig skaliert. Wenn Funktions-Apps den gleichen Verbrauchsplan nutzen, werden sie weiterhin unabhängig skaliert.

  • Flex-Verbrauchsplan: Der Plan verwendet eine deterministische Skalierungsstrategie pro Funktion, bei der jede Funktion unabhängig skaliert wird. Ausgenommen sind von HTTP, Blob und Durable Functions ausgelöste Funktionen, die in ihren eigenen Gruppen skaliert werden. Weitere Informationen finden Sie unter Skalierung pro Funktion. Diese Instanzen werden dann basierend auf der Parallelität Ihrer Anforderungen skaliert.

  • Premium-Plan: Die jeweilige Größe des Premium-Plans bestimmt den verfügbaren Arbeitsspeicher und die verfügbare CPU für alle Apps in diesem Plan für diese 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.

Funktionscodedateien werden in Azure Files-Freigaben im Hauptspeicherkonto der Funktion gespeichert. Wenn Sie das Hauptspeicherkonto der Funktions-App löschen, werden die Funktionscodedateien gelöscht und können nicht wiederhergestellt werden.

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. Bei einer horizontalen Hochskalierung der Funktions-App werden zusätzliche Ressourcen zugeordnet, um mehrere Instanzen des Azure Functions-Hosts auszuführen. Umgekehrt entfernt der Skalierungscontroller bei abnehmenden Computeanforderungen Instanzen des Functions-Hosts. Die Anzahl von Instanzen wird schließlich „abskaliert“, wenn in einer Funktions-App keine Funktionen ausgeführt werden.

Skalierungscontroller: Überwachen von Ereignissen und Erstellen von Instanzen

Kaltstart

Sollte Ihre Funktions-App einige Minuten im Leerlauf sein, kann die Plattform entscheiden, die Anzahl der Instanzen, auf denen Ihre App ausgeführt wird, auf null zu skalieren. Bei der nächsten Anforderung kommt eine zusätzliche Latenz für die Skalierung von 0 auf 1 zum Tragen. Diese Latenz wird als Kaltstart bezeichnet. Die Anzahl von Abhängigkeiten, die für Ihre Funktions-App erforderlich sind, kann sich auf die Dauer des Kaltstarts auswirken. 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 nicht den Verbrauchsplan nutzen. Die anderen Pläne bieten die folgenden Strategien, um Kaltstarts zu minimieren oder auszuschließen:

  • Premium-Plan: Unterstützt vorgewärmte Instanzen und immer einsatzbereite Instanzen (mit mindestens einer Instanz).

  • Flex-Verbrauchsplan: Unterstützt eine optionale Anzahl von immer einsatzbereiten Instanzen, die pro Instanzskalierung definiert werden kann.

  • Dedizierter Plan: Der Plan selbst wird nicht dynamisch skaliert, aber Sie können Ihre App kontinuierlich mit aktivierter Einstellung Immer aktiviert ausführen.

Grundlegendes zum Verhalten von Skalierungen

Die Skalierung variiert ausgehend von verschiedenen Faktoren. Apps werden je nach Auswahl von Trigger und der Sprache unterschiedlich skaliert. Es gibt einige Feinheiten des Skalierungsverhaltens, die zu beachten sind:

  • Maximale Anzahl von Instanzen: Eine einzelne Funktions-App wird auf das vom Plan erlaubte Maximum skaliert. 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.
  • Rate für neue Instanzen: Bei HTTP-Triggern werden neue Instanzen höchstens einmal pro Sekunde zugeordnet. Bei Nicht-HTTP-Triggern werden neue Instanzen höchstens einmal alle 30 Sekunden zugeordnet. Die Skalierung ist schneller, wenn sie in einem Premium-Plan ausgeführt wird.
  • Zielbasierte Skalierung: Die zielbasierte Skalierung bietet ein schnelles und intuitives Skalierungsmodell für Kunden und wird derzeit 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. Auch alle Durable Functions-Trigger nutzen die gleichen Instanzen und werden gemeinsam skaliert. Weitere Informationen finden Sie unter Skalierung pro Funktion.
  • Maximal überwachte Trigger: Derzeit kann der Skalierungscontroller nur bis zu 100 Trigger überwachen, um Skalierungsentscheidungen zu treffen. Wenn Ihre App über mehr als 100 ereignisbasierte Trigger verfügt, werden Skalierungsentscheidungen nur basierend auf den ersten 100 Triggern getroffen, die ausgeführt werden. Weitere Informationen finden Sie unter Bewährte Methoden und Muster für skalierbare Apps.

Begrenzen der horizontalen Skalierung

Möglicherweise möchten Sie die Anzahl von Instanzen beschränken, die von einer App für die horizontale Skalierung verwendet werden kann. Dies ist am häufigsten der Fall, wenn der Durchsatz einer Downstreamkomponente wie einer Datenbank begrenzt ist. Informationen zu den maximalen Skalierungsgrenzen beim Ausführen der verschiedenen Hostingpläne finden Sie unter Skalierungsgrenzen.

Flex-Verbrauchsplan

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 40, 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.

Beachten Sie, dass Sie zwar die maximale Anzahl der Instanzen von Flex-Verbrauchs-Apps in einen Wert von bis zu 1.000 ändern können, aber Ihre Apps erreichen eine Kontingentgrenze, bevor Sie diese Zahl erreichen. 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 <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

Verbrauchs-/Premium-Pläne

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>

Horizontales Herunterskalieren

Die ereignisgesteuerte Skalierung reduziert automatisch die Kapazität, wenn die Nachfrage nach Ihren Funktionen sinkt. Dabei werden Instanzen der aktuellen Funktionsausführungen ausgeglichen und dann entfernt. Dieses Verhalten wird als Ausgleichsmodus protokolliert. Die Karenzzeit für Funktionen, die derzeit ausgeführt werden, kann bis zu 10 Minuten für Apps im Verbrauchsplan und bis zu 60 Minuten für Apps im Flex-Verbrauchs- oder Premium-Plan 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 unter Windows im Verbrauchstarif ausgeführt werden, ist nur für Apps, die nach Mai 2021 erstellt wurden, das Verhalten des Ausgleichsmodus 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

Gilt nur für den Flex-Verbrauchsplan (Vorschau).

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 in einem Flex-Verbrauchsplan mit diesen Funktionen:

function1 function2 function3 function4 function5 function6 function7
HTTP-Trigger HTTP-Trigger Orchestrierungstrigger (Durable) Aktivitätstrigger (Durable) Service Bus-Trigger Service Bus-Trigger Event Hubs-Trigger

In diesem Beispiel:

Bewährte Methoden und Muster für skalierbare Apps

Es gibt viele Aspekte einer Funktions-App, die sich auf die Skalierung auswirken. Dazu zählen beispielsweise die Hostkonfiguration, der Runtimespeicherbedarf und die 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 über mehr als 100 Funktionen verfügt, die ereignisbasierte Trigger verwenden, unterteilen Sie die App ggf. in eine oder mehrere Apps, wobei jede App weniger als 100 ereignisbasierte Funktionen aufweist.

Weitere Informationen zum Skalieren in Python und Node.js finden Sie unter Python-Entwicklerhandbuch für Azure Functions: Skalierung und Parallelität und Node.js-Entwicklerhandbuch für Azure Functions: Skalierung und Parallelität.

Nächste Schritte

Weitere Informationen erhalten Sie in den folgenden Artikeln: