Premium-Tarif für Azure Functions

Der Elastic Premium-Tarif für Azure Functions ist eine dynamische Staffelung für Hostingoption für Funktions-Apps. Andere Hostingplanoptionen finden Sie im Artikel zu Hostingplänen.

Wichtig

Azure Functions wird auf der Azure App Service-Plattform ausgeführt. Auf der App Service-Plattform werden Tarife, die Premium-Apps für Tariffunktionen hosten, als Elastic Premium-Tarife mit SKU-Namen wie bezeichnet. Wenn Sie Ihre Funktions-App in einem Premium-Tarif ausführen möchten, stellen Sie sicher, dass Sie einen Tarif mit einem SKU-Namen erstellen, der mit einem „E“ beginnt, z. B. EP1. App Service Plan-SKU-Namen, die mit einem „P“ beginnen, z. B. P1V2 (kleiner Premium V2-Tarif), sind tatsächlich P1V2 Da es sich um dedizierte Tarife und nicht um Elastic Premium Tarife handelt, werden Tarife mit SKU-Namen, die mit einem „P“ beginnen, nicht dynamisch skaliert und möglicherweise ihre Kosten erhöhen.

Das Hosten von Funktionen im Premium-Plan bietet die folgenden Vorteile:

  • Vermeiden von Kaltstarts durch ständig betriebsbereite (warme) Instanzen
  • VNET-Konnektivität
  • Unbegrenzte Ausführungsdauer, 60 Minuten garantiert
  • Premium-Instanzgrößen: Instanzen mit einem Kern, mit zwei Kernen und mit vier Kernen
  • Besser vorhersagbare Preise im Vergleich zum Verbrauchsplan
  • App-Zuteilung mit hoher Dichte für Pläne mit mehrere Funktions-Apps

Bei Verwendung des Premium-Plans werden Instanzen des Azure Functions-Hosts basierend auf der Anzahl der eingehenden Ereignisse hinzugefügt und entfernt, wie es auch beim Verbrauchsplan der Fall ist. Mehrere Funktions-Apps können im selben Premium-Plan bereitgestellt werden, und der Tarif ermöglicht es Ihnen, die Compute-Instanzgröße, Basisplangröße und maximale Plangröße zu konfigurieren.

Abrechnung

Die Abrechnung für den Premium-Plan basiert auf der Anzahl von Kernsekunden und dem Arbeitsspeicher, der den Instanzen zugeordnet ist. Diese Abrechnung unterscheidet sich von der des Verbrauchsplans, die pro Ausführung und verbrauchtem Arbeitsspeicher erfolgt. Beim Premium-Plan fallen keine Gebühren pro Ausführung an. Pro Plan muss immer mindestens eine Instanz zugeordnet sein. Diese Abrechnung führt zu monatlichen Mindestkosten pro aktivem Plan, unabhängig davon, ob die Funktion aktiv oder im Leerlauf ist. Beachten Sie, dass sich alle Funktions-Apps in einem Premium-Plan die zugeordneten Instanzen teilen. Weitere Informationen finden Sie auf der Seite mit der Preisübersicht für Azure Functions.

Erstellen eines Premium-Plans

Wenn Sie eine Funktions-App im Azure-Portal erstellen, gilt standardmäßig der Verbrauchsplan. Um eine Funktions-App zur Ausführung in einem Premium-Plan zu erstellen, müssen Sie unter Verwendung einer der Elastic Premium-SKUs explizit einen App Service-Plan erstellen. Die von Ihnen erstellte Funktions-App wird dann in diesem Plan gehostet. Im Azure-Portal können Sie den Premium-Plan und die Funktions-App ganz einfach gleichzeitig erstellen. Sie können mehrere Funktions-Apps im selben Premium-Plan ausführen, aber nur, wenn alle Apps unter demselben Betriebssystem (Windows oder Linux) ausgeführt werden.

In den folgenden Artikeln erfahren Sie, wie Sie programmgesteuert oder im Azure-Portal eine Funktions-App mit einem Premium-Plan erstellen:

Vermeiden von Kaltstarts

Wenn keine Ereignisse und Ausführungen im Verbrauchsplan stattfinden werden, wird Ihre App möglicherweise auf null Instanzen abskaliert. Wenn neue Ereignisse eintreffen, muss eine neue Instanz angegeben werden, in der Ihre App ausgeführt wird. Das Einrichten einer neuen Instanz kann je nach App einige Zeit dauern. Diese zusätzliche Wartezeit beim ersten Aufruf wird häufig als App-Kaltstart bezeichnet.

Ein Premium-Plan bietet zwei Features, die gemeinsam Kaltstarts in Ihren Funktionen effektiv vermeiden: jederzeit bereite Instanzen und vorab aufgewärmte Instanzen.

