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. Es bietet Ihnen mehr Flexibilität und Anpassbarkeit, indem es private Netzwerke, die Auswahl der Instanzspeichergröße und schnelle/große Skalierung einführt, die immer noch auf einem serverlosen Modell basieren.

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

Benefits

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

• Reduzierte Kaltstartzeiten: Ermöglichen Sie immer einsatzbereite Instanzen , um im Vergleich zum Verbrauchsplan schnellere Kaltstartzeiten zu erzielen.
• Unterstützung für virtuelle Netzwerke: Durch die Integration virtueller Netzwerke kann Ihre serverlose App in einem virtuellen Netzwerk ausgeführt werden.
• Per-Function Skalierung: Jede Funktion in Ihrer App wird unabhängig von ihrer Arbeitsauslastung skaliert, was zu einer effizienteren Ressourcenzuordnung führt.
• Verbesserte Parallelitätsbehandlung: Bessere Behandlung gleichzeitiger Ausführungen mit konfigurierbaren Parallelitätseinstellungen pro Funktion.
• Flexible Speicherkonfiguration: Flex-Verbrauch bietet mehrere Größenoptionen für Instanzen , sodass Sie ihre spezifischen Workloadanforderungen optimieren können.

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

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.

Instanzengrößen

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. Siehe Abrechnung , um zu erfahren, wie sich Instanzenspeichergrößen auf die Kosten Ihrer Funktions-App auswirken.

Zurzeit bietet Flex Consumption die folgenden Optionen für die Instanzgröße:

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.

Dieses Skalierungsverhalten pro Funktion ist Teil der Hostingplattform, sodass Sie Ihre App nicht konfigurieren oder den Code ändern müssen. Weitere Informationen finden Sie im Artikel zur ereignisgesteuerten Skalierung pro Funktion .

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

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.

Concurrency

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.

Deployment

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.

Bereitstellungen ohne Ausfallzeiten

Flex-Verbrauch bietet Bereitstellungen ohne Ausfallzeiten durch rollierende Updates als Standortupdatestrategie. So können Codebereitstellungen und Konfigurationsänderungen schrittweise auf Instanzen angewendet werden, ohne die Funktionsausführung zu unterbrechen. Andere Hostingpläne verwenden Bereitstellungsplätze, um Ausfallzeiten während der Bereitstellungen zu minimieren. Informationen zu Bereitstellungsoptionen in allen Hostingplänen finden Sie unter Optimieren von Bereitstellungen.

Billing

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.

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 Abrechnungszählern des Flex-Verbrauchsplans finden Sie in der Überwachungsreferenz.

Ausführliche Informationen dazu, wie die Kosten berechnet werden, bei der Nutzung eines Flex-Verbrauchsplans, einschließlich Beispielen, finden Sie unter Verbrauchsbasierte Kosten und Anzeigen von kostenbezogenen Daten.

Unterstützte Sprachstapelversionen

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

1. Das C#-In-Process-Modell wird nicht unterstützt. Stattdessen müssen Sie Ihr .NET-Projekt zum isolierten Workermodell migrieren.

Speicherkontingente für regionale Abonnements

Der Flex-Verbrauchsplan verfügt über ein speicherbasiertes Kontingent, das die Nutzungskapazität aller Ihrer Flex-Verbrauch-Apps in einer bestimmten Region und einem bestimmten Abonnement gleichzeitig begrenzt. Stellen Sie sich vor, Sie haben einen Bucket mit Arbeitsspeicher in GB oder CPU-Kernen für Ihr gesamtes Abonnement in einer Region. Alle Ihre Flex Consumption-Apps in dieser Region teilen diesen Speicherbereich. Wenn Ihre Flex Consumption Apps versuchen, mehr als das Kontingent zu verwenden, können einige Vorgänge verzögert oder im Skalierungsprozess gedrosselt werden. Sie werden jedoch nicht daran gehindert, Apps zu erstellen oder bereitzustellen.

Derzeit hat jede Region in einem bestimmten Abonnement ein Standardkontingent von dem geringeren Wert entweder 512,000 MB oder 250 Kernen für alle Instanzen von Apps, die auf Flex-Verbrauchsplänen ausgeführt werden. Diese Kontingente bedeuten, dass Sie in einem bestimmten Abonnement und einer bestimmten Region eine beliebige Kombination aus Instanzenspeichergrößen und -zählungen haben könnten, solange sie unter den Kontingentgrenzwerten bleiben. In jedem dieser Szenarien wird das Kontingent beispielsweise erreicht, und Apps in der Region werden nicht mehr skaliert:

• Sie haben eine 512-MB-App auf 250 Instanzen skaliert und eine zweite 512-MB-App auf 750 Instanzen skaliert.
• Sie haben eine 512-MB-App auf 1.000 Instanzen skaliert.
• Sie haben eine 2.048-MB-App auf 100 skaliert und eine zweite 2.048-MB-App auf 150 Instanzen skaliert.
• Sie haben eine 2.048 MB-App, die auf 250 Instanzen skaliert wurde
• Sie haben eine 4.096-MB-App, die auf 125 Instanzen skaliert wurde
• Sie haben eine 4.096-MB-App auf 100 skaliert und eine 2.048-MB-App auf 50 Instanzen skaliert.

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

Im Flex-Verbrauchsplan sind viele der standardanwendungseinstellungen und Websitekonfigurationseigenschaften veraltet oder wurden verschoben und sollten nicht verwendet werden, wenn die App-Ressourcenerstellung von Funktionen automatisiert wird. Weitere Informationen finden Sie unter Veraltete Funktionen beim Flex-Verbrauchstarif.

Considerations

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.
• Dauerhafte Funktionen: Azure Storage ist derzeit der einzige unterstützte Speicheranbieter für dauerhafte Funktionen, 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 die Version [4.0.0, 5.0.0) des Erweiterungspakets oder eine höhere Version verwenden.
• Regionen: Derzeit werden nicht alle Regionen unterstützt. Weitere Informationen finden Sie unter Derzeit unterstützte Regionen anzeigen.
• Bereitstellungen: Bereitstellungs-Slots werden derzeit nicht unterstützt. Erfahren Sie mehr über Bereitstellungen ohne Ausfallzeiten mit Flex Consumption unter Strategien zur Aktualisierung von Websites in Flex Consumption.
• Azure Storage als lokale Freigabe: NFS-Dateifreigaben sind für Flex-Verbrauch nicht verfügbar. Nur SMB- und Azure-Blobs (schreibgeschützt) werden unterstützt.
• Scale: Der niedrigste maximale Maßstab 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.
• Zertifikate: Das Laden von Zertifikaten mit der WEBSITE_LOAD_CERTIFICATES App-Einstellung, verwalteten Zertifikaten, App-Dienstzertifikaten und anderen plattformbasierten Features wie endToEndEncryptionEnabled wird derzeit nicht unterstützt.
• Zeitzonen: Die App-Einstellungen für WEBSITE_TIME_ZONE und TZ werden derzeit nicht unterstützt, wenn sie im Flex-Verbrauchsplan ausgeführt werden.

Verwandte Artikel

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