Freigeben über

Hosting des Azure Functions-Flex-Verbrauchstarifs

  • Artikel

Flex-Verbrauch ist ein Linux-basierter Azure Functions-Hostingplan, der auf dem serverlosen Abrechnungsmodell der nutzungsabhängigen Bezahlung basiert. Er bietet Ihnen mehr Flexibilität und Anpassbarkeit, da er private Netzwerke, die Auswahl der Speichergröße und schnelle/große Skalierungsfunktionen einführt, die weiter auf einem serverlosen Modell basieren.

Sie können End-to-End-Beispiele überprüfen, die den Flex-Verbrauchstarif im Flex-Verbrauchstarif-Beispiel-Repository enthalten.

Vorteile

Der Flex-Verbrauchstarif basiert auf den Stärken des Verbrauchstarifs, einschließlich dynamischer Skalierung und ausführungsbasierter Abrechnung. Mit Flex-Verbrauch erhalten Sie auch diese zusätzlichen Features:

Diese Tabelle hilft Ihnen, die Features von Flex-Verbrauch direkt mit dem Hostingplan „Verbrauch“ zu vergleichen:

Funktion Verbrauch Flex-Verbrauch
Skalierung bis null ✅ Ja ✅ Ja
Skalierungsverhalten Ereignisgesteuert Ereignisgesteuert (schnell)
Virtuelle Netzwerke ❌ Nicht unterstützt ✅ Unterstützt
Dedizierter Computemodus (weniger Kaltstarts) ❌ Keine ✅ Jederzeit bereite Instanzen (optional)
Abrechnung Nur Ausführungszeit Ausführungszeit + stets bereite Instanzen
Instanzen mit horizontaler Skalierung (max.) 200 1.000

Einen vollständigen Vergleich des Flex-Verbrauchstarifs mit dem Verbrauchstarif und allen anderen Plänen und Hostingtypen finden Sie unter Funktionsskalierung und Hostingoptionen.

Integration in ein virtuelles Netzwerk

Flex-Verbrauch erweitert die traditionellen Vorteile des Verbrauchstarifs, indem Unterstützung für die Integration in ein virtuelles Netzwerk hinzugefügt wird. Wenn Ihre Apps in einem Flex-Verbrauchstarif ausgeführt werden, können sie eine Verbindung mit anderen Azure-Diensten herstellen, die in einem virtuellen Netzwerk gesichert sind. Gleichzeitig können Sie weiterhin die serverlose Abrechnung und Skalierung zusammen mit den Vorteilen der Skalierung und des Durchsatzes des Flex-Verbrauchstarifs nutzen. Weitere Informationen finden Sie unter Integration in ein virtuelles Netzwerk aktivieren.

Instanzarbeitsspeicher

Wenn Sie Ihre Funktions-App in einem Flex-Verbrauchstarif erstellen, können Sie die Speichergröße der Instanzen auswählen, in denen Ihre App ausgeführt wird. Lesen Sie Abrechnung, um zu erfahren, wie sich die Instanzspeichergröße auf die Kosten Ihrer Funktions-App auswirkt.

Derzeit bietet Flex Consumption Instanzenspeichergrößenoptionen von 2.048 MB und 4.096 MB.

Wenn Sie entscheiden, welche Instanzspeichergröße für Ihre Apps verwendet werden soll, sollten Sie Folgendes berücksichtigen:

  • Die Instanzspeichergröße 2.048 MB ist die Standardspeichergröße und sollte für die meisten Szenarien verwendet werden. Verwenden Sie die Größe der 4.096-MB-Instanz für Szenarien, in denen Ihre App mehr Parallelität oder höhere Verarbeitungsleistung erfordert. Weitere Informationen finden Sie unter Konfigurieren des Instanzspeichers.
  • Sie können die Instanzspeichergröße jederzeit ändern. Weitere Informationen finden Sie unter Konfigurieren des Instanzspeichers.
  • Instanzressourcen werden von Ihrem Funktionscode und dem Funktionshost gemeinsam genutzt.
  • Je größer der Instanzspeicher, desto mehr kann jede Instanz verarbeiten – bis hin zu parallelen Ausführungen oder intensiveren CPU- oder Speicherworkloads. Spezifische Skalierungsentscheidungen sind workloadspezifisch.
  • Die standardmäßige Parallelität von HTTP-Triggern hängt von der Größe des Instanzspeichers ab. Weitere Informationen finden Sie unter HTTP-Triggerparallelität.
  • Verfügbare CPUs und Netzwerkbandbreite werden proportional zu einer bestimmten Instanzgröße bereitgestellt.

