Vergleich der Azure Functions-Hostingoptionen

Wenn Sie eine Funktions-App in Azure erstellen, müssen Sie einen Hostingplan für die App auswählen. Azure bietet Ihnen diese Hostingoptionen für Ihren Funktionscode:

Die Azure App Service-Infrastruktur erleichtert das Hosting von Azure Functions auf virtuellen Linux- und Windows-Computern. Die von Ihnen gewählte Hostingoption bestimmt folgendes Verhalten:

• Wie Ihre Funktions-App skaliert wird.
• Die für jede Instanz der Funktions-App verfügbaren Ressourcen.
• Die Unterstützung für erweiterte Funktionen wie Azure Virtual Network-Konnektivität
• Unterstützung für Linux-Container.

Der von Ihnen ausgewählte Plan wirkt sich auch auf die Kosten für die Ausführung des Funktionscodes aus.

Übersicht über die Pläne

Es folgt eine Zusammenfassung der Vorteile der verschiedenen Hostingoptionen:

Verbrauchsplan

Der Verbrauchsplan ist der Standardhostingplan. Zahlen Sie nur für Computeressourcen, wenn Ihre Funktionen ausgeführt werden (nutzungsbasiert) mit automatischer Skalierung. Im Verbrauchsplan werden Instanzen des Functions-Hosts basierend auf der Anzahl von eingehenden Ereignissen dynamisch hinzugefügt und entfernt.

Flex-Verbrauchsplan

Erzielen Sie eine hohe Skalierbarkeit mit Rechenoptionen, virtuellen Netzwerken und Abrechnung nach Nutzung. Im Flex-Verbrauchsplan werden Instanzen des Functions-Host basierend auf der konfigurierten Parallelität pro Instanz und der Anzahl der eingehenden Ereignisse dynamisch hinzugefügt und entfernt.

Sie können Kaltstarts reduzieren, indem Sie die Anzahl der vorab bereitgestellten (immer bereiten) Instanzen angeben. Skaliert automatisch basierend auf Bedarf.

Premium-Plan

Skaliert automatisch nach Bedarf durch vorgewärmte Worker, die Anwendungen ohne Verzögerung nach dem Leerlauf ausführen, wird auf leistungsfähigeren Instanzen ausgeführt und stellt eine Verbindung mit virtuellen Netzwerken her.

Ziehen Sie den Premium-Plan für Azure Functions in folgenden Situationen in Betracht:

• Ihre Funktions-Apps werden kontinuierlich oder nahezu kontinuierlich ausgeführt.
• Sie möchten mehr Kontrolle über Ihre Instanzen haben und mehrere Funktions-Apps im selben Plan mit ereignisgesteuerter Skalierung bereitstellen.
• Sie verfügen über eine hohe Anzahl kleiner Ausführungen und haben hohe Ausführungskosten, aber wenige Gigabytesekunden im Verbrauchsplan.
• Sie benötigen weitere CPU- oder Arbeitsspeicheroptionen zusätzlich zu den vom Verbrauchsplan bereitgestellten.
• Ihr Code muss länger ausgeführt werden, als im Verbrauchsplan als maximal zulässige Ausführungsdauer angegeben ist.
• Sie benötigen VNet-Konnektivität.
• Sie möchten ein benutzerdefiniertes Linux-Image bereitstellen, auf dem Ihre Funktionen ausgeführt werden sollen.

Dedizierter Plan

Führen Sie Ihre Funktionen in einem App Service-Plan zu den regulären Preisen dieses Plans aus. Dieser Plan eignet sich am besten in zeitintensiven Szenarien, in denen Durable Functions nicht verwendet werden kann.

Ziehen Sie einen App Service-Plan in folgenden Situationen in Betracht:

• Sie müssen über eine vollständig vorhersehbare Abrechnung verfügen, oder Sie müssen Instanzen manuell skalieren.
• Sie möchten mehrere Web-Apps und Funktions-Apps im selben Plan ausführen.
• Sie benötigen Zugriff auf eine größere Auswahl an Rechengrößen.
• Vollständig isoliertes Compute und sicherer Netzwerkzugriff, der von einer App Service-Umgebung (ASE) bereitgestellt wird.
• Hohe Speicherauslastung und hohe Skalierung (ASE).

Container Apps

Erstellen und Bereitstellen von containerisierten Funktions-Apps in einer vollständig verwalteten Umgebung, die von Azure Container Apps gehostet wird.

Verwenden Sie das Programmiermodell von Azure Functions, um ereignisgesteuerte, serverlose, cloudnative Funktions-Apps zu erstellen. Führen Sie Ihre Funktionen zusammen mit anderen Microservices, APIs, Websites und Workflows als containergehostete Programme aus.

Überlegen Sie, Ihre Funktionen in Container Apps in den folgenden Situationen zu hosten:

• Sie möchten benutzerdefinierte Bibliotheken mit Ihrem Funktionscode in einem Paket zusammenfassen, um branchenspezifische Apps zu unterstützen.
• Sie müssen die Codeausführung von lokalen Apps oder Legacy-Apps zu cloudnativen Microservices migrieren, die in Containern ausgeführt werden.
• Sie möchten den Mehraufwand und die Komplexität der Verwaltung von Kubernetes-Clustern und dedizierten Computeressourcen vermeiden.
• Sie benötigen die High-End-Verarbeitungsleistung, die von dedizierten CPU-Computeressourcen für Ihre Funktionen bereitgestellt wird.

Dauer des Funktions-App-Timeouts

Die functionTimeout Eigenschaft in der host.json Projektdatei gibt die Timeoutdauer für Funktionen in einer Funktions-App an. Diese Eigenschaft gilt speziell für Funktionsausführungen. Nachdem der Trigger die Ausführung der Funktion gestartet hat, muss die Funktion innerhalb der Timeoutdauer etwas zurückgeben oder reagieren.

Die folgende Tabelle zeigt die Standard- und Höchstwerte (in Minuten) für bestimmte Pläne:

1. Unabhängig von der Timeouteinstellung der Funktions-App stellen 230 Sekunden die längste Zeit dar, die einer über HTTP ausgelösten Funktion bis zur Reaktion auf eine Anfrage bleibt. Dies liegt an dem standardmäßigen Leerlauftimeout von Azure Load Balancer. Für längere Verarbeitungszeiten sollten Sie das asynchrone Muster "Durable Functions " verwenden oder die eigentliche Arbeit zurückstellen und eine sofortige Antwort zurückgeben.
2. Es wird keine maximale Ausführungstimeoutdauer erzwungen. Die an eine Funktionsausführung übergebene Karenzzeit beträgt jedoch 60 Minuten während der Skalierung für die Flex-Verbrauchs- und Premium-Pläne, und während Plattformupdates wird eine Nachfrist von 10 Minuten gewährt.
3. Hierfür muss der App Service-Plan auf Always On festgelegt werden. Während Plattformupdates wird eine Toleranzperiode von 10 Minuten gewährt.
4. Das Standardtimeout für Version 1.x der Functions-Host-Runtime ist unbegrenzt.
5. Wenn die Mindestanzahl von Replikaten auf Null festgelegt ist, hängt das Standardtimeout von den spezifischen Triggern ab, die in der App verwendet werden.