Running Batch Jobs auf Amazon ECS

Question

Ich bin sehr neu in der Verwendung von AWS, und noch mehr für ECS. Zurzeit habe ich eine Anwendung entwickelt, die eine S3-Verbindung herstellen, die Daten von dieser Verbindung herunterladen, die Daten verarbeiten und dann einige Informationen über diese Daten ausgeben kann. Ich habe diese Anwendung bereits in einem Andock-Container verpackt und befindet sich nun in der Amazon Container-Registrierung. Ich möchte jetzt einen Cluster starten, einen S3-Link an jede EC2-Instanz senden, auf der Docker läuft, alle Container-Instanzen die Nummern knacken lassen und alle Ergebnisse an einen einzelnen Knoten zurückgeben. Ich verstehe nicht ganz, wie ich meine Bewerbung an dieser Stelle ändern soll. Muss ich meine Anwendung im Docker-Container einen Dienst ausführen lassen? Oder sollte ich einfach per ssh Befehle an Container senden? Wenn ich so weit komme, wie kommuniziere ich dann mit dem Cluster, um die Arbeit für möglicherweise Hunderte von S3-Links zu bewirtschaften? Im Idealfall möchte ich, da meine Anwendung sehr rechenintensiv ist, nur einen Container pro EC2-Instanz ausführen.

Danke!

Answer 1

Ihre Geschichte ist schwer zu beantworten, da es viele Fragen ohne viel Forschung gibt.

Mein erster Gedanke ist es, es komplett staatenlos zu machen.

Sie sind auf dem richtigen Weg, indem Sie sie über S3 starten und verarbeiten. Sie sollten dies erweitern, um etwas wie eine SQS-Warteschlange zu verwenden. Diese SQS-Nachrichten würden eine S3-Verbindung enthalten. Ihre Anwendung wird gestartet, Sie erhalten eine Nachricht von SQS, verarbeiten den erhaltenen Link und löschen die Nachricht.

Die nächste Sache ist, nicht zu einer Konsole irgendeiner Art auszugeben. Gib es woanders aus. Wie eine andere SQS-Warteschlange oder irgendwo.

Damit entfällt die Notwendigkeit, dass die Boxen miteinander kommunizieren. Dies wird die Dinge beschleunigen, sie unendlich skalierbar machen und die seltsamen Hacks entfernen, die sie dazu bringen, miteinander zu kommunizieren.

Warum auch ein Container pro Instanz? 2 Fäden bei 50% sind normalerweise gleich 1 bei 100%. Entfernen Sie diese Anforderung und Sie können ECS + Lambda + Cloudwatch basierend auf der Anzahl der Nachrichten skalieren. > 10000, vergrößern, so etwas. < 100 herunterskalieren. Das bedeutet, dass Sie Millionen von Nachrichten in SQS werfen können und ECS einfach skalieren können, um sie zu verarbeiten und an anderer Stelle auszugeben.

Answer 2

Ich stimme Marc Young zu, Sie müssen dies statuslos machen und die Kommunikationsschicht von der App entkoppeln.

Für eine Anwendung wie diese würde ich die S3-Links in eine Warteschlange (RabbitMQ ist eine gute, ich persönlich nicht SQS, aber es ist auch eine Option) setzen. Lassen Sie dann Ihre Worker-Knoten in ECS Nachrichten aus der Warteschlange ziehen und verarbeiten.

Es klingt wie Sie haben eine andere App, die Verarbeitung verarbeitet. Abhängig von der Ausgabe könnten Sie das Ergebnis dann in eine andere Verarbeitungswarteschlange legen und dasselbe Modell verwenden oder es direkt in eine Datenbank einfügen (oder als Dateien in S3).

Zusätzlich zu dem, was Marc über Autoscaling sagte, sollten Sie cloudwatch + spot-Instanzen verwenden, um die Kosten Ihrer ECS-Container-Instanzen zu verwalten. Insbesondere für schwere Rechenaufgaben können Sie auf diese Weise große Rabatte erhalten.