Jederzeit bereite Instanzen

Im Premium-Plan können Sie Ihre App jederzeit bereit für eine angegebene Anzahl von Instanzen vorhalten. Die maximale Anzahl von jederzeit bereiten Instanzen beträgt 20. Wenn Ereignisse mit dem Auslösen der App beginnen, werden sie zuerst an die jederzeit bereiten Instanzen weitergeleitet. Wenn die Funktion aktiv wird, werden zusätzliche Instanzen als Puffer „vorgewärmt“. Dieser Puffer verhindert einen Kaltstart für neue Instanzen, die während der Skalierung erforderlich sind. Diese gepufferten Instanzen werden als vorgewärmte Instanzen aufgerufen. Durch die Kombination aus jederzeit bereiten Instanzen und einem vorgewärmten Puffer kann Ihre App einen Kaltstart effektiv vermeiden.

Hinweis

Jeder Premium-Plan bietet immer mindestens eine aktive (in Rechnung gestellte) Instanz.

Sie können die Anzahl der jederzeit bereiten Instanzen im Azure-Portal konfigurieren, indem Sie Ihre Funktions-App auswählen, zur Registerkarte Plattformfeatures wechseln und die Optionen zum Aufskalieren auswählen. Im Bearbeitungsfenster der Funktions-App sind jederzeit bereite Instanzen für diese App spezifisch.

Elastic Scale Settings

Vorab aufgewärmte Instanzen

Bei vorab aufgewärmten Instanzen handelt es sich um Instanzen, die während Skalierungs- und Aktivierungsereignissen als Puffer vorgewärmt werden. Vorab aufgewärmte Instanzen setzen die Pufferung fort, bis der Grenzwert für maximale horizontale Skalierung erreicht wird. Die standardmäßige Anzahl vorab aufgewärmter Instanzen ist 1, und dieser Wert sollte für die meisten Szenarien beibehalten werden.

Wenn eine App eine lange Aufwärmphase aufweist (z. B. ein benutzerdefiniertes Containerimage), kann es sinnvoll sein, diesen Puffer zu vergrößern. Eine vorab aufgewärmte Instanz wird erst aktiv, wenn alle aktiven Instanzen ausreichend ausgelastet wurden.

Sie können auch einen Aufwärmtrigger definieren, der vor dem Aufwärmvorgang ausgeführt wird. Ein Trigger für die Aufwärmphase kann verwendet werden, um während der Vorabaufwärmung benutzerdefinierte Abhängigkeiten vorab zu laden, damit Ihre Funktionen sofort mit der Verarbeitung von Anforderungen beginnen können. Weitere Informationen finden Sie unter Azure Functions-Aufwärmtrigger.

Folgendes Beispiel zeigt, wie jederzeit bereite Instanzen und vorab aufgewärmte Instanzen zusammenarbeiten. Für eine Premium-Funktions-App sind fünf jederzeit bereite Instanzen konfiguriert, und die Standardeinstellung bietet eine vorab aufgewärmte Instanz. Wenn sich die App im Leerlauf befindet und keine Ereignisse als Auslöser vorhanden sind, wird die App mit fünf Instanzen bereitgestellt und ausgeführt. Zu diesem Zeitpunkt wird Ihnen keine vorab aufgewärmte Instanz in Rechnung gestellt, da die jederzeit bereiten Instanzen nicht verwendet werden und keine vorab aufgewärmte Instanz zugeordnet ist.

Sobald der erste Trigger eintrifft, werden die fünf jederzeit bereiten Instanzen aktiv, und eine vorab aufgewärmte Instanz wird zugeordnet. Die App wird nun mit sechs bereitgestellten Instanzen ausgeführt: mit den fünf jetzt aktiven, jederzeit bereiten Instanzen und dem sechsten vorab aufgewärmten und inaktiven Puffer. Wenn die Ausführungsrate weiterhin zunimmt, sind die fünf aktiven Instanzen schließlich ausgelastet. Wenn die Plattform über fünf Instanzen hinaus skaliert, erfolgt die Skalierung in die vorab aufgewärmte Instanz. In diesem Fall sind jetzt sechs aktive Instanzen vorhanden, und eine siebte Instanz wird sofort bereitgestellt und füllt den Puffer mit vorab aufgewärmten Instanzen auf. Diese Sequenz aus Skalierung und Vorabaufwärmung wird fortgesetzt, bis die maximale Anzahl von Instanzen für die App erreicht ist. Über den maximalen Wert hinaus werden keine Instanzen vorab aufgewärmt oder aktiviert.

Sie können die Anzahl der vorab aufgewärmten Instanzen für eine App ändern, indem Sie die Azure CLI verwenden.

az resource update -g <resource_group> -n <function_app_name>/config/web --set properties.preWarmedInstanceCount=<desired_prewarmed_count> --resource-type Microsoft.Web/sites

Maximale Anzahl von Funktions-App-Instanzen

Zusätzlich zur Maximalen Anzahl von Instanzen des Tarifs können Sie einen maximale Anzahl pro App konfigurieren. Die maximale Anzahl pro App kann mit der App-Skalierungsgrenze konfiguriert werden.

Private Netzwerkkonnektivität

Funktions-App, die in einem Premium-Plan bereitgestellt wurden, können von der VNET-Integration für Web-Apps profitieren. Ist diese Integration konfiguriert, kann Ihre App mit Ressourcen in Ihrem VNET oder geschützt über Dienstendpunkte kommunizieren. IP-Einschränkungen sind ebenfalls für die App verfügbar, um eingehenden Datenverkehr zu beschränken.

Wenn Sie Ihrer Funktions-App in einem Premium-Plan ein Subnetz zuweisen, benötigen Sie ein Subnetz mit genügend IP-Adressen für jede mögliche-Instanz. Wir benötigen einen IP-Block mit mindestens 100 verfügbaren Adressen.

Weitere Informationen finden Sie unter Integrieren einer Funktions-App in ein Azure Virtual Network.

Schnelle elastische Skalierung

Weitere Compute-Instanzen werden automatisch für Ihre App hinzugefügt. Dazu wird die gleiche Logik für schnelle Skalierung verwendet wie für den Verbrauchsplan. Apps im gleichen App Service-Plan werden unabhängig voneinander auf der Grundlage der Anforderungen der jeweiligen App skaliert. Von Funktions-Apps im gleichen App Service-Plan werden VM-Ressourcen jedoch nach Möglichkeit gemeinsam genutzt, um Kosten zu sparen. Die Anzahl von Apps, die einem virtuellen Computer zugeordnet sind, hängt vom Speicherbedarf der einzelnen Apps sowie von der Größe des virtuellen Computers ab.

Informationen zur Funktionsweise der Skalierung finden Sie unter Ereignisgesteuerte Skalierung in Azure Functions.

Längere Ausführungsdauer

Azure Functions in einem Verbrauchsplan sind auf 10 Minuten für eine einzelne Ausführung beschränkt. Im Premium-Plan wird die Ausführungsdauer standardmäßig auf 30 Minuten festgelegt, um Endlosausführungen zu verhindern. Sie können jedoch die host.json-Konfiguration ändern, um eine unbegrenzte Dauer für Premium-Plan-Apps festzulegen. Wenn für Ihre Funktions-App eine unbegrenzte Dauer festgelegt wurde, wird sie garantiert mindestens 60 Minuten lang ausgeführt.

Migration

Wenn Sie über eine vorhandene Funktions-App verfügen, können Sie Azure CLI-Befehle verwenden, um Ihre App unter Windows zwischen einem Verbrauchsplan und einem Premium-Plan zu migrieren. Die spezifischen Befehle hängen von der Richtung der Migration ab. Weitere Informationen finden Sie unter Planmigration.

Die Migration wird unter Linux nicht unterstützt.

Plan- und SKU-Einstellungen

Wenn Sie den Plan erstellen, konfigurieren Sie zwei Einstellungen für die Plangröße: die Mindestanzahl von Instanzen (oder Plangröße) und den maximalen Burstgrenzwert.

Wenn Ihre App über die jederzeit bereiten Instanzen hinaus weitere Instanzen erfordert, kann die Aufskalierung fortgesetzt werden, bis die Anzahl von Instanzen das maximale Burstlimit erreicht. Instanzen, die Ihre Plangröße überschreiten, werden Ihnen nur in Rechnung gestellt, während sie ausgeführt werden und Ihnen zugeordnet sind. Die Abrechnung erfolgt sekundengenau. Die Plattform versucht, Ihre App bis zum definierten Maximalwert zu skalieren.

Sie können die Plangröße und die Maximalwerte im Azure-Portal konfigurieren, indem Sie die Aufskalieren-Optionen im Plan oder eine Funktions-App auswählen, die für diesen Plan bereitgestellt ist (unter Plattformfeatures).

Sie können auch den maximalen Burstgrenzwert über die Azure-Befehlszeilenschnittstelle erhöhen:

az functionapp plan update -g <resource_group> -n <premium_plan_name> --max-burst <desired_max_burst>