Skalierung pro Funktion

Parallelität ist ein wichtiger Faktor, der bestimmt, wie Flex-Verbrauch-Funktions-Apps skaliert werden. Um die Skalierungsleistung von Apps mit verschiedenen Triggertypen zu verbessern, bietet der Flex-Verbrauchstarif eine deterministischere Möglichkeit, Ihre App auf Funktionsbasis zu skalieren.

Diese Skalierung pro Funktion ist Teil der Hostingplattform, sodass Sie Ihre App nicht konfigurieren oder den Code ändern müssen. Weitere Informationen finden Sie unter Skalierung pro Funktion im Artikel „Ereignisgesteuerte Skalierung“.

Bei der Skalierung pro Funktion werden Entscheidungen für bestimmte Funktionstrigger basierend auf Gruppenaggregationen getroffen. Die folgende Tabelle zeigt die definierten Funktionsskalierungsgruppen:

Skalierungsgruppen Trigger in Gruppe Einstellungswert
HTTP-Trigger HTTP-Trigger
SignalR-Trigger		 http
Blob Storage-Trigger
(Event Grid-basiert)		 Blob Storage-Trigger blob
Langlebige Funktionen Orchestrierungstrigger
Aktivitätstrigger
Entitätstrigger		 durable

Alle anderen Funktionen in der App werden einzeln in ihren jeweiligen Instanzen skaliert, auf die mithilfe der Konvention function:<NAMED_FUNCTION> verwiesen wird.

Jederzeit bereite Instanzen

Flex-Verbrauch enthält eine immer bereite Funktion, mit der Sie Instanzen auswählen können, die immer ausgeführt werden und die den einzelnen Skalierungsgruppen pro Funktion oder Funktionen zugewiesen sind. Dies ist eine hervorragende Option für Szenarien, in denen Sie über eine Mindestanzahl von stets bereiten Instanzen verfügen müssen, um Anforderungen zu verarbeiten, z. B. die Kaltstartlatenz Ihrer Anwendung zu verringern. Der Standardwert lautet 0 (Null).

Wenn Sie z. B. für Ihre HTTP-Funktionsgruppe immer 2 festlegen, werden von der Plattform immer zwei Instanzen ausgeführt und Ihrer App für Ihre HTTP-Funktionen in der App zugewiesen. Diese Instanzen verarbeiten Ihre Funktionsausführungen, aber je nach Parallelitätseinstellungen skaliert die Plattform über diese beiden Instanzen hinaus auch mit bedarfsgesteuerten Instanzen.

Informationen zum Konfigurieren von immer bereiten Instanzen finden Sie unter Festlegen der Anzahl der immer bereiten Instanzen.

Parallelität

Parallelität bezieht sich auf die Anzahl der parallelen Ausführungen einer Funktion in einer Instanz Ihrer App. Sie können eine maximale Anzahl paralleler Ausführungen festlegen, die jede Instanz zu einem bestimmten Zeitpunkt verarbeiten soll. Weitere Informationen finden Sie unter HTTP-Triggerparallelität.

Die Parallelität wirkt sich direkt darauf aus, wie Ihre App skaliert wird, da Sie auf niedrigeren Parallelitätsebenen mehr Instanzen benötigen, um die ereignisgesteuerte Nachfrage nach einer Funktion zu bedienen. Während Sie die Parallelität steuern und optimieren können, stellen wir Standardeinstellungen bereit, die für die meisten Fälle funktionieren. Informationen zum Festlegen von Parallelitätsgrenzwerten für HTTP-Triggerfunktionen finden Sie unter Festlegen von HTTP-Parallelitätsgrenzwerten.

Bereitstellung

Bereitstellungen im Flex-Verbrauchsplan folgen einem einzigen Pfad. Nachdem der Projektcode erstellt und in ein Anwendungspaket gezippt wurde, wird er in einem Blobspeichercontainer bereitgestellt. Beim Start ruft Ihre App das Paket ab und führt den Funktionscode aus diesem Paket aus. Standardmäßig wird dasselbe Speicherkonto, das zum Speichern interner Hostmetadaten (AzureWebJobsStorage) verwendet wird, auch als Bereitstellungscontainer verwendet. Sie können jedoch ein alternatives Speicherkonto verwenden oder Ihre bevorzugte Authentifizierungsmethode auswählen, indem Sie die Bereitstellungseinstellungen Ihrer App konfigurieren. Bei der Optimierung des Bereitstellungspfads ist es nicht mehr erforderlich, mit App-Einstellungen das Bereitstellungsverhalten zu beeinflussen.

