Ich bin ein Dev-Ops-Webentwickler mit einer Site, auf der zwei ec2.smalls hinter einem Load Balancer auf AWS laufen.
Vor Kurzem haben wir festgestellt, dass 3–4 Anfragen pro Sekunde die Site unseres Kunden lahmlegten.
Die Site war ausgefallen und konnte nach mehreren Serverneustarts und Fehlerprotokollscans nach Skripts, die das Problem verursachen könnten, nicht wiederhergestellt werden, obwohl in letzter Zeit keine Änderungen vorgenommen wurden.
Nachdem ich die Protokollierung des Lastenausgleichs aktiviert hatte, sah ich, dass Tausende von Anfragen an eine einzige Seite von einer einzigen IP-Adresse kamen.
Wir haben die Anfrage vom Load Balancer per X-Forwarded-for an den Anfrage-verarbeitenden Server weitergeleitet und die IP per .htaccess-Regel blockiert.
Während der Kommunikation mit der IT des Kunden wurde diesem mitgeteilt, dass es sich bei der für die Flut an Anfragen verantwortlichen IP-Adresse tatsächlich um einen seiner internen Firmencomputer handelte.
Der betroffene Rechner wurde per Fernzugriff neugestartet und alle Anfragen wurden gestoppt. Die Site kam wieder online.
Die offizielle Erklärung hierfür war: „Der Computer ist ausgerastet.“
Ist es möglich, dass ein Webbrowser oder ein Windows-Computer 3–4 Anfragen pro Sekunde an eine lastausgeglichene Webseite stellt und diese dann für über 5 Stunden ausfällt?
So sahen die Anfragen aus:
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
Antwort1
Natürlich ist das möglich, es hängt jedoch von mehreren Faktoren ab:
1) Es klingt, als ob die serverseitige Anwendung Probleme mit der Parallelität hat. Es könnte sich lohnen, zu prüfen, ob die Anwendungsserver der Engpass waren oder ob es Upstream-Probleme wie die DBs und die Anwendungsserver waren, denen der Speicher ausging, weil die Apache-Konfiguration die Threads nicht schnell genug leerte. Wenn es die Anwendungsserver waren, könnte es sich lohnen, einige Anpassungen vorzunehmen – starten Sie eine identische Maschine außerhalb des ELB und verwenden Sie JMeter, um sie mit etwas Last zu beladen und die Engpässe herauszufinden.
Wenn es die Datenbank war, können Sie möglicherweise Memcache/Elasticache verwenden (da es so aussieht, als würden Sie ein bestimmtes Objekt abrufen), um die tatsächlichen Abfragen zwischenzuspeichern. Auf diese Weise reagieren die Datenbankverbindungen schnell, Apache kann schnell reagieren und Threads beenden, anstatt den Speicherpool des Anwendungscomputers zu füllen.
Wenn Sie sich wirklich gefährdet fühlen, können Sie Varnish vorinstallieren, um die Anfragen mit einer TTL von 1–5 Sekunden zwischenzuspeichern und so eine große Anfrageflut zu verhindern. Aber seien Sie vorsichtig, denn VCL ist gnadenlos und kann zu großen Problemen und Ärgernissen führen (Cache-Poisoning/Cache-Leckage).
2) Was die „betroffene“ Maschine selbst betrifft. Offensichtlich könnte sie kompromittiert worden sein – das sollte auf jeden Fall untersucht werden. Ich überlasse es Ihnen zu entscheiden, ob der IT-Typ ehrlich ist oder nicht – das liegt außerhalb des Bereichs eines Serverfehlers.
Vorausgesetzt, es wurde nicht kompromittiert, könnte es sich um fehlerhaften JavaScript-Code gehandelt haben. Wenn Sie Polling-Aktualisierungen durchführen und ein Zeitparameter irgendwie geändert wurde, könnte es durchaus dazu kommen, dass viele Anfragen pro Sekunde gesendet werden. Ebenso kann sich das JS gut verhalten haben, aber die Person hat möglicherweise 25 Tabs geöffnet und ist abends nach Hause gegangen. Wenn jeder Tab 1 Anfrage pro 5 Sekunden sendet, sind das 5 Anfragen/Sekunde.