Die Mindestanzahl für jeden Plan beträgt mindestens eine Instanz. Die tatsächliche Mindestanzahl von Instanzen wird basierend auf den jederzeit bereiten Apps im Plan automatisch konfiguriert, die von Apps im Plan angefordert werden. Wenn App A z. B. fünf jederzeit bereite Instanzen anfordert und App B zwei jederzeit bereite Instanzen im gleichen Plan anfordert, wird die Mindestplangröße als fünf berechnet. App A wird in allen 5 Instanzen ausgeführt, App B nur in 2 Instanzen.

Wichtig

Ihnen wird jede Instanz, die entsprechend der Mindestanzahl von Instanzen zugeordnet ist, in Rechnung gestellt, unabhängig davon, ob Funktionen ausgeführt werden oder nicht.

In den meisten Fällen ist dieser automatisch berechnete Mindestwert ausreichend. Eine Skalierung über den Mindestwert hinaus erfolgt jedoch nach bestem Bemühen. Es ist möglich (wenn auch unwahrscheinlich), dass sich die Aufskalierung zu einem bestimmten Zeitpunkt verzögert, wenn keine weiteren Instanzen verfügbar sind. Wenn Sie einen Mindestwert festlegen, der höher als der automatisch berechnete Mindestwert ist, reservieren Sie Instanzen vor dem horizontalen Hochskalieren.

Die Erhöhung des berechneten Mindestwerts für einen Plan kann mit der Azure CLI erfolgen.

az functionapp plan update -g <resource_group> -n <premium_plan_name> --min-instances <desired_min_instances>

Verfügbare Instanz-SKUs

Wenn Sie Ihren Plan erstellen oder skalieren, können Sie zwischen drei Instanzgrößen wählen. Ihnen werden die Gesamtanzahl bereitgestellter Kerne und der bereitgestellte Arbeitsspeicher in Rechnung gestellt (sekundengenau für die Zeit, die Ihnen die Instanz zugeordnet ist). Ihre App kann automatisch nach Bedarf auf mehrere Instanzen aufskaliert werden.

SKU Kerne Arbeitsspeicher Storage
EP1 1 3,5 GB 250 GB
EP2 2 7 GB 250 GB
EP3 4 14 GB 250 GB

Überlegungen zur Speicherauslastung

Das Ausführen auf einem Computer mit mehr Arbeitsspeicher bedeutet nicht immer, dass Ihre Funktions-App den gesamten verfügbaren Arbeitsspeicher auch verwendet.

Beispielsweise wird eine JavaScript-Funktions-App durch das standardmäßige Arbeitsspeicherlimit in „Node.js“ eingeschränkt. Um dieses feste Arbeitsspeicherlimit zu erhöhen, fügen Sie die App-Einstellung languageWorkers:node:arguments mit dem Wert --max-old-space-size=<max memory in MB> hinzu.

Stellen Sie bei Plänen mit mehr als 4 GB Arbeitsspeicher sicher, dass die Einstellung für die Bitanzahl der Plattform unter 64 Bit auf 64 Bit festgelegt ist.

Maximale horizontale Hochskalierung der Region

Im Folgenden werden die derzeit unterstützten maximalen Werte für horizontales Hochskalieren für einen einzelnen Tarif in jeder Region und Betriebssystemkonfiguration aufgeführt.

Auf der Azure-Website finden Sie Informationen zur Verfügbarkeit von Functions in allen Regionen.

Region Windows Linux
Australien, Mitte 100 Nicht verfügbar.
Australien, Mitte 2 100 Nicht verfügbar.
Australien (Osten) 100 40
Australien, Südosten 100 20
Brasilien Süd 100 20
Kanada, Mitte 100 20
Indien, Mitte 100 20
USA (Mitte) 100 40
China, Osten 2 100 20
China, Norden 2 100 20
Asien, Osten 100 20
East US 100 60
USA (Ost) 2 100 40
Frankreich, Mitte 100 20
Deutschland, Westen-Mitte 100 20
Japan, Osten 100 20
Japan, Westen 100 20
Jio Indien, Westen 100 20
Korea, Mitte 100 20
Korea, Süden Nicht verfügbar 20
USA Nord Mitte 100 20
Nordeuropa 100 40
Norwegen, Osten 100 20
Südafrika, Norden 100 20
USA Süd Mitte 100 40
Indien (Süden) 100 Nicht verfügbar.
Asien, Südosten 100 20
Schweiz, Norden 100 20
Schweiz, Westen 100 20
Vereinigte Arabische Emirate, Norden 100 20
UK, Süden 100 20
UK, Westen 100 20
US Gov Arizona 100 20
US Gov Texas 100 Nicht verfügbar.
US Government, Virginia 100 20
USA, Westen-Mitte 100 20
Europa, Westen 100 40
Indien, Westen 100 20
USA (Westen) 100 20
USA, Westen 2 100 20
USA, Westen 3 100 20

Nächste Schritte