Abrechnung

Es gibt zwei Modi, mit denen Ihre Kosten bestimmt werden, wenn Sie Ihre Apps im Flex-Verbrauchstarif ausführen. Jeder Modus wird pro Instanz bestimmt.

Abrechnungsmodus Beschreibung
Bei Bedarf Bei Ausführung im Modus Bei Bedarf wird Ihnen nur der Zeitraum in Rechnung gestellt, in dem der Funktionscode für Ihre verfügbaren Instanzen ausgeführt wird. Im bedarfsorientierten Modus ist keine Mindestanzahl an Instanzen erforderlich. Ihnen wird Folgendes in Rechnung gestellt:

• Die Gesamtmenge des bereitgestellten Arbeitsspeichers zur aktiven Ausführung von Funktionen durch On-Demand-Instanzen (in GB-Sekunden) abzüglich einer kostenlosen Zuweisung von GB-Sekunden pro Monat.
• Die Gesamtzahl der Ausführungen abzüglich einer kostenlosen Zuweisung (Anzahl) von Ausführungen pro Monat.
Immer bereit Sie können eine oder mehrere Instanzen konfigurieren, die bestimmten Triggertypen (HTTP/Durable/Blob) und einzelnen Funktionen zugewiesen sind, die immer verfügbar sind, um Anforderungen zu verarbeiten. Wenn immer einsatzbereite Instanzen aktiviert sind, werden Ihnen folgende Kosten in Rechnung gestellt:

• Die Gesamtmenge an Arbeitsspeicher, der in allen immer einsatzbereiten Instanzen bereitgestellt wird, die als Baseline bezeichnet werden (in GB-Sekunden).
• Die Gesamtmenge des bereitgestellten Arbeitsspeichers für jede immer einsatzbereite Instanz während des Zeitraums, in dem sie aktiv Funktionen ausführt (in GB-Sekunden).
• Die Gesamtanzahl der Ausführungen.

Bei der Abrechnung der stets bereiten Instanzen gibt es keine kostenlosen Zuweisungen.

Die aktuellsten Informationen zu Ausführungspreisen, Basiskosten der immer bereiten Instanzen und kostenlose Zuweisungen für On-Demand-Ausführungen finden Sie auf der Azure Functions-Preisseite.

Der minimale abrechnungsfähige Ausführungszeitraum für beide Ausführungsmodi beträgt 1.000 ms. Darüber hinaus wird der abrechnungsfähige Aktivitätszeitraum auf die nächsten 100 ms gerundet. Details zu den Verbrauchseinheiten für die Abrechnung des Flex-Verbrauchstarifs finden Sie in der Referenz zur Überwachung.

Ausführliche Informationen dazu, wie Kosten berechnet werden, wenn Sie in einem Flex-Verbrauchstarif ausgeführt werden, einschließlich Beispiele, finden Sie unter Verbrauchsbasierte Kosten.

Unterstützte Sprachstapelversionen

In dieser Tabelle sind die Sprachstapelversionen aufgeführt, die derzeit für Flex-Verbrauchs-Apps unterstützt werden:

Sprachstapel Erforderliche Version
C# (isolierter Prozessmodus)1 .NET 82
Java Java 11, Java 17
Node.js Node 20
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11

1C# In-Process-Modus wird nicht unterstützt. Sie müssen stattdessen Ihr .NET-Codeprojekt migrieren, um es im isolierten Workermodell auszuführen.
2Erfordert Version 1.20.0 oder höher von Microsoft.Azure.Functions.Worker und Version 1.16.2 oder höher von Microsoft.Azure.Functions.Worker.Sdk.

Speicherkontingente für regionale Abonnements

