In diesem Beitrag möchten wir Ihnen die Details der Dienstunterbrechung mitteilen, die am 25. November 2020 in der Region Northern Virginia (US-EAST-1) aufgetreten ist.
Amazon Kinesis sammelt, verarbeitet und analysiert Streaming-Daten in Echtzeit. Neben der direkten Nutzung durch Kunden ist es an einer Reihe von AWS-Services beteiligt. Diese Dienste litten auch unter einem Ausfall. Der Auslöser (aber nicht die Hauptursache) dieses Ereignisses war die relativ geringe Kapazitätserweiterung des Dienstes, die um 2:44 Uhr PST begann und um 3:47 Uhr endete.
Über das Kinesis-Gerät
Kinesis verwendet eine große Anzahl von "Back-End" -Clustern von Zellen (Zellen), die Datenströme verarbeiten. Dies sind die Arbeitspferde von Kinesis. Sie sind für die Verteilung, den Zugriff und die Skalierung für das Streaming verantwortlich. Streams werden von Front-End-Servern mithilfe von Sharding an Back-End-Server verteilt. Der Backend-Cluster "besitzt" viele Shards und bietet eine konsistente Skalierung und Fehlerisolierung. Die Front-End-Arbeit ist in unserem Fall klein, aber wichtig. Es ist für die Authentifizierung, Drosselung und Weiterleitung von Anforderungen an die richtigen Thread-Shards in Backend-Clustern verantwortlich.
Wir haben die Front-End-Maschinenflotte um neue Kapazitäten erweitert. Jeder Front-End-Server bildet einen Datencache, einschließlich Mitgliedschafts- und Shard-Besitzern (zwischen Back-End-Clustern), und bildet eine sogenannte Shard-Map. Diese Informationen werden abgerufen, indem Anforderungen an den Dienst gesendet werden, der Mitgliedschaftsinformationen bereitstellt, und Konfigurationsdaten aus DynamoDB abgerufen werden.
Darüber hinaus verarbeitet jeder Server kontinuierlich Nachrichten von anderen Kinesis-Front-End-Servern. Zu diesem Zweck werden im Betriebssystem jedes Front-End-Computers Threads für jeden der Front-End-Server erstellt. Wenn neue Kapazitäten hinzugefügt werden, lernen die Server, die bereits im Frontend-Park arbeiten, neue Mitglieder kennen und erstellen die entsprechenden Streams. Es dauert bis zu einer Stunde, bis jeder vorhandene Front-End-Server über neue Maschinen informiert ist.
Diagnose und Problemlösung
Um 5:15 PST wurden die ersten Fehlermeldungen beim Schreiben und Abrufen von Kinesis-Datensätzen angezeigt. Unsere Teams begannen sofort, die Protokolle zu studieren. Der Verdacht fiel sofort auf neue Kapazitäten, aber einige der Fehler waren in keiner Weise mit den neuen Maschinen verbunden und wären höchstwahrscheinlich nirgendwo hingegangen, selbst wenn wir alle neuen Kapazitäten entfernt hätten.
Trotzdem haben wir vorsichtshalber begonnen, sie zu entfernen, um die Ursache für andere Fehler zu ermitteln. Ihre große Vielfalt verlangsamte unsere Diagnose. Wir haben Fehler in allen Aspekten aller Arten von Anrufen gesehen, die von bestehenden und neuen Mitgliedern der Front-End-Maschinenflotte getätigt wurden, und dies machte es ziemlich schwierig, die Nebenwirkungen von der Grundursache zu trennen.
Ab 7:51 Uhr PST haben wir die Verdächtigen auf wenige Kandidaten eingegrenzt und festgestellt, dass eine der wahrscheinlichsten Ursachen einen vollständigen Neustart des Frontends erfordern würde. Das Kinesis-Team wusste sehr gut, dass dieser Prozess langsam und detailliert sein sollte.
Tatsache ist, dass das Ausfüllen der Shard-Karte mit der Verarbeitung eingehender Anforderungen für die Ressourcen des Front-End-Servers konkurriert. Wenn Sie die Front-End-Server zu schnell wiederherstellen, entsteht ein Konflikt zwischen den beiden Prozessen, und es bleibt zu wenig Zeit, um eingehende Anforderungen zu verarbeiten. Das Endergebnis ist vorhersehbar: eine Zunahme der Fehlerraten und eine Zunahme der Latenzen. Darüber hinaus können langsame Front-End-Server als Zeichen für eine fehlerhafte Ausführung angesehen werden, was dazu führen kann, dass sie aus der Liste der verfügbaren Server entfernt werden, was wiederum den Wiederherstellungsprozess weiter verlangsamt.
Bei allen möglichen Lösungen wurde die Konfiguration jedes Front-End-Servers geändert und neu gestartet. Während unser Hauptkandidat für die Ursache unserer Probleme (ein Problem, das Druck auf das Gedächtnis auszuüben schien) vielversprechend aussah, riskierten wir, wenn wir falsch lagen, die Wiederherstellungszeit zu verdoppeln, da wir alles neu reparieren und neu starten müssten. Um den Neustart zu beschleunigen, haben wir parallel zur Untersuchung begonnen, Änderungen an der Konfiguration der Front-End-Server vorzunehmen, sodass Sie beim Start Daten direkt vom Metadatenspeicher und nicht von den Front-End-Nachbarn empfangen können.
Hauptgrund
Um 9:39 Uhr PST konnten wir endlich die Grundursache des Absturzes bestätigen. Es stellte sich heraus, dass es nicht mit dem Gedächtnis zusammenhängt. Das Hinzufügen neuer Kapazitäten führte dazu, dass die Anzahl der Threads auf allen Front-End-Servern das durch die Systemkonfiguration zulässige Maximum überschritt. Da das Limit überschritten wurde, konnte der Cache (Shard-Karten) nicht erstellt werden. Infolgedessen konnten die Front-End-Server keine Anforderungen an die Back-End-Cluster weiterleiten.
Wir wollten das Thread-Limit im Betriebssystem nicht ohne vorherige Tests erhöhen, und da die zusätzliche Kapazität zu diesem Zeitpunkt bereits entfernt worden war, entschieden wir, dass das Risiko, das Systemlimit für die Anzahl der Threads zu überschreiten, minimal war, und starteten die Server weiter neu. Die erste Gruppe neuer Frontends begann um 10:07 PST, Kinesis-Verkehr zu akzeptieren.
Die Front-End-Flotte besteht aus vielen tausend Servern, und aus den oben beschriebenen Gründen können wir Server mit einer Geschwindigkeit von nicht mehr als einigen hundert pro Stunde hinzufügen. Wir haben das Frontend langsam weiter erweitert und seit Mittag einen stetigen Rückgang der Kinesis-Servicefehler festgestellt. Der Service erholte sich um 22:23 Uhr PST vollständig.
Was haben wir gelernt?
Wir haben aus dem Kinesis-Vorfall mehrere Lehren gezogen und planen, in naher Zukunft Korrekturen vorzunehmen.
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
Der Absturz betraf auch einige Dienste, die Kinesis verwenden.
Amazon Cognito verwendet Kinesis-Datenströme, um API-Zugriffsmuster zu erfassen und zu analysieren. Obwohl diese Informationen für den Betrieb des Cognito-Dienstes äußerst nützlich sind, kann nicht garantiert werden, dass sie bereitgestellt werden (bester Aufwand) . Die Daten werden lokal gepuffert, damit der Dienst mit Latenz oder kurzen Zeiträumen der Nichtverfügbarkeit im Kinesis Data Streams-Dienst fertig wird.
Leider hat die langwierige Nichtverfügbarkeit von Kinesis-Datenströmen einen latenten Fehler im Puffercode aufgedeckt, der dazu führte, dass Cognito-Webserver anfingen, Kinesis-Datenstrompuffer zu blockieren. Infolgedessen waren Cognito-Kunden mit API-Störungen und einer erhöhten Latenz für Cognito-Benutzerpools und Identitätspools konfrontiert. Externe Benutzer konnten keine temporären AWS-Anmeldeinformationen authentifizieren oder abrufen.
In den frühen Phasen des Ausfalls versuchte das Cognito-Team, die Auswirkungen von Kinesis-Fehlern zu verringern, indem es mehr Kapazität hinzufügte und dadurch die Anrufpufferungsfunktionen von Kinesis erhöhte. Dies hatte zunächst einen positiven Einfluss auf den Service, aber um 7:01 PST war die Fehlerrate erheblich gestiegen. Parallel dazu arbeitete das Team daran, Cognitos Abhängigkeit von Kinesis zu verringern. Um 10.15 Uhr wurde diese Lösung bereitgestellt und die Fehlerrate begann zu sinken. Um 12:15 Uhr war die Anzahl der Fehler erheblich gesunken, und um 14:18 Uhr PST funktionierte Cognito normal. Um zu verhindern, dass dieses Problem erneut auftritt, haben wir die Cognito-Webserver geändert. Sie können jetzt Kinesis-API-Fehler tolerieren, ohne ihre Puffer zu entleeren (was zu Benutzerproblemen führt).
CloudWatchverwendet Kinesis Data Streams zur Verarbeitung von Metriken und Protokollen. Ab 5:15 Uhr morgens traten bei CloudWatch zunehmende Fehler und Latenzen für die APIs PutMetricData und PutLogEvents auf, und die Warnungen wurden aktiviert
INSUFFICIENT_DATA. Während einige CloudWatch-Metriken während des Ausfalls weiter verarbeitet wurden, fielen die meisten von ihnen zahlreichen Fehlern und einer erhöhten Latenz zum Opfer.
Um 5:47 Uhr PST zeigten sich die ersten Anzeichen einer Wiederherstellung, als sich die Situation im Kinesis-Datenstrom verbesserte, und um 22:31 Uhr waren die CloudWatch-Metriken und -Warnungen vollständig wiederhergestellt. In den folgenden Stunden wurde die Verarbeitung verzögerter Metriken und Protokolle fortgesetzt. Während CloudWatch mit Fehlern zu kämpfen hatte, konnten interne und externe Clients keine Metrikdaten an CloudWatch liefern. Infolgedessen gibt es Lücken in den CloudWatch-Metrikdaten.
Derzeit verlässt sich der CloudWatch-Dienst auf Kinesis, um Metriken und Protokolle zu erfassen. Das Team wird jedoch in Kürze eine Änderung implementieren, nach der CloudWatch Daten drei Stunden lang im lokalen Speicher speichert. Durch diese Änderung können Benutzer und Dienste, die an CloudWatch-Metriken (einschließlich AutoScaling) gebunden sind, direkt auf neu gesammelte Metriken zugreifen (im lokalen CloudWatch-Datenspeicher). Diese Idee wurde bereits in der Region US-EAST-1 umgesetzt, und in den kommenden Wochen planen wir, sie weltweit einzuführen.
Zwei weitere Dienste wurden zu Geiseln von Problemen mit CloudWatch-Metriken:
- Erstens hatten AutoScaling- Richtlinien, die auf CloudWatch-Metriken basierten, eine Latenz bis 17:47 Uhr, dem Punkt , an dem CloudWatch wieder auf die Beine kam .
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
CloudWatch Events und EventBridge verzeichneten ab 5:15 Uhr MEZ einen Anstieg der API-Fehler und der Latenz bei der Ereignisverarbeitung. Nach der Verbesserung der Verfügbarkeit nahm Kinesis EventBridge die Übermittlung neuer Ereignisse an die Adressaten wieder auf und verarbeitete dabei den Rückstand an Ereignissen.
Elastic Container Service (ECS) und Elastic Kubernetes Service (EKS) verwenden EventBridge in ihren internen Workflows, um Clientcluster und -aufgaben zu verwalten. Dies wirkte sich auf die Bereitstellung neuer Cluster, die verzögerte Skalierung bestehender Cluster und die De-Bereitstellung von Aufgaben aus. Bis 16:15 Uhr PST waren die meisten dieser Probleme behoben.
Kundenbenachrichtigung
Zusätzlich zu den Schwierigkeiten mit den Diensten traten zu Beginn des Vorfalls gewisse Verzögerungen bei der Übermittlung von Informationen über den Status der Dienste an die Kunden auf.
Wir haben zwei Möglichkeiten, mit Kunden während operativer Ereignisse zu kommunizieren:
- Service Health Dashboard - Ein öffentlich verfügbares Dashboard zur Warnung vor großen betrieblichen Problemen.
- Personal Health Dashboard - zur direkten Benachrichtigung betroffener Kunden.
Bei solchen Ereignissen veröffentlichen wir normalerweise Informationen im Service Health Dashboard. In diesem Fall konnten wir jedoch zu Beginn des Absturzes die Informationen im Service Health Dashboard nicht aktualisieren, da das zum Veröffentlichen von Updates verwendete Tool vom abgestürzten Cognito verwendet wird.
Wir haben eine Fallback-Methode zum Aktualisieren des Service Health Dashboards mit minimalen Service-Abhängigkeiten. Es hat wie beabsichtigt funktioniert, aber es gab einige Verzögerungen beim Veröffentlichen von Informationen im Service Health Dashboard zu Beginn der Veranstaltung. Der Punkt ist, dass dieses Backup-Tool viel weniger automatisiert und den Helpdesk-Betreibern weniger vertraut ist.
Um sicherzustellen, dass alle betroffenen Kunden rechtzeitig über Updates informiert werden, nutzte das Support-Team das Personal Health Dashboard, um sie auf potenzielle Serviceprobleme aufmerksam zu machen. Außerdem haben wir im Service Health Dashboard ein globales Banner mit aktuellen Informationen angebracht, um die Benutzer über den Vorfall so gut wie möglich zu informieren. Bis zum Ende des Absturzes verwendeten wir weiterhin eine Kombination aus Service Health Dashboard (mit Zusammenfassungen globaler Banner und Details zur Funktionsweise bestimmter Services) und Personal Health Dashboard, um Kunden, die von Problemen mit Services betroffen sind, auf dem neuesten Stand zu halten. Basierend auf unserer Erfahrung haben wir in unserer regelmäßigen Schulung als Support-Ingenieur obligatorische Übungen mit einem Fallback-System zum Posten von Nachrichten an das Service Health Dashboard eingeführt.
...
Abschließend möchte ich mich für die negativen Auswirkungen dieses Vorfalls auf unsere Kunden entschuldigen. Wir sind stolz auf die hohe Verfügbarkeit von Amazon Kinesis und wissen, wie wichtig dieser und andere AWS-Services für unsere Kunden, ihre Anwendungen / Endbenutzer und ihre Unternehmen sind. Wir werden unser Bestes tun, um aus diesem Vorfall zu lernen und ihn zu nutzen, um die Zugänglichkeit weiter zu verbessern.
PS
Lesen Sie auch in unserem Blog: