Questa è una versione PDF del contenuto. Per la versione completa e aggiornata, visita:
Verrai reindirizzato automaticamente...
In der heutigen Cloud-Computing-Landschaft ist die Serverless-Kostenoptimierung nicht mehr nur eine Frage der Einsparung, sondern eine echte Ingenieursdisziplin, die notwendig ist, um die Nachhaltigkeit des Unternehmens zu gewährleisten. Stellen wir uns das Szenario von MutuiperlaCasa vor, einer hochfrequentierten Plattform für Hypothekenvergleiche. Bis gestern basierte die Infrastruktur auf Clustern von ständig aktiven EC2-Instanzen, die für die Bewältigung der Verkehrsspitzen am Montagmorgen dimensioniert waren, aber nachts und an Wochenenden weitgehend ungenutzt blieben. Das Ergebnis? Eine Verschwendung von Ressourcen und untragbare OPEX (Betriebskosten).
In diesem technischen Leitfaden analysieren wir, wie die Einführung einer FinOps-Mentalität, angewendet auf eine Serverless-Architektur auf AWS, das Kostenmodell radikal verändern und die Ausgaben um bis zu 60% senken kann, ohne die Leistung zu beeinträchtigen. Wir werden fortschrittliche Lösungen für den Umgang mit Cold Starts, die intelligente Orchestrierung von Workflows und die Nutzung von Spot-Rechenkapazitäten untersuchen.
Der erste Schritt zur Serverless-Kostenoptimierung besteht darin zu verstehen, wo die Ineffizienz liegt. In einer traditionellen Architektur, die auf VMs (Virtual Machines) basiert, zahlt man für die reservierte Kapazität, unabhängig von der tatsächlichen Nutzung. In einem Serverless-Modell zahlt man für den Aufruf und die Dauer der Ausführung.
Für MutuiperlaCasa bedeutete die Migration die Zerlegung des Java-Monolithen in auf AWS Lambda basierende Microservices. Das einfache «Lift-and-Shift» des Codes in Lambda-Funktionen garantiert jedoch nicht automatisch Einsparungen. Ohne angemessenes Tuning riskiert man aufgrund falscher Speicherkonfigurationen oder verlängerter Ausführungszeiten sogar höhere Ausgaben.
Eines der Haupthindernisse für die Einführung von Lambda für benutzerorientierte Anwendungen (wie einen Echtzeit-Hypothekenrechner) ist das Problem des Cold Start. Wenn eine Funktion längere Zeit nicht aufgerufen wurde, muss der Cloud-Provider die Ausführungsumgebung initialisieren, den Code herunterladen und die Runtime starten. Bei Sprachen wie Java (die im Bankensektor wegen ihrer Robustheit oft verwendet werden) kann dies zu Latenzen von mehreren Sekunden führen.
Um dieses Problem zu mildern, ohne auf die teure Provisioned Concurrency zurückzugreifen (die faktisch wieder Fixkosten ähnlich wie bei EC2 einführt), ist die Nutzung von AWS Lambda SnapStart die Erfolgsstrategie. Diese Technologie, verfügbar für verwaltete Java-Runtimes, erstellt einen Snapshot des Speichers und des Festplattenzustands der initialisierten Funktion und speichert ihn im Cache.
Trotz SnapStart gibt es kritische Szenarien, in denen Variabilität nicht tolerierbar ist. Für die Kerndienste von MutuiperlaCasa, wie die Login-API, kann eine hybride Strategie angewendet werden: Nutzung von Application Auto Scaling zur Anpassung der Provisioned Concurrency basierend auf vorhersehbaren Zeitplänen (z. B. Erhöhung der Kapazität um 08:00 Uhr und Reduzierung um 20:00 Uhr). Dies balanciert Leistungsgarantie und Kostenkontrolle.
Ein häufiger Fehler bei der Serverless-Kostenoptimierung ist die Verwendung von Lambda-Funktionen, um auf Antworten externer Dienste zu warten. Im Fall von MutuiperlaCasa erfordert die Prüfung der Kreditwürdigkeit Abfragen an externe Systeme (z. B. Schufa oder Zentralregister), die zwischen 30 Sekunden und mehreren Minuten dauern können.
Würden wir eine Lambda verwenden, um auf diese Antwort zu warten, würden wir für die gesamte «Idle»-Zeit (Wartezeit) bezahlen. Die korrekte technische Lösung ist die Verwendung von AWS Step Functions.
Zur Kostenoptimierung ist die Wahl des richtigen Workflow-Typs entscheidend:
Durch die Implementierung von Standard Workflows für asynchrone Aufrufe hat MutuiperlaCasa Tausende von «leeren» Lambda-Ausführungsstunden eliminiert und die Rechenkosten für diese Prozesse um 90% gesenkt.
Nicht alles kann eine Lambda-Funktion sein. Das Generieren von PDF-Berichten der Verträge oder die Verarbeitung nächtlicher Logs sind Aufgaben, die lange Zeiten und konstante Ressourcen erfordern. Hier kommt AWS Fargate ins Spiel, die Serverless-Engine für Container.
Um die Serverless-Kostenoptimierung zu maximieren, sieht die Strategie die ausschließliche Nutzung von Fargate Spot vor. Spot-Instanzen nutzen die ungenutzte Kapazität von AWS und bieten Rabatte von bis zu 70% im Vergleich zum On-Demand-Preis.
Der einzige Nachteil von Spot-Instanzen ist, dass sie mit einer Vorwarnzeit von zwei Minuten beendet werden können, wenn AWS die Ressourcen benötigt. Um dies in einer Produktionsumgebung zu handhaben:
SIGTERM im Container, um den Zustand (Checkpointing) auf Amazon S3 oder DynamoDB vor dem Schließen zu speichern.Die rigorose Anwendung dieser Strategien zur Serverless-Kostenoptimierung führte zu folgenden Ergebnissen für MutuiperlaCasa:
Die Einführung von Serverless ist kein Zauberstab für Kosten, sondern ein mächtiges Werkzeug, wenn es von soliden FinOps-Prinzipien geleitet wird. Der Schlüssel zum Erfolg liegt im Verständnis der Nuancen der Preismodelle (wie der Unterschied zwischen Bezahlung nach Dauer vs. Übergang) und in der Architektur der Software, um diese Unterschiede zu nutzen. Für Fintech-Unternehmen wie MutuiperlaCasa setzt dieser Ansatz nicht nur wirtschaftliche Ressourcen frei, sondern ermöglicht es auch, unendlich zu skalieren und dabei gesunde Gewinnmargen zu erhalten.
Serverless FinOps ist eine Disziplin, die Prinzipien des Finanzmanagements auf Serverless-Cloud-Architekturen anwendet und die Kostenoptimierung in eine Ingenieurspraxis verwandelt. Der Hauptvorteil liegt im Übergang von einem Modell fester Ausgaben, das auf reservierter Kapazität basiert, zu einem Pay-per-Use-Modell, bei dem man nur für die tatsächliche Ausführung des Codes zahlt. Dieser Ansatz ermöglicht es, Verschwendung durch inaktive Ressourcen zu eliminieren und die Betriebskosten drastisch zu senken, oft um bis zu 60% im Vergleich zu traditionellen Infrastrukturen.
Um die Fixkosten der Provisioned Concurrency zu vermeiden und dennoch eine hohe Leistung beizubehalten, ist die beste Strategie die Verwendung von AWS Lambda SnapStart, insbesondere für Runtimes wie Java. Diese Technologie erstellt und speichert einen Snapshot der initialisierten Ausführungsumgebung, sodass die Funktion zum Zeitpunkt der Anfrage fast augenblicklich starten kann. Auf diese Weise erhält man minimale Latenzen und zahlt nur für Standardaufrufe, ohne ständig aktive Instanzen unterhalten zu müssen.
Die Verwendung von Lambda-Funktionen zum Warten auf Antworten von externen Diensten oder langen Prozessen ist finanziell ineffizient, da man für die gesamte Zeit des inaktiven Wartens bezahlt. AWS Step Functions, insbesondere mit Standard Workflows, löst dieses Problem, indem es ermöglicht, die Ausführung ohne zusätzliche Kosten zu pausieren, bis eine externe Antwort empfangen wird. Man zahlt nur für die Zustandsübergänge und nicht für die Dauer des Wartens, was zu erheblichen Einsparungen bei asynchronen Prozessen führt.
AWS Fargate Spot ist ideal für Aufgaben, die keine sofortige Ausführung oder absolute Kontinuität erfordern, wie z. B. die Batch-Verarbeitung von Daten, die Erstellung von Berichten oder die Log-Analyse. Es bietet Rabatte von bis zu 70% gegenüber den On-Demand-Tarifen, indem es die ungenutzte Kapazität der Cloud nutzt. Da die Instanzen jedoch kurzfristig unterbrochen werden können, ist es entscheidend, dass die Anwendungen stateless sind und ihren Zustand speichern können, um die Arbeit im Falle einer Unterbrechung wiederaufzunehmen.
Eine einfache direkte Migration des Codes, bekannt als Lift-and-Shift, ohne angemessenes Tuning kann paradoxerweise die Kosten erhöhen, anstatt sie zu senken. Die Hauptrisiken umfassen falsche Speicherkonfigurationen, die die Abrechnungsdauer verlängern, und die unsachgemäße Verwendung von Lambda-Funktionen für Warteaufgaben. Um Einsparungen zu gewährleisten, ist es notwendig, die Architektur unter Nutzung spezifischer Dienste für die Orchestrierung neu zu gestalten und die Ausführungszeiten des Codes zu optimieren.