Wie Klever ständig die Augen offen hält, um eine hohe Performance & Verfügbarkeit der Dienste zu gewährleisten und wie diese Überwachung nicht nur hilft Probleme zu lösen, sondern auch eine kontinuierliche Leistungsverbesserung zu ermöglichen.
Sie haben wahrscheinlich schon von DevOps-Praktiken gehört und wie sie dazu beitragen, kontinuierlich bessere Produkte und Dienstleistungen bereitzustellen. Wenn nicht, lade ich Sie ein, diesen Artikel mit einer etwas tieferen Erläuterung dazu zu lesen.
Heute sprechen wir über Monitoring, das ein wichtiger Teil des Anwendungslebenszyklus ist, der in DevOps verwendet wird.
Über Jahre war die Überwachung nur als Möglichkeit gedacht, Probleme zu entdecken und hatte nur eine Funktion - das zuständige Team zu alarmieren, um es zu lösen - solche Teams arbeiteten normalerweise als Feuerwehrleute und danach sprach niemand mehr darüber.
Wir glauben nicht, dass dies eine Klever-Arbeitsweise ist, da das Monitoring uns viele Einblicke gibt und die alleinige Verwendung dieser bei der Fehlerbehebung eine solche Verschwendung wertvoller Daten und Informationen ist.
In dieser Artikelserie ist es (zumindest vorerst 😉) nicht unser Ziel, darüber zu schreiben, wie wir Site Reliability Engineering-Praktiken implementieren, sondern Ihnen stattdessen zwei Leistungsoptimierungen zu zeigen, die kürzlich vom Klever DevOps-Team durchgeführt und an das Klever-Ökosystem geliefert wurden und warum dies nur mit Beobachtbarkeit möglich war.
Global verteilte Dienste
Eine Methode, die wir verwenden, um die Verfügbarkeit unserer Dienste zu überwachen, besteht darin, jeden einzelnen von ihnen mit synthetischen Tests zu testen.
Synthetic Monitoring ist eine Technik, die das Verhalten des Benutzers emuliert, um den Betrieb der überwachten Systeme sicherzustellen.
Der Aktionsfluss des Benutzers wird durch eine andere Software, normalerweise Skripte, emuliert und wiederholt in festgelegten Zeitintervallen für Leistungsmessungen ausgeführt, wie z. B.: Funktionalität, Verfügbarkeit und Reaktionszeit.
Kurz gesagt, wir haben "Roboter" in verschiedenen Teilen der Welt, die unsere Anwendungsfunktionen emulieren, und wenn ein Bot die Aufgabe nicht ausführen kann, wird eine Benachrichtigung an unser Team gesendet, das dann proaktive Maßnahmen ergreift.
Dies funktioniert hervorragend, um Probleme zum Zeitpunkt des Auftretens zu erkennen, gibt uns aber auch die Reaktionszeit unserer Dienste an allen Standorten an. Darüber hinaus teilt das Überwachungstool auch die Zeit auf, die für jeden Teil von HTTP-Transaktionen aufgewendet wird.
-
connect
-
processing
-
resolve
-
tls
-
transfer
Anhand dieser Daten konnten wir feststellen, dass die Anfragen an einigen Standorten in drei Phasen zu lange dauerten: connect, tls und transfer.
Lösung für das globale Latenzproblem
Die Reduzierung der Verbindungs- und Übertragungszeit ist eine Herausforderung. Die Lösung besteht darin, die Backend-Anwendungen so nah wie möglich an die Clients zu „verlagern“, um die Netzwerklatenz zu reduzieren.
Da Klever eine weltweite Benutzerbasis und Kunden in allen Teilen der Welt hat, kann es teuer und schwer zu warten sein, unsere Dienste für alle Regionen zu replizieren. Aus diesem Grund haben wir uns entschieden, von unserem traditionellen Load-Balancing zum GCLB von Google zu migrieren, das einen regionsübergreifenden Load-Balancing mit Points of Presence (PoP) auf der ganzen Welt bietet.
Sobald die Verbindungen im nächsten PoP hergestellt sind und der gesamte Datenverkehr zu unserem Kubernetes-Back-End und den Datenbanken im internen Google-Netzwerk läuft, haben wir auch die TLS-Terminierung von Ingress-nginx auf Edge-Load-Balancer verschoben, um die TLS-Zeit zu verkürzen. Mit diesem Schritt wurde die durchschnittliche Reaktionszeit halbiert, wie in der folgenden Grafik dargestellt.
Swap API Reaktionszeit
Diese Optimierung der Antwortzeit der Klever Swap-API unterscheidet sich von Natur aus vom ersten Beispiel, da sie keine Infrastrukturänderung beinhaltet.
Unser Monitoring-Stack hat uns bei der Identifizierung der Engpässe unterstützt und zusammen mit dem Swap-Team Änderungen am Quellcode vorgenommen, die zu einer 60-prozentigen Verbesserung der Antwortzeit für die am häufigsten genannte API-Methode führten – diejenige, die für die Auflistung der aktiven Schlüsselpaare vom Swap verantwortlich ist.
Mit einer Klever-Anpassung und verringertem CPU-Verbrauch des Servers wurde die Geschwindigkeit aller Swaps in Klever deutlich erhöht.
In verteilten Softwarearchitekturen, wie sie Klever verwendet, um unsere Benutzer weltweit zu bedienen, ist es manchmal schwierig herauszufinden, welcher genaue Schritt im gesamten verteilten Computing-Prozess die Ursache für eine mögliche erkannte Verlangsamung ist.
Aus diesem Grund ist die verteilte Ablaufverfolgung entscheidend, um zu verstehen, wie sich eine Anforderung über mehrere Dienste, Pakete und Infrastrukturkomponenten hinweg bewegt.
In diesem speziellen Szenario mit verteiltem Tracing stellen wir fest, dass die API auch ohne Swap-Transaktion ständig aufgerufen wurde und eine Lösung gefunden hat.
Optimieren der Swap-API-Antwortzeit
Dies ist ein typischer Fall von Monolith, bei dem ein Dienst für mehr als ein Ziel verantwortlich ist. Unsere Swap-Funktionalität ist fantastisch, einfach zu bedienen und war einer unserer ersten Dienste in der App. Zu dieser Zeit wurde die Funktionalität zur Rückgabe von Coin-Preisen in die Swap-API integriert.
Mit unserer Produktentwicklung, dem Benutzerwachstum und der Zunahme der für Swap verfügbaren Coins haben wir erkannt, dass es notwendig war, diese Funktionalität in einen anderen Dienst aufzuteilen. Im Wesentlichen, um die Preise und Swap-Services zu trennen und zu verteilen, um die gesamte Swap-Funktion schneller, zuverlässiger und effizienter zu machen.
Nach dieser Änderung können andere Bildschirme in der Anwendung aktuelle Preise abrufen, ohne die Gesamtleistung des Swaps zu beeinträchtigen, und wir konnten den Service je nach Nachfrage separat skalieren.
Fazit
In diesem Artikel haben wir zwei Beispiele dafür vorgestellt, wie uns die kontinuierliche Überwachung unserer Dienstleistungen hilft, unserer Gemeinschaft von Klever-Anwendern qualitativ hochwertige und sich ständig weiterentwickelnde Produkte anzubieten.
Natürlich umfasst diese Überwachung viel mehr als das, was wir heute behandelt haben und die Grundlagen sind auch sehr wichtig:
Der reibungslose Betrieb aller Klever-Dienste ist das Herz, das unser Blut am Laufen hält.
Eine gute Überwachungsstrategie reduziert unsere MTTA und MTTR und ermöglicht es unserem global verteilten Team mit Rufbereitschaft rund um die Uhr, mögliche Probleme immer im Blick zu behalten und durch proaktive Maßnahmen für die Zukunft besser zu skalieren. Unser CTO Bruno hat in seinem Artikel hier ein wenig darüber gesprochen.
Die kontinuierliche Verfolgung von Microservices ist eine Herausforderung in verteilten Softwarearchitekturen und die Überwachung ist ein kontinuierlicher Fortschrittszyklus für das Klever DevOps-Team. Aber das ist ein Gespräch für ein anderes Mal!
Mit freundlichen Grüßen,
Kadu Relvas Barral
Klever’s Site Reliability Engineer
Kadu verfügt über mehr als 15 Jahre Berufserfahrung in der IT und verbrachte die letzten 10 Jahre damit, in Versicherungs-, Telekommunikations- und Finanzunternehmen zu arbeiten, um herauszufinden, was in ihren Systemen defekt war, bevor andere es herausfanden. Marathonist in der Freizeit, läuft gerne und hält Anwendungen am Laufen.
Klever App herunterladen