Derzeit verfügt jede Region in einem bestimmten Abonnement über eine Speichergrenze von 512,000 MB für alle Instanzen von Apps, die in Flex-Verbrauchstarifen ausgeführt werden. Das bedeutet, dass Sie in einem bestimmten Abonnement und einer bestimmten Region jede beliebige Kombination von Instanzspeichergrößen und -zahlen haben können, solange sie unter der Kontingentgrenze bleiben. Jedes der folgenden Beispiele würde bedeuten, dass die Kontingentgrenze erreicht ist und die Anwendungen nicht mehr skaliert werden:

  • Sie haben eine App mit 2048 MB, die auf 100 skaliert ist, und eine zweite App mit 2048 MB, die auf 150 Instanzen skaliert ist.
  • Sie haben eine App mit 2048 MB, die auf 250 Instanzen skaliert ist.
  • Sie haben eine App mit 4096 MB, die auf 125 Instanzen skaliert ist.
  • Sie haben eine App mit 4096 MB, die auf 100 skaliert ist, und eine zweite App mit 2048 MB, die auf 50 Instanzen skaliert ist.

Dieses Kontingent kann erhöht werden, damit Ihre Flex Consumption Anwendungen weiter skaliert werden können, je nach Ihren Anforderungen. Wenn Ihre Anwendungen ein größeres Kontingent benötigen, erstellen Sie bitte ein Supportticket.

Veraltete Eigenschaften und Einstellungen

In Flex-Verbrauch sind viele der Standardanwendungseinstellungen und Standortkonfigurationseigenschaften, die in Bicep, ARM-Vorlagen und auf der gesamten Steuerungsebene verwendet werden, veraltet oder wurden verschoben und sollten beim Automatisieren der Ressourcenerstellung für die Funktions-App nicht verwendet werden. Weitere Informationen finden Sie unter Veraltete Funktionen beim Flex-Verbrauchstarif.

Überlegungen

Beachten Sie diese anderen Überlegungen bei der Verwendung des Flex-Verbrauchstarifs:

  • Host: Für die App-Initialisierungen ist ein Timeout von 30 Sekunden definiert. Wenn die Funktions-App mehr als 30 Sekunden benötigt, werden möglicherweise gRPC-bezogene System.TimeoutException-Einträge protokolliert. Dieses Timeout kann derzeit nicht konfiguriert werden. Weitere Informationen finden Sie in dieser Hostarbeitsaufgabe.
  • Durable Functions: Azure Storage ist derzeit der einzige unterstützte Speicheranbieter für Durable Functions, wenn er im Flex-Verbrauchsplan gehostet wird. Sehen Sie sich die Empfehlungen an, wenn Sie langlebige Funktionen im Flex-Verbrauchsplan hosten.
  • Integration in virtuelle Netzwerke: Stellen Sie sicher, dass der Azure-Ressourcenanbieter Microsoft.App für Ihr Abonnement aktiviert ist, indem Sie die folgenden Anweisungen befolgen. Die Subnetzdelegierung, die von Flex-Verbrauch-Apps benötigt wird, lautet Microsoft.App/environments.
  • Trigger: Alle Trigger mit Ausnahme von Kafka- und Azure SQL-Triggern werden vollständig unterstützt. Der Blob-Speichertrigger unterstützt nur die Event Grid-Quelle. Nicht-C#-Funktions-Apps müssen Version [4.0.0, 5.0.0) des Erweiterungspakets oder eine höhere Version verwenden.
  • Regionen: Nicht alle Regionen werden derzeit unterstützt. Weitere Informationen finden Sie unter Derzeit unterstützte Regionen anzeigen.
  • Bereitstellungen: Bereitstellungsslots werden derzeit nicht unterstützt.
  • Skalierung: Die niedrigste maximale Skalierung ist derzeit 40. Der höchste derzeit unterstützte Wert ist 1000.
  • Verwaltete Abhängigkeiten: Verwaltete Abhängigkeiten in PowerShell werden von Flex Consumption nicht unterstützt. Sie müssen stattdessen eigene benutzerdefinierte Module definieren.
  • Diagnoseeinstellungen: Diagnoseeinstellungen werden derzeit nicht unterstützt.
  • Zertifikate: Das Laden von Zertifikaten mit der App-Einstellung WEBSITE_LOAD_CERTIFICATES wird derzeit nicht unterstützt.
  • Key Vault-Verweise: Key Vault-Verweise in den App-Einstellungen funktionieren nicht, wenn der Zugriff auf Key Vault über das Netzwerk eingeschränkt ist, auch wenn die Funktions-App über eine Integration des virtuellen Netzwerks verfügt. Die aktuelle Problemumgehung besteht darin, im Code direkt auf den Key Vault zu verweisen und die erforderlichen Geheimnisse zu lesen.

Azure Functions-HostingoptionenErstellen und Verwalten von Funktions-Apps im Flex-Verbrauchstarif