Ich bin ein Neuling in der Cloud-Architektur, habe aber gute Erfahrungen in der Anwendungsentwicklung. Im Moment bin ich dabei, eine große Rechenpipeline über eine Webanwendung für 5-10 Benutzer zugänglicher zu machen und richte das Ganze in AWS ein.
Meine aktuelle Implementierung ist eine leichte React-Webanwendung, die zwei APIs und ein MySQL-Backend verwendet, mit dem Benutzer Jobs mit Parametern in die Warteschlange stellen und über die Webanwendung oder über E-Mails, die den Benutzern nach Abschluss eines Laufs gesendet werden, auf die Endergebnisse zugreifen können.
In der Mitte dieser Pipeline besteht eine Abhängigkeit von einem proprietären Softwareteil, der zur Berechnung dieser Schritte eine sehr leistungsstarke Maschine benötigt (64 GB RAM, 16 Kerne, 1 TB Festplatte) und für nur diesen einen Schritt bis zu 1,5 Tage laufen kann. Dies ist mein größter Flaschenhals der gesamten Pipeline.
Um möglichst viel Kosten zu sparen, versuche ich, den Engpass/Serviceteil skalierbar/kosteneffizient zu machen, indem ich mehrere „Agenten“ für EC2-Instanzen bereithalte, die eingeschaltet werden können, die Schritte ausführen, eine E-Mail senden, in die Datenbank der Web-App schreiben und dann die Instanz über AWS-Lambda-Funktionen stoppen, die durch eine Aktion der Web-App ausgelöst werden.
Ich plane, eine EC2-Instanz für die Web-App, 2 APIs und einen MySQL-Server zu hosten, da die Parallelität/Skalierbarkeit bei diesem Teil sehr gering ist. Ich werde auch noch 1-3 weitere Instanzen für die Engpassdienste haben, um gleichzeitige Läufe von 5-10 Benutzern zu teilen, was bis zu 3 Läufe des schweren Schritts gleichzeitig ermöglichen könnte.
Da die Engpassdienste ähnliche Dateien zum Ausführen der Programme benötigen und die Eingaben für diese Schritte manchmal eine Dateigröße von 150 GB haben können, denke ich darüber nach, entweder EFS- oder S3-Speicher zum Speichern der Eingaben zu verwenden, sodass ich mich nur um die Übertragung der Eingabedateien an einen Ort kümmern muss, der von EC2-Instanzen gemeinsam genutzt werden kann, und ich nicht sicherstellen muss, dass sie gestartet werden, um den Übertragungsschritt durchzuführen. Dies ist ein manueller Teil, für den ich auch noch keine gute Möglichkeit gefunden habe, ihn stärker zu automatisieren, da die Dateigrößen so groß sind.
Meine Fragen lauten: Klingt mein Setup sinnvoll und sehen Sie Lücken in meinen Implementierungsideen? Derzeit verwende ich EBS-Speicher für die Serviceinstanzen, möchte aber die Eingabeorte für die 150 GB-Übertragungen/Wartung minimieren. Ich bin mir auch nicht sicher, was der Unterschied zwischen S3 und EFS ist, da beide mehrere Instanzen montierbar zu sein scheinen, aber welche soll ich verwenden? Und ist es sinnvoll, die Web-App, APIs und die Datenbank auf einer EC2-Instanz zu behalten, wenn ich die Serviceinstanzen benötige, damit sie nach Abschluss in die Datenbank schreiben können? Diese Instanz wäre die ganze Zeit eingeschaltet.
Vielen Dank für Ihre Hilfe und verzeihen Sie mir, wenn ich etwas Naivität gesagt habe.
Antwort1
Ihr Setup klingt vernünftig. Ich würde vorschlagen, dass Sie sich nach einem API-Gateway umsehen, um Ihre API zu „hosten“, und überlegen, ob es für Sie funktioniert. Sie könnten auch erwägen, Ihre hochbelasteten EC2-Instanzen in einer Autoscaling-Gruppe zu haben und Ihre Kontroll-Lambda mit dieser interagieren zu lassen, anstatt direkt mit den Instanzen.
S3 und EFS sind unterschiedliche Datenspeicherlösungen. S3 ist ein Objektspeicher, während EFS ein Dateispeicher ist. S3 ist nicht genau mountbar, obwohl es vielleicht so dargestellt wird, als ob es über verschiedene Dienstprogramme möglich wäre. Ob esrichtigOb Sie S3 oder EFS verwenden, hängt davon ab, wie Sie die dort vorhandenen Dateien verwenden.
Für Ihre Datenbank könnten Sie RDS in Betracht ziehen, möglicherweise mit einer Burst-Instance-Klasse oder einer der serverlosen Optionen. Dies hängt jedoch von Ihrem Budget und Anwendungsfall ab.
Antwort2
Generell empfiehlt es sich, in der Cloud Dienste statt Server zu verwenden. Sie müssen die Kosten im Auge behalten, aber dadurch können Lösungen robuster, schneller und konformer werden.
Zu Ihrer Arbeitsbelastung habe ich ein paar Gedanken:
- Können Sie einen Orchestrator wie AWS Step Functions verwenden, der viele AWS-Lambda-Funktionen aufruft, um die Berechnung durchzuführen? Mir ist bewusst, dass Lambda wahrscheinlich die teuerste Rechenzeit bei AWS ist, also vielleicht nicht ideal. Mit den richtigen Grenzwerten und einer geeigneten Arbeitslast könnten Sie vielleicht 10.000 Lambdas starten und die Arbeit parallel in 15 Minuten erledigen.
- Wie wäre es, statt EFS/S3 ein goldenes EC2-Image/AMI zu erstellen und dann für jeden Job eine Spot-/dynamische EC2-Instanz hochzufahren, die groß genug ist, um die Verarbeitung für diesen einen Job durchzuführen, und dann herunterzufahren, wenn er fertig ist? Lambda könnte den Job vielleicht basierend auf Ereignissen irgendeiner Art orchestrieren? Dadurch würden Datenübertragungsgebühren vermieden – obwohl ich nicht sicher bin, ob sie EBS/S3 in Rechnung gestellt werden oder nicht. Spot-Compute ist ziemlich günstig, und wenn Sie Ihre Region/AZ/Instanzgröße richtig wählen, sollten Unterbrechungen selten sein. Unterbrochene Instanzen werden heruntergefahren und das EBS-Volumen beibehalten, daher würde dies besser funktionieren, wenn Ihr Job regelmäßig auf die Festplatte geschrieben wird und neu gestartet werden kann.
Ich würde wahrscheinlich auch etwas Zeit in die Optimierung dieser riesigen Aufgabe investieren.