Ereignisgesteuerte Skalierung in Azure Functions

In den Verbrauchs- und Premium-Plänen skaliert Azure Functions CPU- und Arbeitsspeicherressourcen, indem weitere Instanzen des Functions-Hosts hinzugefügt werden. Die Anzahl von Instanzen wird anhand der Anzahl der Ereignisse bestimmt, die eine Funktion auslösen.

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 ist die gesamte Funktions-App, d. h., alle Funktionen innerhalb einer Funktions-App verwenden innerhalb einer Instanz dieselbe Ressource und werden gleichzeitig skaliert. Funktions-Apps, die denselben Verbrauchsplan nutzen, werden unabhängig voneinander skaliert. Im Premium-Plan bestimmt die Plangröße den verfügbaren Arbeitsspeicher und die verfügbare CPU für alle Apps in diesem Plan für diese Instanz.

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.

Scale controller monitoring events and creating instances

Kaltstart

Wenn sich Ihre Funktions-App einige Minuten im Leerlauf befunden hat, skaliert die Plattform möglicherweise die Anzahl von Instanzen, auf denen Ihre App ausgeführt wird, auf 0. 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 die Ausführung in einem Premium-Plan oder einem Dedicated-Plan, für den die Always-On-Einstellung aktiviert ist, in Erwägung ziehen.

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 mehrere Meldungen oder Anforderungen gleichzeitig verarbeiten, weshalb es keine Grenze für die Anzahl gleichzeitiger Ausführungen gibt. 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 und Cosmos DB-Erweiterungen unterstützt. Informieren Sie sich über die zielbasierte Skalierung, um ihr Skalierungsverhalten zu verstehen.

Begrenzen der horizontalen Skalierung

Möglicherweise möchten Sie die maximale Anzahl von Instanzen begrenzen, die eine App zum Hochskalieren verwendet. Dies ist am häufigsten in Fällen der Fall, in denen eine nachgelagerte Komponente wie eine Datenbank einen begrenzten Durchsatz hat. Standardmäßig werden die Funktionen des Verbrauchsplans auf bis zu 200 Instanzen aufskaliert, und Premium-Planfunktionen werden auf bis zu 100 Instanzen aufskaliert. Sie können einen niedrigeren Höchstwert für eine bestimmte App angeben, indem Sie den functionAppScaleLimit-Wert ä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. Dazu werden Instanzen ihrer aktuellen Funktionsausführungen entwässert und diese Instanzen entfernt. Dieses Verhalten wird als Ausgleichsmodus protokolliert. Die Karenzzeit für Funktionen, die derzeit ausgeführt werden, kann bis zu 10 Minuten für Verbrauchsplan-Apps und bis zu 60 Minuten für Premium-Plan-Apps verlängern. Ereignisgesteuerte Skalierung und dieses Verhalten gelten nicht für Apps im Dedicated-Tarif.

Die folgenden Überlegungen gelten für horizontales Herunterskalieren:

  • Bei Funktions-Apps im Verbrauchstarif, die 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.

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).

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.

Abrechnungsmodell

Die Abrechnung für die verschiedenen Pläne ist detailliert auf der Preisseite für Azure Functions beschrieben. Der Verbrauch wird auf Ebene der Funktions-App zusammengefasst, wobei nur die Zeit gezählt wird, für die der Funktionscode ausführt wurde. Folgende Einheiten werden für die Abrechnung verwendet:

  • Ressourcenverbrauch in Gigabytesekunden (GB-s) – berechnet als Kombination aus Arbeitsspeichergröße und Ausführungsdauer für alle Funktionen in einer Funktions-App.
  • Ausführungen – werden bei jeder Ausführung einer Funktion als Antwort auf einen Ereignisauslöser gezählt.

Nützliche Fragen und Informationen zum Verständnis Ihrer Verbrauchsrechnung finden Sie in den häufig gestellten Fragen zur Abrechnung.

Nächste Schritte

Weitere Informationen erhalten Sie in den folgenden Artikeln: