Betriebskosten einer HTTP-Schnittstelle reduzieren: Azure Function als Alternative zum App Service Plan

Erfahren Sie in diesem Artikel, wie Sie Ihre Betriebskosten in Azure deutlich reduzieren können, indem Sie statt eines Service Plans auf eine Azure Function setzen. Image by Freepik Beim Entwerfen einer Cloudlösung hat man oft die Wahl zwischen verschiedenen Services, die den gleichen Zweck erfüllen können. Um eine fundierte Entscheidung treffen zu können, stellt sich schnell die Frage nach den Kosten. In diesem Artikel zeigen wir, wie eine kostengünstige HTTP-Schnittstelle erstellt werden kann und auf was dabei zu achten ist, denn gerade im Kontext von Cloudlösungen ergibt sich oft die Möglichkeit, klein zu beginnen und die Lösung im Laufe des Produktzyklus zu skalieren. Grundaufbau der HTTP-Schnittstelle Wir erstellen eine HTTP-Schnittstelle basierend auf einer Azure Function, welche in einem Consumption Plan (Pay as you go) gehostet wird. Vorteil eines Consumption Plan ist, dass nur Kosten anfallen, wenn Rechenleistung benötigt wird. Wir nehmen für dieses Beispiel eine Million API-Aufrufe pro Monat mit einer durchschnittlichen Antwortzeit von 1000 Millisekunden an, um damit die Rechenleistung (und somit die Kosten) ungefähr einzuschätzen. Azure Function in Kombination mit Consumption Plans Bei der Wahl von Azure Functions mit einem Consumption Plan sollte man wissen, dass Azure die CPU-Ressourcen steuert. Wenn diese nicht verwendet werden, werden sie für andere Cloudnutzer freigegeben und stehen uns somit erst nach einem Cold Start wieder zur Verfügung. Dies führt zu erhöhten Latenzen, die vor allem dann stören, wenn Benutzer direkt davon betroffen sind, weil sie z.B. 10 Sekunden auf ihre Anfrage warten müssen. Es gibt keine konkreten Zeitangaben von Microsoft, wann die Ressourcenfreigabe erfolgt und mit welcher konkreten Verzögerung dabei zu rechnen ist. Es gibt jedoch einen hilfreichen Artikel (auf Englisch), der das Verhalten von Azure Functions bei einem Cold Start beschreibt. Mit Ausnahme des Cold Starts unterscheiden sich eine Azure Function und ein App Service in Bezug auf die Funktion als HTTP-Schnittstelle nicht weiter. Wenn sich der Cold Start folglich unterbinden ließe, so würde sich ein entscheidender Vorteil in den Betriebskosten ergeben. Wäre das nicht möglich, so wäre die Verwendung von Azure Functions nur auf Services beschränkt, die für Nutzer von außen nicht zugänglich wären und die erhöhten Latenzen hätten somit keine direkte Auswirkung auf Benutzer. Unterbinden von Cold Starts Um eine performante HTTP-Schnittstelle bereitzustellen, muss bei dieser Architekturentscheidung sichergestellt werden, dass keine regelmäßigen Cold Starts stattfinden. Eine Lösung, um dies zu erreichen, ist die Function regelmäßig aufzurufen und somit das automatisierte Freigeben der Ressourcen von Azure zu unterbinden. Von der Benutzerseite aus kann nicht sichergestellt werden, dass regelmäßig Aufrufe stattfinden. Es gibt aber mindestens zwei Möglichkeiten, wie trotzdem sichergestellt werden kann, dass die Function regelmäßig Aktivitäten hat. Entweder man erstellt eine Timer Triggered Function, die z. B. regelmäßig einen Log Eintrag erstellt, oder es wird ein neuer HTTP-Endpunkt in derselben Function erstellt, der eine einfache Statusroute zur Verfügung stellt. Diese Route wird dann mittels Azure regelmäßig aufgerufen. Wir empfehlen die zweite Variante zu wählen, da diese zwei Funktionen gleichzeitig erfüllt: Die Azure Function wird regelmäßig aufgerufen, um zu unterbinden, dass sie einen Cold Start durchführen muss und es entsteht zeitgleich ein Alerting, falls die Schnittstelle nicht mehr verfügbar ist. Dies bietet sich an, denn die Sicherstellung eines aktiven Monitorings sollte bei einer produktiv eingesetzten Schnittstelle ohnehin gegebener Standard sein. Durch die regelmäßigen Aufrufe der HTTP-Schnittstelle entstehen nun aber mehr Requests, die in Folge Mehrkosten erzeugen können. Führen wir beispielsweise einen Availability Test ein, der alle 5 Minuten einen Request aus 3 Regionen absetzt, so kann die Anzahl der Requests wie folgt auf einen Monat hochgerechnet werden: Diese Zahl muss auf unsere ursprüngliche Annahme von 1 Millionen Requests/Monat aufaddiert werden. Bei dieser Statusroute nehmen wir an, dass dieser Aufruf nicht länger als 1 Sekunden dauert. Welche Kosten entstehen mit dieser Lösung? Mit der von uns aufgezeigten Lösung entstehen für die HTTP-Schnittstelle mit den definierten Aufrufen und Rechenzeiten Kosten i. H. v. ca. 1,82 €. Dabei sind keine weiteren Services berücksichtigt, wie z.B. Storage Accounts, um zusätzliche Daten zu speichern oder Application Insights für das Speichern von Logs. „Was ist nun an diesem Beispiel besonders?“ wird sich nun der eine oder andere Leser fragen. Wenn man einen App Service verwendet und diesen auf einem App Service Plan aufsetzt, der für eine Produktionsumgebung gedacht ist, so entstehen nennenswert höhere Kosten, wie folgendes Beispiel zeigt: Für einen App Service, der auf einem App Service Plan (Windows) mit der Skalierung S1 und einer Instanz läuft, fallen Kosten i. H. v. 66,10€ an. Diese Kosten sind fix und es gibt die Möglichkeit, mehrere Services mit diesem Plan auszuführen. Im Vergleich dazu kann mit dem Consumption Plan nur eine Azure Function ausgeführt werden. Besteht das Produkt also aus mehreren Services, so kann es sich anbieten, diese auf einem gemeinsamen App Service Plan zu hosten. Fazit In diesem Beitrag haben wir eine Azure Function auf einem Consumption Plan betrachtet und den Unterschied zu einem Azure App Service in Bezug auf eine HTTP-Schnittstelle aufgezeigt. Um Kosten zu optimieren ist es wichtig zu verstehen, was bei einer Azure Function unter der Haube passiert und worauf geachtet werden muss (Rechenleistung). Wenn man diese Punkte versteht und in Kombination mit anderen Services verwendet (wie z. B. Availability Tests), kann eine kosteneffiziente Lösung bereitgestellt werden, die alle Anforderungen einer HTTP-Schnittstelle erfüllt. Wir empfehlen bei Services, die nach Nutzung oder Rechenleistung abgerechnet werden, zusätzliche Kosten-Alerts zu erstellen. Möchten auch Sie Ihre bestehende Cloudlösung optimieren?Kommen Sie auf uns zu und lassen uns darüber sprechen, wie wir Ihnen bei der Optimierung behilflich sein können! AIT kontaktieren The post Betriebskosten einer HTTP-Schnittstelle reduzieren: Azure Function als Alternative zum App Service Plan appeared first on AIT GmbH & Co. KG.

zum Artikel gehen

Datenimport von On-Premises-Datenquellen in die Azure-Cloud

Wenn man von der Datenanalyse mit Microsoft Azure hört, stellt man sich unweigerlich einige Fragen: Wie funktioniert die Einrichtung einer Azure-Infrastruktur? Was ist gemeint mit Begriffen wir „Data Lake“ oder „Azure Data Factory“ und wozu braucht man da

zum Artikel gehen

Schulung: Microsoft Azure Virtual Desktop (AVD)

Optional: Allgemeine Einfhrung in Microsoft Azure Modul 1: berblick und Einfhrung 1. Desktop as a Service (DaaS) 2. Von Remote Desktop Services (RDS) zu Windows-Desktops in Azure 3. bersicht ber Azure Virtual Desktop (und Windows 365). 4. Terminolo

zum Artikel gehen

Azure AD Connect und Azure AD Connect Cloud Sync

Um Anmeldedaten zwischen Active Directory und Azure Active Directory zu synchronisieren, verwenden viele Administratoren Azure AD Connect. Wir haben im Beitrag „Azure AD Connect installieren“ bereits beschrieben, wie Sie lokale [] Der Beitrag Azure AD Con

zum Artikel gehen

Azure Active Directory in der Praxis Die ersten Schritte

Mit Azure Active Directory (Azure AD) bietet Microsoft eine cloudbasierte Version von Active Directory. Im Gegensatz zu lokalen Active Directory-Domänen sind für den Einsatz von Azure AD aber keine Domänencontroller [] Der Beitrag Azure Active Directory i

zum Artikel gehen

Azure AD Custom Security Attributes ermöglichen flexible Berechtigungsstrukturen

Bei Azure AD Security Attributes handelt es sich um Schlüssel-Wert-Paare, die in Azure AD benutzerdefiniert erstellt werden können. Dadurch können Benutzern Unternehmensanwendungen oder verschiedene Azure-Ressourcen (z. Bsp. bestimmte Werte wie [] Der Bei

zum Artikel gehen