June 9, 2025
Das Problem: Wenn Serverless anfängt, seine Grenzen zu zeigen
Unsere Reise begann mit AWS Lambda, einem leistungsstarken Tool für schnelle Bereitstellung und mühelose Skalierung. Es war in unserer Anfangsphase die perfekte Lösung, da es einfach zu bedienen war und einen geringen Betriebsaufwand bot. Aber als unser System reifte, zeigten sich Risse.
- Kaltstarts: Die Kaltstartlatenz von Lambda machte sich bei Diensten bemerkbar, die niedrige Reaktionszeiten erforderten, insbesondere bei sporadischem Verkehr.
- Beschränkungen der Ressourcen: Speicher- und Ausführungszeitbeschränkungen schränkten unsere Fähigkeit ein, komplexere oder länger laufende Workloads auszuführen.
- Verwaltung von Abhängigkeiten: Als unsere Anwendungen immer komplexer wurden, wurde die Verwaltung großer oder spezialisierter Abhängigkeiten innerhalb von Lambda-Funktionen umständlich.
Als immer mehr Kunden die FloQast-Plattform nutzten und immer größere und komplexere Datensätze mitbrachten, spürten wir die Belastung durch die Einschränkungen von Lambda mehr denn je.
Ein Beispiel für die Schmerzen unserer Kunden
Beim Export von Datensätzen mit rund 5.000 Elementen stießen wir auf ein kritisches Problem. Unsere Lambda-Funktionen stießen ständig an Speichergrenzen, was sporadisch zu 502-Fehlern bei Kunden führte. Darüber hinaus würde es im Erfolgsfall durchschnittlich 18 Sekunden dauern, bis der Kunde den Bericht erhält. Angesichts des rasant wachsenden Kundendatenvolumens wussten wir, dass sich dieses Problem nur noch verschärfen würde. Es wurde klar, dass wir eine skalierbarere und robustere Lösung brauchten — und zwar schnell.
Die Lösung: Migration zu AWS ECS
Um die Einschränkungen zu überwinden, mit denen wir bei AWS Lambda konfrontiert waren, haben wir unsere Workloads migriert auf AWS ECS (Elastischer Containerdienst). ECS bot die Kontrolle, Flexibilität und Skalierbarkeit, die wir für die Weiterentwicklung unserer Systeme benötigten.
So hat ECS unsere wichtigsten Herausforderungen gelöst:
- Keine Kaltstarts mehr: Mit ECS werden unsere Dienste als langlebige Container ausgeführt, wodurch die Kaltstartlatenz vollständig entfällt. Dies führte zu schnelleren Reaktionszeiten und einer verbesserten Benutzererfahrung, insbesondere bei latenzempfindlichen Endpunkten.
- Flexible Ressourcenzuweisung: Mit ECS konnten wir die CPU- und Speicherkonfigurationen für jeden Container feinabstimmen. Wir könnten jetzt anspruchsvollere Prozesse ausführen, ohne uns Sorgen machen zu müssen, an harte Grenzen zu stoßen.
- Besseres Abhängigkeitsmanagement: Durch die Containerisierung unserer Anwendungen erhielten wir die volle Kontrolle über die Laufzeitumgebung. Komplexe Abhängigkeiten und native Bibliotheken könnten einmal gepackt und konsistent in allen Umgebungen ausgeführt werden.
Die Ergebnisse: Erfolgreiche ECS-Migration
Nach sorgfältiger Planung und Ausführung haben wir unsere kritischen Services erfolgreich auf AWS ECS migriert. Dies war nicht nur eine Änderung der Infrastruktur — es war eine Gelegenheit, unsere Codebasis und Bereitstellungspipeline zu modernisieren. Der Übergang umfasste drei wichtige Schritte:
- Modernisierung der Codebasis: Im Rahmen der Migration haben wir von JavaScript auf TypeScript umgestellt. Dies verbesserte die Typsicherheit, die Produktivität der Entwickler und die langfristige Wartbarkeit.
- Containerisierung von Diensten: Wir haben unsere Anwendung in Docker-Container gepackt. Dies verbesserte nicht nur die Qualität, indem ein konsistentes Laufzeitverhalten in allen Umgebungen gewährleistet wurde, sondern es vereinfachte auch die lokale Entwicklungseinrichtung und ein schnelleres Onboarding von Entwicklern.
- Bereitstellung auf ECS: Wir haben ECS-Cluster und -Services eingerichtet, sie in unsere CI/CD-Pipeline integriert und den neuen Bereitstellungsprozess gründlich getestet, um Zuverlässigkeit und Skalierbarkeit sicherzustellen.
Wie bei jeder Infrastrukturänderung war diese Migration mit Kompromissen verbunden. Zu den wichtigsten Herausforderungen, mit denen wir konfrontiert waren, gehörten:
- Skalierungsgeschwindigkeit: Eine Einschränkung, auf die wir bei ECS gestoßen sind, ist die langsamere Reaktionszeit bei der Skalierung unter hoher Last. Als wir den Service an seine Grenzen brachten, beobachteten wir merkliche Verzögerungen beim Hochfahren neuer Instances, um fehlerhafte Instanzen zu ersetzen. Dies führt zu potenziellen Ausfallzeiten bei Spitzennachfrage, und das müssen wir berücksichtigen — insbesondere, wenn wir uns darauf vorbereiten, deutlich größere Kunden an Bord zu holen.
- Erhöhter Konfigurationsaufwand: Im Gegensatz zu Lambda, das die meisten Infrastrukturdetails abstrahiert, verlangt ECS von Entwicklern die Verwaltung und Feinabstimmung einer Vielzahl von Einstellungen — wie CPU-/Speicherzuweisung, Aufgabendefinitionen, Netzwerkmodi und Skalierungsrichtlinien. Diese zusätzliche Komplexität kann die Entwicklung verlangsamen und erfordert ein besseres operatives Bewusstsein.
Es dauerte nicht lange, bis sowohl die Leistung als auch die Stabilität zunahmen! 🥳🎉
Hier sind einige wichtige Vorteile, die wir nach der Migration beobachtet haben:
- Verbesserte Leistung: Die Eliminierung von Kaltstarts führte zu einer erheblichen Latenzreduzierung. In den Exportzeiten konnten wir Effizienzsteigerungen von bis zu 76% verzeichnen! 🚀
- Erhöhte Stabilität: Konsistente Ressourcenverfügbarkeit führte zu stabileren Diensten (keine 502 mehr!). Seit der Veröffentlichung wurden in unseren Logs keine Abstürze festgestellt.
- Verbessertes Management: Die Containerisierung vereinfachte Bereitstellungen und Updates.
Zusammenfassend lässt sich sagen, dass die Migration von AWS Lambda zu AWS ECS eine robuste und skalierbare Grundlage für unsere Infrastruktur bot. Dadurch wurden wichtige Einschränkungen behoben und die Systemleistung und Verwaltbarkeit erheblich verbessert. Noch wichtiger ist, dass wir so in die Lage versetzt werden, den wachsenden Umfang und die Komplexität von Unternehmenskundendaten sowohl jetzt als auch in Zukunft mit Zuversicht zu unterstützen.