Ereignisgesteuerte Skalierung in Azure Functions

In den Verbrauchs- und Premium-Plänen skaliert Azure Functions CPU- und Arbeitsspeicherressourcen, indem zusätzliche 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 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 Auf- oder Abskalierung erforderlich ist. Der Skalierungscontroller verwendet Heuristik für jeden Triggertyp. Bei Verwendung eines Triggers für Azure Queue Storage beispielsweise basieren die Skalen auf der Länge der Warteschlange und dem Alter der ältesten Nachricht in der Warteschlange.

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 auf null 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 mit aktivierter Always-On-Einstellung in Erwägung ziehen.

Grundlegendes zum Verhalten von Skalierungen

Die Skalierung variiert ausgehend von verschiedenen Faktoren, und die Skalierung ist je nach dem ausgewählten Auslöser und der Sprache unterschiedlich. Es gibt einige Feinheiten des Skalierungsverhaltens, die zu beachten sind:

  • Maximale Anzahl von Instanzen: Eine einzelne Funktions-App wird maximal auf 200 Instanzen erweitert. 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.
  • Skalierungseffizienz: Verwenden Sie für Service Bus-Trigger Verwaltungsrechte für Ressourcen, um eine möglichst effiziente Skalierung zu erreichen. Mit Lauschrechten ist die Skalierung unpräziser, da die Warteschlangenlänge nicht in Skalierungsentscheidungen einbezogen werden kann. Weitere Informationen zum Festlegen von Berechtigungen in Service Bus-Zugriffsrichtlinien finden Sie unter SAS-Autorisierungsrichtlinien. Informationen zu Event Hub-Triggern finden Sie in diesem Leitfaden zur Skalierung.

Begrenzen des horizontalen Hochskalierens

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>
$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

Event Hubs-Trigger

In diesem Abschnitt wird beschrieben, wie sich die Skalierung verhält, wenn Ihre Funktion einen Event Hubs-Trigger oder einen IoT Hub Trigger verwendet. In solchen Fällen wird jede Instanz einer durch ein Ereignis ausgelösten Funktion durch eine einzelne EventProcessorHost-Instanz gesichert. Der (auf Event Hubs basierende) Trigger stellt sicher, dass nur eine EventProcessorHost-Instanz eine Lease für eine bestimmte Partition erhalten kann.

Stellen Sie sich einen Event Hub wie folgt vor:

  • 10 Partitionen
  • 1\.000 gleichmäßig auf alle Partitionen verteilte Ereignisse mit 100 Nachrichten in jeder Partition

Wenn Ihre Funktion zuerst aktiviert wird, gibt es nur eine Instanz der Funktion. Wir nennen die erste Funktionsinstanz Function_0. Die Function_0-Funktion umfasst eine einzelne Instanz von EventProcessorHost mit einer Lease auf allen zehn Partitionen. Diese Instanz beginnt mit dem Lesen von Ereignissen von den Partitionen 0-9. Von diesem Punkt an wird eines der folgenden Ereignisse eintreten:

  • Es sind keine neuen Funktionsinstanzen erforderlich:Function_0 kann alle 1.000 Ereignisse verarbeiten, bevor die Skalierungslogik von Functions einsetzt. In diesem Fall werden alle 1.000 Nachrichten von Function_0 verarbeitet.

  • Eine weitere Funktionsinstanz wird hinzugefügt: Wenn die Functions-Skalierungslogik bestimmt, dass Function_0 mehr Nachrichten enthält, als verarbeitet werden können, wird eine neue Funktions-App-Instanz (Function_1) erstellt. Diese neue Funktion umfasst auch eine zugeordnete Instanz von EventProcessorHost. Wenn die zugrunde liegende Event Hubs-Instanz erkennt, dass eine neue Hostinstanz versucht, Nachrichten zu lesen, wird ein Lastenausgleich der Partitionen in den Hostinstanzen vorgenommen. Zum Beispiel können die Partitionen 0-4 Function_0 und die Partitionen 5-9 Function_1 zugewiesen werden.

  • N weitere Funktionsinstanzen werden hinzufügt: Wenn die Functions-Skalierungslogik bestimmt, dass sowohl Function_0 als auch Function_1 mehr Nachrichten aufweisen, als verarbeitet werden können, werden neue Functions_N-Funktions-App-Instanzen erstellt. Apps werden erstellt, bis N größer ist als die Anzahl der Event Hub-Partitionen. In unserem Beispiel für Event Hubs erneut einen Lastenausgleich für die Partitionen aus, in diesem Fall für die Instanzen Function_0... Functions_9.

Wenn skaliert wird, entsprechen N Instanzen einer Zahl, die größer als die Anzahl der Event Hub-Partitionen ist. Dieses Muster wird verwendet, um sicherzustellen, dass EventProcessorHost-Instanzen verfügbar sind, um Partitionen zu sperren, sobald diese von anderen Instanzen bereitgestellt werden. Es werden Ihnen nur die Ressourcen berechnet, die bei der Ausführung der Funktionsinstanz in Anspruch genommen werden. Das heißt, die Kosten für diese übermäßige Bereitstellung werden nicht berechnet.

Wenn alle Funktionsausführungen abgeschlossen sind (mit oder ohne Fehler), werden Prüfpunkte dem zugehörigen Speicherkonto hinzugefügt. Wenn die Prüfpunkte erfolgreich erstellt wurden, werden alle 1.000 Nachrichten nie wieder abgerufen.

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