Ergebnisse auf einen Blick

• Server skalieren automatisch basierend auf aktueller Last
• Bessere Wartbarkeit durch Infrastructure as Code mit AWS CDK
• Kritische Module laufen Serverless alle anderen skalieren automatisch

Herausforderung

Das Unternehmen betreibt ein eigens entwickeltes 3D-Optimierungstool namens RapidPipeline, das zuvor unter dem Namen RapidCompact bekannt war. Die Plattform verarbeitet 3D-Modelle für Kunden über eine Kombination aus Worker-Servern und API-Servern. Diese Infrastruktur stand vor folgenden Herausforderungen:

• Spitzenlasten: Ein einzelner Nutzer kann hunderte von 3D-Modellen gleichzeitig hochladen, was zu plötzlichen Spitzenlasten führt.
• Skalierung und Kosten: Die Server müssen dynamisch skalieren, um eine optimale Leistung bei minimalen Kosten zu gewährleisten.
• Performance: Kundenseitig sollten Wartezeiten reduziert werden, damit mehr Anfragen parallel verarbeitet werden können.

Unsere Lösung

Nach einer detaillierten Analyse der bestehenden Infrastruktur wurden folgende Maßnahmen umgesetzt:

1. Implementierung von Auto Scaling Groups: Sowohl für die Worker-Server als auch für die API-Server wurden Auto Scaling Groups eingerichtet, um die Serveranzahl automatisch an die aktuelle Last anzupassen.
2. Serverless-Architektur: Kritische Teile der Infrastruktur wurden aus dem Monolithen ausgelagert und als eigenständiger Service mit API Gateway und AWS Lambda bereitgestellt. Dies gewährleistet hohe Verfügbarkeit und niedrige Antwortzeiten.
3. Containerisierung: Der Workload wurde als Container auf EC2-Instanzen innerhalb von Auto Scaling Groups bereitgestellt, um ein robustes und wiederholbares Deployment zu gewährleisten. Das gleiche Vorgehen wurde für die API Server umgesetzt.
4. Skalierbare API : Die API-Server wurden mit Loadbalancer und Auto Scaling Groups ausgestattet, um Anfragen dynamisch zu verteilen und die Skalierbarkeit zu maximieren.

Stand Vorher

• Einzelne API- und Worker-Server
• Keine automatische Skalierung basierend auf Last
• Instanzen manuell verwaltet
• Kritische Endpunkte als Teil der Hauptanwendung

Vor der Umsetzung der neuen Architektur war es schwierig, auf verschiedene Lastanforderungen Rücksicht zu nehmen. Neue Server mussten manuell zugeschaltet werden und die Rechenleistung wurde nicht effizient genutzt.

Beispielsweise mussten Instanzen per CLI Command hochgefahren werden, wenn die Menge der Jobs in der Queue zu hoch wurde. Es gab dafür keine Automation.

Stand Nachher

• API- und Worker-Server skalieren automatisch je nach Last
• Es fallen nur Serverkosten an, wenn die Rechenleistung gebraucht wird
• Deployments können bequem und robust per git-push erledigt werden
• Kritische Endpunkte in Lambda ausgelagert für sehr hohe Verfügbarkeit

Mit der Einführung von Auto Scaling Groups (ASGs) und der damit einhergehenden Konfiguration ist es nicht länger nötig, Server auf Verdacht laufen zu lassen. Wenn die Last ein definiertes Maß übersteigt, werden automatisch weitere Server dazugeschaltet und danach auch wieder heruntergefahren. Kritische Teile der Infrastruktur wurden ausgelagert und werden Serverless mittels AWS Lambda ausgeführt. Das sorgt dafür, dass diese Operationen von potentiellen Downtimes der Hauptapplikation komplett ausgenommen sind. Das sorgt dafür, dass die Kosten reduziert werden, während unerwartete Lastspitzen abgefangen werden.

Darüber hinaus wurde die gesamte Infrastruktur auf CDK umgezogen, sodass jede Änderung durch ein Code Review gehen kann und damit das gesamte System resistenter gegen Ausfälle wird.

Die Infrastruktur ist nun fähig, sich an verschiedene Lastszenarien optimal anzupassen, um die Kosten gering zu halten und die Wartezeiten zu minimieren.