Freigeben über

Hosting des Azure Functions-Flex-Verbrauchstarifs

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 die folgenden Optionen für Speichergröße von Instanzen an: 512 MB, 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. Die Speichergrößen von 512 MB und 4.096 MB sind für Szenarien verfügbar, die den Parallelitäts- oder Verarbeitungsleistungsanforderungen Ihrer Anwendung am besten entsprechen. 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. Immer bereit ist eine gute Option für Szenarien, in denen Sie über eine Mindestanzahl von stets bereiten Instanzen verfügen müssen, um Anforderungen zu verarbeiten. Zum Beispiel, um 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.

Nicht weniger als zwei immer einsatzbereite Instanzen können pro Funktion oder Funktionsgruppe konfiguriert werden, während Zonenredundanz aktiviert ist.

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. 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. Informationen zum Festlegen von Parallelitätsgrenzwerten für Nicht-HTTP-Triggerfunktionen finden Sie unter Target Base Scaling.

Bereitstellung

Bereitstellungen im Flex-Verbrauchsplan folgen einem einzigen Pfad, und es ist nicht mehr erforderlich, dass App-Einstellungen das Bereitstellungsverhalten beeinflussen. Nachdem Ihr 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.

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, .NET 93
Java Java 11, Java 17, Java 21
Node.js Node.js 20, Node.js 22
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11, Python 3.12
  1. C#-In-Process-Modus wird nicht unterstützt. Sie müssen stattdessen Ihr .NET-Codeprojekt migrieren, um es im isolierten Workermodell auszuführen.
  2. Erfordert 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.
  3. Erfordert Version 2.0.0 oder höher von Microsoft.Azure.Functions.Worker und 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. Dieses Kontingent 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. Zum Beispiel würde jedes der folgenden Beispiele bedeuten, dass die Kontingentgrenze erreicht ist und die Anwendungen nicht mehr skaliert werden:

  • Sie haben eine 512 MB-App auf 250 Instanzen skaliert, und eine zweite 512 MB-App wurde auf 750 Instanzen skaliert.
  • Sie haben eine 512 MB-App auf 1.000 Instanzen skaliert.
  • 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.

Flex-Verbrauch-Apps, die auf Null skaliert wurden, oder Instanzen, die als skaliert und gelöscht markiert werden, zählen nicht für das Kontingent. 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 ein Supportticket.

Veraltete Eigenschaften und Einstellungen

In Flex-Verbrauch sind viele der Standardanwendungseinstellungen und Standortkonfigurationseigenschaften 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:

  • Apps pro Plan: Es ist nur eine App pro Flex-Verbrauchsplan zulässig.
  • Host: Für die App-Initialisierung gibt es ein Timeout von 30 Sekunden. Wenn die Funktions-App mehr als 30 Sekunden benötigt, werden möglicherweise gRPC-bezogene System.TimeoutException-Einträge protokolliert. Sie können dieses Timeout zurzeit nicht konfigurieren. 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: Während alle Trigger in einem Flex-Verbrauchsplan vollständig unterstützt werden, unterstützt der Blob Storage-Trigger 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.
  • Proxys: Funktionsproxys werden nicht unterstützt. Erwägen Sie die Integration Ihrer Funktions-Apps in Azure API Management.
  • 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 Module mit App-Inhalt hochladen.
  • Diagnoseeinstellungen: Diagnoseeinstellungen werden derzeit nicht unterstützt.
  • Zertifikate: Das Laden von Zertifikaten mit der App-Einstellung WEBSITE_LOAD_CERTIFICATES, verwalteten Zertifikaten, App-Dienstzertifikaten und anderen Features auf Basis von Plattformzertifikaten wird derzeit nicht unterstützt.
  • Key Vault- und App-Konfigurationsreferenzen: Sie können derzeit keine Azure Key Vault - oder Azure App-Konfigurationsverweise in Ihren Flex-Verbrauchsplan-App-Einstellungen verwenden, wenn diese Dienste den Netzwerkzugriff eingeschränkt haben. Diese Einschränkung gilt auch dann, wenn die Funktions-App die Integration des virtuellen Netzwerks aktiviert hat. Wenn Sie eingeschränkte Key Vault- oder App-Konfigurationsinstanzen verwenden müssen, müssen Sie Client-SDKs verwenden, um Werte aus Verweisen in diesen Diensten manuell abzurufen. Funktionenbindungserweiterungen können auch nicht auf diese Verweise zugreifen. Dies bedeutet, dass Sie auch Azure-Client-SDKs für den Zugriff auf Remotedienstdaten aus Ihrem Funktionscode verwenden müssen.
  • Zeitzonen: WEBSITE_TIME_ZONE und TZ App-Einstellungen werden derzeit nicht unterstützt, wenn sie im Flex-Verbrauchsplan ausgeführt werden.

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