Was passiert, wenn ein Mitglied der Autoscaling-Gruppe aws gelöscht wird und herausragende Spring-Async-Threads dabei sind?

Question

Ich habe eine Spring App, die heute @Async Methoden verwendet, um einige nicht wesentliche, aber informative Sachen zu kümmern. Es funktioniert großartig.

Ich möchte eine neue Verarbeitung in diese Ecke der App verschieben, aber ich verstehe nicht ganz, was in der ec2-Instanz passieren würde, auf der sie ausgeführt wird, wenn sie über AWS heruntergefahren wird.

Diese App läuft auf Tomcat 8 in AWS als Teil einer Autoscaling-Gruppe. Wir setzen häufig ein und skalieren oft hoch und runter, so dass die Maschinenbeendigung Routine ist. Ich verstehe, dass dies dazu führen kann, dass einige Threads mitten im Stream angehalten werden, und das ist akzeptabel.

Vorhandener Anwendungsfall: "Berichte über die letzte Stunde an die mittlere Verwaltung über Slack melden."

Ich verstehe, dass ein Herunterfahren der Maschine verursachen kann, dass Slack-Nachricht nicht gebucht wird, und das ist in Ordnung. Es ist nur das mittlere Management.

Neuer Anwendungsfall: "Melden Sie die Verkäufe für den letzten Tag täglich um 5:00 Uhr per E-Mail an die Geschäftsleitung."

Wenn dieser Bericht lange dauert, ist es viel wahrscheinlicher, dass der laufende Thread angehalten wird, wenn das Netzkabel gezogen wird.

Ich weiß, wie man sich dagegen wehren und Dinge "atomar" über Redis etc machen kann, aber das skaliert nicht zu kontinuierlichem Versagen oder wenn die Dauer der Aufgabe die ec2-Lebensdauer übersteigt, und ich würde gerne ein tieferes Verständnis davon bekommen Ein "shutdown" -Befehl der ec2-Instanz wirkt sich auf einen jvm-Thread während des Flugs aus, der gerade Code über einen Methodenaufruf @Async ausführt.

Ich möchte diese Dinge in Lambda oder irgendetwas anderes Out-of-Band nicht ausführen, weil unsere Domäne in dieser Codebasis ist und häufig aktualisiert wird.

Ich habe zu diesem Thema ein wenig gegoogelt, und fast alle Ergebnisse ergeben Themen ihrer App-Container nicht Herunterfahren in diesem Szenario, das ist das Gegenteil der Informationen, die ich suche.

Danke!

-neil

Answer 1

Art Hacky klingende Antwort, aber unter der Annahme, die kritische @Async Verarbeitung in jedes Feld passieren kann (oder geschieht mit allen Boxen), dann können Sie nur die Instanz, die aws anrufen CLI, wenn es beginnt kritische Verarbeitung und ruft es erneut, wenn es fertig ist? Es sollte Instanzschutz auf diese Weise aktivieren können.

http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingBehavior.InstanceTermination.html#instance-protection-instance

Verwenden Sie die folgende Update-Auto-Scaling-Gruppe Befehlsinstanz Schutz für die angegebene Auto Scaling-Gruppe aktivieren:

aws autoscaling set-instance-protection --instance-ids i-5f2e8a0d --auto-scaling-group-name my-asg --protected-from-scale-in 

Und an anderer Stelle im Dokument:

Wenn alle Instanzen in einer Auto Scaling-Gruppe vor Term geschützt sind Während des Einskalierens und während des Scale-In-Ereignisses verringert Auto Scaling die gewünschte Kapazität.Auto Scaling kann jedoch die erforderliche Anzahl von Instanzen nicht beenden, bis ihre Instanzschutzeinstellungen deaktiviert sind.

Der Instanzenschutz schützt Auto Scaling-Instanzen nicht vor manuellen Beendigungen über die Amazon EC2-Konsole, den Befehl "terminate-instances" oder die API "TerminateInstances". Der Instanzenschutz schützt eine Auto Scaling-Instanz nicht vor Beendigung, wenn sie die Integritätsprüfung nicht besteht und ersetzt werden muss. Außerdem schützt der Instanzenschutz Spot-Instanzen in einer Auto Scaling-Gruppe nicht vor Unterbrechungen.

---

Alternativ kann, wenn nur ein Feld, um es ausführen muss, sollte es möglich sein, eine einzige dedizierte Instanz alsBearbeitungskasten geschützt zu haben, und Sie müssen nur darauf achten, dass diese Instanz das ist eine, die Ihre kritische asynchrone Verarbeitung durchführt.

Answer 2

Es gibt einige Dinge zu beachten:

1. Beantwortung direkt Ihre Frage:

   Was passiert, wenn ein aws automatische Skalierung Gruppenmitglied zerstört und gibt es hervorragende Frühling async Fäden tun Sachen?

   Threads erhalten InterruptedException.

2. Das Szenario, das Sie beschreiben, ist nicht wirklich für Auto-Skalierungsinstanzen geeignet. Diese wurden für den Verkehr entwickelt. In Ihrem Szenario geht es mehr um die Jobverarbeitung. Eine dedizierte (vielleicht geplante) Instanz (Flotte) ist dafür besser geeignet. Wenn Sie viele davon ausführen müssen, können Sie Spot-Instanzen planen, um Kosten zu sparen. Wenn Sie die Jobs in der Regel auf den Traffic-Handling-Maschinen ausführen, klingt es so, als würden Sie Bedenken in der Anwendung mischen, besser aufteilen.

3. Innerhalb der Instanz würde ich die Anwendung ausführen, die einige Zustandsverwaltung für Aufträge ausführt. Sie können es selbst schreiben, indem Sie dauerhaften Speicher wie DynamoDB verwenden (gut Elasticache ist in Ordnung, aber was ist, wenn das scheitert?), Oder lassen Sie es von anderen Tools tun (wie Oozie, Chronos/Airflow, je nachdem, welche Sprache Sie bevorzugen).

   Wenn Sie sich selbst implementieren würden, gäbe es für jedes Berichtsintervall einen Datensatz (sagen wir mal einen Tag). Die Zustandsmaschine wäre: Not Running (das gleiche wie nicht vorhanden), Running, Failed, Done. Alle außer hätten den letzten Update-Zeitstempel, der in regelmäßigen Abständen für laufende Jobs fortlaufend aktualisiert würde. Es würde auch die Instanz/Prozess/Thread-Kennung geben, wer den laufenden Job besitzt. Wenn der Job als ausgeführt markiert ist, aber das Update für mehr als X Intervalle fehlt, können Sie den vorherigen Runner als fehlgeschlagen deklarieren, und die nächste Instanz, die dies beobachtet, kann den Besitz dieses Jobs übernehmen (den Besitzer aktualisieren).