Unser Junitreffen in Test in Production war dem Chaos Engineering gewidmet. Die leitende Softwareentwicklerin Norah Jones begann damit, wie Netflix Tests in der Produktion durchführt.
„Chaos Engineering ... dies sind Experimente in der Produktion, um Schwachstellen in einem System zu finden, bevor sie einen Service für Kunden ungeeignet machen. Bei Netflix führen wir sie mit einem Tool namens ChAP aus ... [es] erkennt Schwachstellen und ermöglicht es uns, Fehler in Services und Produktion zu implementieren. Diese Fehler bestätigen die Annahmen zu diesen Diensten, bevor sie zu vollständigen Ausfällen führen. “
Sehen Sie sich eine Präsentation an (oder lesen Sie das Transkript) darüber, wie ihr Team Benutzern - Netflix-Ingenieuren - hilft, sicher in der Produktion zu testen und Schwachstellen in ihren Systemen aktiv zu identifizieren.
Entschlüsselung
Ich bin sehr froh, heute hier zu sein.
Netflix verwendet aktiv Tests in der Produktion. Wir machen sie durch Chaos Engineering und haben kürzlich unser Team in Resiliance Engineering [nachhaltige Entwicklung] umbenannt, weil Chaos Engineering ein Weg ist, um allgemeine Nachhaltigkeit zu erreichen. Ich werde heute darüber sprechen.
Unser Ziel ist es, die Verfügbarkeit zu erhöhen, indem wir proaktiv nach Schwachstellen in Diensten suchen. Wir tun dies durch Experimente in der Produktion. Das Team ist zuversichtlich, dass eine bestimmte Klasse von Schwachstellen und Problemen nur im realen Datenverkehr erkannt werden kann.
Zunächst sollten Sie sich um Sicherheit und Überwachung kümmern, da Sie sonst keine normalen Tests in der Produktion durchführen können. Solche Tests können beängstigend sein: Wenn sie Angst machen, sollten Sie auf diese Stimme hören und herausfinden, warum. Vielleicht, weil Sie kein gutes Sicherheitssystem haben. Oder weil es keine gute Überwachung gibt. In unseren Tools kümmern wir uns wirklich um diese Dinge.
Wenn wir Chaos Engineering in einem Satz formulieren, ist dies die Disziplin von Experimenten in der Produktion, um Schwachstellen im System zu finden, bevor sie den Service für Kunden ungeeignet machen. Bei Netflix führen wir sie mit einem Tool namens ChAP aus, dh der Chaos Automation Platform (Chaos Automation Platform). ChAP erkennt Schwachstellen und ermöglicht es Benutzern, Fehler in Diensten und in der Produktion zu implementieren. Diese Fehler bestätigen die Annahmen der Benutzer zu diesen Diensten, bevor sie zu vollständigen Ausfällen führen.
Ich werde Ihnen sagen, wie die Plattform auf hohem Niveau funktioniert. Dies ist eine hypothetische Menge von Microservice-Abhängigkeiten. Es gibt einen bestimmten Proxy. Es sendet eine Anforderung an Dienst A, der dann für die Dienste B, C und D ohne Lüfter abweicht, und es besteht immer noch ein gewisses Maß an Persistenz. Service D greift auf Cassandra zu, und Service B greift auf den Cache zu.
Ich eile voran und fasse alles zusammen, denn die Essenz beginnt weiter. Wir möchten sicherstellen, dass Service D robust gegen einen Cache-Fehler ist. Der Benutzer betritt die ChAP-Schnittstelle und wählt Dienst D als Dienst aus, der Cache-Fehler beobachtet, und als Dienst für Fehler. ChAP klont Dienst B tatsächlich in zwei Kopien. Wir verwenden sie zur Kontrolle in experimentellen Clustern: In gewisser Weise funktionieren sie wie A / B-Tests oder Kanarien-Tests. Diese Replikate sind viel kleiner als Service B. Wir senden nur einen sehr, sehr kleinen Prozentsatz der Kunden an diese Cluster, da wir offensichtlich keinen vollständigen Fehler wünschen. Wir berechnen diesen Prozentsatz basierend auf der aktuellen Anzahl der Benutzer, die den Dienst derzeit nutzen.
ChAP weist das Failover-System dann an, Anforderungen zu kennzeichnen, die unseren Kriterien entsprechen. Dies erfolgt durch Hinzufügen von Informationen zu den Anforderungsheadern. Es werden zwei Sätze von Tags erstellt. Im ersten Satz von Anweisungen für den Ausfall und das Weiterleiten an die Kanarienvogelreplik und im zweiten Satz nur Anweisungen für das Weiterleiten an das Überwachungselement.
Wenn der RPC-Client und der Dienst A die zum Weiterleiten der Anforderung erforderlichen Anweisungen erhalten, leiten sie den Datenverkehr tatsächlich an den Überwachungscluster oder den experimentellen Cluster. Das Fehlerimplementierungssystem auf RPC-Ebene des experimentellen Clusters erkennt dann, dass die Anforderung als fehlerhaft markiert ist, und gibt eine fehlgeschlagene Antwort zurück. Wie zuvor führt der experimentelle Cluster Code aus, um den Fehler als erfolglose Antwort aus dem Cache zu behandeln. Wir gehen davon aus, dass es fehlertolerant ist, oder? Aber manchmal sehen wir, dass dies nicht so ist. Aus Sicht von Service A sieht alles wie normales Verhalten aus.
Wir kontrollieren die Chaos-Technik sorgfältig, was sehr schlecht laufen kann. Als Netflix solche Experimente zum ersten Mal startete, hatten wir kein gutes Kontrollsystem. Wir starteten eine künstliche Panne und setzten uns mit gekreuzten Fingern in den Raum und überprüften, ob alles gut funktionierte. Jetzt legen wir viel mehr Wert auf Sicherheit.
Wir betrachten wichtige Geschäftskennzahlen. Eine davon heißt SPS (Stream startet pro Sekunde), dh startet Video-Streams pro Sekunde. Wenn Sie darüber nachdenken, was für das Geschäft von Netflix am wichtigsten ist, können Benutzer jede Serie jederzeit ausführen.
In den Grafiken sehen Sie ein echtes Experiment. Es zeigt den Unterschied in der SPS zwischen dem experimentellen und dem Kontrollcluster während des Tests. Sie können feststellen, dass die Diagramme stark voneinander abweichen, was nicht der Fall sein sollte, da der gleiche Prozentsatz des Datenverkehrs an beide Cluster gesendet wird.
Aus diesem Grund verwendet der Test eine automatisierte Kanarienanalyse. Es gibt ein Signal, dass sehr viele Graphen stark voneinander abweichen. In diesem Fall wird der Test sofort unterbrochen, damit die Benutzer normal mit der Site arbeiten können. Aus Sicht des Benutzers ist dies eher eine kurzfristige Panne, wenn dies geschieht.
Wir haben viele andere Mittel. Wir begrenzen das Volumen des Testverkehrs in jeder Region, sodass wir das Experiment nicht nur in der Zone West 2 der USA durchführen. Wir führen sie überall durch und begrenzen die Anzahl der Experimente, die gleichzeitig in der Region durchgeführt werden können. Tests bestehen nur während der Arbeitszeit, sodass wir Ingenieure nicht wecken, wenn etwas schief geht. Wenn der Test fehlschlägt, kann er nicht automatisch erneut gestartet werden, bis jemand ihn explizit manuell korrigiert und bestätigt: "Hey, ich weiß, dass der Test nicht bestanden wurde, aber ich habe alles behoben, was benötigt wird."
Es ist möglich, benutzerdefinierte Eigenschaften auf Cluster anzuwenden. Dies ist nützlich, wenn der Dienst wie viele Netflix-Dienste in Shards unterteilt ist. Darüber hinaus können Sie Fehler basierend auf dem Gerätetyp implementieren. Wenn wir Probleme mit Apple-Geräten oder einem bestimmten Fernsehtyp annehmen, können wir Tests speziell für diese Geräte durchführen.
ChAP hat viele Fehler gefunden. Hier ist einer meiner Favoriten. Wir haben ein Experiment durchgeführt, um den Sicherungspfad des Dienstes zu überprüfen, der für seine Verfügbarkeit entscheidend ist, und dort einen Fehler festgestellt. Das Problem wurde behoben, bevor es zum Vorfall der Serviceverfügbarkeit führte. Dies ist ein wirklich interessanter Fall, da dieser Sicherungspfad nicht oft ausgeführt wurde. Daher wusste der Benutzer nicht wirklich, ob es richtig funktioniert, und wir konnten es nachahmen. Wir haben tatsächlich einen Servicefehler verursacht und überprüft, ob es sich um ein Abstellgleis handelt und ob es ordnungsgemäß funktioniert. In diesem Fall hielt der Benutzer seinen Dienst für unkritisch oder zweitrangig, aber tatsächlich war er ein kritischer Dienst.
Hier ist ein weiteres Beispiel. Wir haben ein Experiment durchgeführt, um das Problem während des Registrierungsprozesses zu reproduzieren, der nachts auf einigen Servern auftrat. Mit dem Service passierte etwas Seltsames. Das Problem wurde nach Einführung einer Verzögerung von 500 Millisekunden reproduziert. Während des Tests wurde das Problem in den auf das Big Data Portal hochgeladenen Protokollen gefunden. Dies half zu verstehen, warum in einigen Fällen die Registrierung nicht funktionierte. Nur dank des ChAP-Experiments konnten wir sehen, was geschah und warum.
Die Konfiguration des ChAP-Tests erfordert viele Informationen. Wir müssen die geeigneten Punkte für die Einführung von Fehlern herausfinden. Die Teams müssen entscheiden, ob sie abstürzen oder verzögern möchten. Es hängt alles vom Einspritzpunkt ab. Sie können Cassandra, Hystrix (unser Backup-System), den RPC-Service, den RPC-Client, S3, SQS oder unseren Cache zum Absturz bringen oder eine Verzögerung hinzufügen. Oder beides. Sie können auch Kombinationen verschiedener Experimente erstellen.
Sie müssen sich mit einem Serviceteam zusammensetzen und einen guten Test erstellen. Es wird viel Zeit in Anspruch nehmen. Wenn Sie ein Experiment einrichten, sollten Sie auch ACA-Konfigurationen (Automated Canary Analysis) oder automatische Kanarienkonfigurationen definieren.
Wir hatten einige vorgefertigte ACA-Konfigurationen. Es gab eine ChAP-Konfiguration für SPS. Es gab eine mit Überwachungssystemindikatoren. Ein anderer, der nach RPS-Abstürzen suchte. Ein anderer hat dafür gesorgt, dass unser Service tatsächlich einwandfrei funktioniert und Fehler ordnungsgemäß implementiert. Wir haben erkannt, dass das Entwerfen eines Tests sehr zeitaufwändig sein kann, und so geschah es. Es wurden nicht viele Tests erstellt. Es ist schwierig für eine Person, alles im Auge zu behalten, was für ein gutes Experiment benötigt wird. Wir haben beschlossen, etwas mit ChAP zu automatisieren. Wir haben uns die Indikatoren angesehen: Wo und von wem gehen die Anrufe, Dateien mit Zeitüberschreitungen, wiederholte Anrufe. Es wurde klar, dass alle Informationen von verschiedenen Orten stammen. Es war notwendig, es zu aggregieren.
Wir haben die Analyse auf die ChAP-Ebene skaliert, wo es viel bequemer ist, mit Informationen zu arbeiten, und Sie Monocle verwenden können. Jetzt können alle Informationen über die Anwendung und den Cluster an einem Ort untersucht werden. Hier stellt jede Linie eine Abhängigkeit dar, und diese Abhängigkeiten stellen einen Nährboden für Chaos-Engineering-Experimente dar.
Wir haben alle Informationen für die Entwicklung des Experiments an einem Ort gesammelt, aber nicht verstanden, dass eine solche Aggregation an sich sehr nützlich ist, daher ist dies ein interessanter Nebeneffekt. Sie können hier hingehen und tatsächlich Anti-Muster sehen, die mit einem bestimmten Dienst verbunden sind. Beispielsweise wird eine Abhängigkeit erkannt, die nicht als kritisch angesehen wurde, aber keine Fallback-Route hat. Offensichtlich wird sie jetzt kritisch. Die Leute konnten Timeout-Fehlanpassungen und Rückruf-Fehlanpassungen feststellen. Wir verwenden diese Informationen, um die Kritikalität eines Experiments eines bestimmten Typs zu bewerten und in einen Algorithmus einzugeben, der Prioritäten bestimmt.
Jede Zeile stellt eine Abhängigkeit dar, und diese Zeilen können erweitert werden. Hier ist ein interessantes Beispiel.
Hier zeigt die blaue Linie oben die Zeitüberschreitung einer Person an, und die violette Linie unten zeigt die übliche Laufzeit an. Wie Sie sehen können, ist es sehr, sehr weit vom Timeout entfernt. Die meisten dieser Informationen waren jedoch nicht verfügbar. Was passiert, wenn wir den Test direkt unter dem Timeout ausführen? Was denkst du? Wird er bestehen? Dies ist eine interessante Frage. Wir versuchen, den Benutzern diesen Detaillierungsgrad zur Verfügung zu stellen, bevor sie die Tests ausführen, damit sie Schlussfolgerungen ziehen und Einstellungen ändern können.
Ich möchte ein kleines Spiel spielen. Dieser Netflix-Dienst weist eine Sicherheitsanfälligkeit auf. Versuchen Sie, diese zu erkennen. Nehmen Sie sich eine Sekunde Zeit und schauen Sie.
Um Ihnen einen gewissen Kontext zu geben, enthält der Befehl remote Hystrix sowohl sample-rest-client als auch sample-rest-client.GET. Das Hystrix-Timeout ist auf 500 Millisekunden eingestellt. Sample-rest-client.GET hat eine Zeitüberschreitung von 200 ms mit einem erneuten Versuch, was gut ist, da die Summe 400 Millisekunden beträgt, was in die Hystrix-Grenze passt. Der zweite Client hat Timeouts von 100 und 600 mit einem erneuten Versuch.
In diesem Fall kann der Wiederholungsversuch unter Berücksichtigung des Zeitlimits der Hystrix-Shell nicht abgeschlossen werden. Das heißt, Hystrix lehnt die Anforderung ab, bevor der Client eine Antwort erhalten kann. Hier liegt die Schwachstelle. Wir stellen diese Informationen den Benutzern zur Verfügung. Interessanterweise befindet sich der größte Teil der Logik bei der Implementierung dieser Funktionen an verschiedenen Stellen, und bevor sie diese Dinge nicht vergleichen konnten. Sie dachten, alles würde gut funktionieren, aber hier ist ein Fehler.
Warum ist das passiert? Natürlich ist es für Entwickler einfach, den Konflikt zu erkennen und das Zeitlimit zu ändern, oder? Aber wir wollen den Grund herausfinden. Wir können das Timeout ändern, aber wie können wir garantieren, dass dies nicht noch einmal passiert? Wir helfen auch dabei, die Gründe herauszufinden.
Bei der Erstellung automatisierter Tests verwenden wir auch Monocle. Der Benutzer erstellt ein Experiment mit zahlreichen Arten von Eingabedaten. Wir nehmen all dies und automatisieren die Erstellung solcher Tests, damit sich die Benutzer nicht darum kümmern. Wir erstellen und priorisieren automatisch Hystrix-Experimente und RPC-Experimente mit Verzögerungen und Fehlern aufgrund von Verzögerungen. ACA-Konfigurationen werden standardmäßig hinzugefügt. SPC, Systemmetriken, Abfragestatistiken und Experimente werden automatisch ausgeführt. Prioritäten für Experimente werden ebenfalls erstellt. Für sie funktioniert ein High-Level-Algorithmus. Wir verwenden einen Bucket mit RPS-Statistiken. Wir verwenden mehrere Wiederholungsversuche und verwandte Hystrix-Befehle. Der gesamte Satz wird entsprechend gewichtet.
Darüber hinaus werden die Anzahl der Teams ohne Sicherungsausführungspfade und alle externen Auswirkungen (kuratierte Auswirkungen) berücksichtigt, die der Client zu seiner Abhängigkeit hinzufügt. Externe Einflüsse wirken sich stark auf Autorisierungs-, Registrierungs- und SPS-Verfahren aus. Und wir messen wirklich seine Wirkung und führen keine Experimente durch, wenn das Ergebnis negativ ist. Dann werden die Tests eingestuft und in absteigender Reihenfolge der Kritikalität ausgeführt. Je höher der Kritikalitätswert, desto früher und häufiger beginnt der Test.
Ironischerweise gab uns Monocle Feedback, mit dem wir weniger Tests in der Produktion durchführen können. Wir haben so viele Tests durchgeführt, dass sich eine Rückkopplungsschleife bildete: Wir haben die Zusammenhänge zwischen den Tests gesehen. Jetzt können Sie bestimmte Konfigurationsdateien anzeigen und bestimmte Anti-Patterns anzeigen. Auch ohne Tests für diese Informationen ist es möglich zu verstehen, was genau den Fehler verursacht. Zu diesem Zeitpunkt haben wir dies noch nicht verstanden.
Dies hat zu einem neuen Sicherheitsniveau geführt. Zuvor wurde ein erfolgloses Experiment als gelöst markiert. Jetzt wird es vor dem Neustart als behoben markiert. Aber jetzt können wir der Sucht explizit externe (kuratorische) Einflüsse hinzufügen. Der Benutzer gibt sein Monokel ein und zeigt an: Dieser Faktor beeinflusst genau das Autorisierungsverfahren. Dieser ist auf SPC. Und wir arbeiten an einem Rückkopplungszyklus, damit bei einem Fehlschlag auch ein solcher kuratorischer Effekt hinzugefügt wird.
Daher ist Monocle in ChAP ein wichtiges Tool, mit dem alle Informationen gesammelt werden. Es generiert automatisch Experimente, priorisiert automatisch und sucht nach Schwachstellen, bevor diese zu einem vollständigen Herunterfahren führen. Zusammenfassend ist es wichtig, sich daran zu erinnern, warum wir uns mit Chaos Engineering beschäftigen und all diese Experimente in der Produktion durchführen. Dies geschieht, um zu verstehen, wie Kunden den Service nutzen, und um sie nicht aus den Augen zu verlieren. Sie möchten den Menschen den bequemsten Service bieten. Überwachung und Sicherheit sind daher von größter Bedeutung. Netflix sollte immer Videos anzeigen.
Vielen Dank.