Echtzeit-Datenstreaming und Ereignisverarbeitung stellen Skalierbarkeits- und Verwaltungsherausforderungen dar. AWS bietet eine breite Auswahl an verwalteten Produkten Echtzeit-Daten-Streaming-Dienste um diese Workloads in jeder Größenordnung mühelos auszuführen.

In diesem Beitrag erklärt Nexthink, wie das geht Amazon Managed Streaming für Apache Kafka (Amazon MSK) ermöglichte ihnen eine enorme Skalierung der Ereignisverarbeitung. Aufgrund des enormen Geschäftswachstums migrierte Nexthink zu AWS, um die Skalierungsbeschränkungen lokaler Lösungen zu überwinden. Mit Amazon MSK verarbeitet Nexthink jetzt nahtlos Billionen von Ereignissen pro Tag und erreicht einen aggregierten Durchsatz von über 5 GB pro Sekunde.

In den folgenden Abschnitten stellt Nexthink sein Produkt und die Notwendigkeit der Skalierbarkeit vor. Anschließend beleuchten sie die Herausforderungen ihrer alten lokalen Anwendung und stellen ihren Übergang zu einer Cloud-zentrierten Software-as-a-Service-Architektur (SaaS) auf Basis von Amazon MSK vor. Abschließend erläutert Nexthink detailliert die Vorteile, die durch die Einführung von Amazon MSK erzielt werden.

Nexthink muss skalieren

Nexthink ist führend im Bereich Digital Employee Experience (DeX). Das Unternehmen gestaltet die Zukunft der Arbeit, indem es IT-Führungskräften und C-Levels Einblicke in die täglichen Technologieerfahrungen der Mitarbeiter auf Geräte- und Anwendungsebene bietet. Dadurch kann die IT von der reaktiven Problemlösung zur proaktiven Optimierung übergehen.

Das Nexthink Infinity-Plattform kombiniert Analyse, Überwachung, Automatisierung und mehr, um das digitale Erlebnis der Mitarbeiter zu verwalten. Durch das Sammeln von Geräte- und Anwendungsereignissen, deren Verarbeitung in Echtzeit und deren Speicherung analysiert unsere Plattform Daten, um Probleme zu lösen und die Erfahrungen von über 15 Millionen Mitarbeitern auf fünf Kontinenten zu verbessern.

In nur drei Jahren wuchs das Geschäft von Nexthink um das Zehnfache, und mit der Einführung von mehr Echtzeitdaten musste unsere Anwendung von der Verarbeitung von 3 MB pro Sekunde auf 200 GB pro Sekunde und Billionen von Ereignissen täglich skalieren. Um dieses Wachstum zu ermöglichen, haben wir unsere Anwendung von einem lokalen Single-Tenant-Monolithen zu einer cloudbasierten, skalierbaren SaaS-Lösung auf Basis von Amazon MSK modernisiert.

In den nächsten Abschnitten wird unser Modernisierungsweg detailliert beschrieben, einschließlich der Herausforderungen, denen wir gegenüberstanden, und der Vorteile, die wir mit unserer neuen cloudzentrierten, AWS-basierten Architektur erzielt haben.

Die On-Premise-Lösung und ihre Herausforderungen

Schauen wir uns zunächst unsere bisherige On-Premise-Lösung Nexthink V6 an, bevor wir untersuchen, wie Amazon MSK die Herausforderungen bewältigt. Das folgende Diagramm veranschaulicht seine Architektur.

V6 bestand aus zwei monolithischen Einzelmandanten-Java- und C++-Anwendungen, die eng miteinander verbunden waren. Das Portal war eine Backend-für-Frontend-Java-Anwendung, und die Kern-Engine war eine interne C++-In-Memory-Datenbankanwendung, die auch Geräteverbindungen, Datenaufnahme, Aggregation und Abfragen verwaltete. Durch die Bündelung all dieser Funktionen wurde es schwierig, die Engine zu verwalten und zu verbessern.

V6 mangelte es auch an Skalierbarkeit. Ursprünglich wurden 10,000 Geräte unterstützt, einige neue Mieter verfügten jedoch über mehr als 300,000 Geräte. Wir reagierten mit der Bereitstellung mehrerer V6-Engines pro Mandant, was zu einer Erhöhung der Komplexität und Kosten, einer Beeinträchtigung des Benutzererlebnisses und einer Verzögerung der Markteinführung führte. Dies führte auch zu längeren Proof-of-Concept- und Onboarding-Zyklen, was dem Geschäft schadete.

Darüber hinaus führte das Fehlen einer Streaming-Plattform wie Kafka durch die enge HTTP/gRPC-Kopplung zu Abhängigkeiten zwischen den Teams. Darüber hinaus konnten Teams vor der Aufnahme in die Datenbank nicht auf Echtzeitereignisse zugreifen, was die Funktionsentwicklung einschränkte. Außerdem fehlte uns ein Datenpuffer, wodurch bei Ausfällen ein potenzieller Datenverlust drohte. Solche Einschränkungen behinderten Innovationen und erhöhten Risiken.

Zusammenfassend lässt sich sagen, dass das V6-System zwar seinen ursprünglichen Zweck erfüllte, es jedoch mit Cloud-basierten Technologien neu erfunden werden musste, um die Skalierbarkeit und Zuverlässigkeit zu verbessern und die Innovation unserer Entwicklungs- und Produktteams zu fördern.

Übergang zu einer Cloud-zentrierten Architektur mit Amazon MSK

Um unsere Modernisierungsziele zu erreichen, haben wir nach gründlicher Recherche und Iterationen ein ereignisgesteuertes Microservices-Design implementiert Amazon Elastic Kubernetes-Service (Amazon EKS) mit Kafka auf Amazon MSK für die verteilte Ereignisspeicherung und das Streaming.

Unser Übergang von der v6-On-Prem-Lösung zur cloudzentrierten Plattform verlief in vier Schritten:

• Phase 1 – Wir haben von On-Premise-Maschinen auf virtuelle Maschinen in der Cloud umgestellt, um die betriebliche Komplexität zu reduzieren, die Proof-of-Concept-Zyklen zu beschleunigen und gleichzeitig Kunden transparent zu migrieren.
• Phase 2 – Wir haben die Cloud-Architektur durch die Implementierung neuer Produktfunktionen mit Microservices und selbstverwaltetem Kafka auf Kubernetes erweitert. Der Betrieb von Kafka-Clustern selbst erwies sich jedoch als übermäßig schwierig, was uns zu Phase 3 führte.
• Phase 3 – Wir sind von selbstverwaltetem Kafka auf Amazon MSK umgestiegen, um die Stabilität zu verbessern und die Betriebskosten zu senken. Wir erkannten, dass die Verwaltung von Kafka nicht unsere Kernkompetenz oder unser Alleinstellungsmerkmal war und dass der Aufwand hoch war. Amazon MSK ermöglichte es uns, uns auf unsere Kernanwendung zu konzentrieren und befreite uns von der Last der undifferenzierten Kafka-Verwaltung.
• Phase 4 – Schließlich haben wir alle Legacy-Komponenten eliminiert und damit den Übergang zu einer vollständig Cloud-zentrierten SaaS-Plattform abgeschlossen. Diese mehrjährige Reise des Lernens und der Transformation dauerte drei Jahre.

Heute, nach unserer erfolgreichen Umstellung, nutzen wir Amazon MSK für zwei Schlüsselfunktionen:

• Echtzeit-Datenerfassung und -verarbeitung von Billionen täglicher Ereignisse von über 15 Millionen Geräten weltweit, wie in der folgenden Abbildung dargestellt.

• Ermöglichung eines ereignisgesteuerten Systems, das Datenproduzenten und -konsumenten entkoppelt, wie in der folgenden Abbildung dargestellt.

Um unsere Skalierbarkeit und Widerstandsfähigkeit weiter zu verbessern, haben wir a eingeführt Zellbasierte Architektur Nutzung der breiten Verfügbarkeit von Amazon MSK in allen AWS-Regionen. Wir betreiben derzeit über 10 Zellen, von denen jede eine unabhängige regionale Bereitstellung unserer SaaS-Lösung darstellt. Dieser zellenbasierte Ansatz minimiert den Wirkungsbereich bei Problemen, erfüllt Anforderungen an die Datenresidenz und ermöglicht eine horizontale Skalierung über AWS-Regionen hinweg, wie in der folgenden Abbildung dargestellt.

Vorteile von Amazon MSK

Amazon MSK war entscheidend für die Umsetzung unseres ereignisgesteuerten Designs. In diesem Abschnitt beschreiben wir die wichtigsten Vorteile, die wir durch die Einführung erzielt haben.

Verbesserte Datenresilienz

In unserer neuen Architektur werden Daten von Geräten direkt an Kafka-Themen in Amazon MSK übertragen, was für hohe Verfügbarkeit und Ausfallsicherheit sorgt. Dadurch ist gewährleistet, dass Ereignisse jederzeit sicher empfangen und gespeichert werden können. Unsere Dienste, die diese Daten nutzen, erben die gleiche Ausfallsicherheit von Amazon MSK. Sollten bei unseren Backend-Ingestion-Diensten Störungen auftreten, geht kein Ereignis verloren, da Kafka alle veröffentlichten Nachrichten behält. Wenn unsere Dienste wieder aufgenommen werden, setzen sie die Verarbeitung nahtlos dort fort, wo sie aufgehört haben, dank der Produzentensemantik von Kafka, die die Verarbeitung von Nachrichten je nach Anwendungsanforderungen genau einmal, mindestens einmal oder höchstens einmal ermöglicht.

Mit Amazon MSK können wir die Dauer der Datenaufbewahrung an unsere spezifischen Anforderungen anpassen und von Sekunden bis hin zu unbegrenzter Dauer reichen. Diese Flexibilität gewährleistet eine ununterbrochene Datenverfügbarkeit für unsere Anwendung, was mit unserer vorherigen Architektur nicht möglich war. Um die Datenintegrität im Falle von Verarbeitungsfehlern oder Korruption zu gewährleisten, ermöglichte uns Kafka außerdem die Implementierung eines Datenwiedergabemechanismus, der die Datenkonsistenz und -zuverlässigkeit gewährleistet.

Organisatorische Skalierung

Durch die Einführung einer ereignisgesteuerten Architektur mit Amazon MSK haben wir unsere monolithische Anwendung in lose gekoppelte, zustandslose Mikrodienste zerlegt, die asynchron über Kafka-Themen kommunizieren. Dieser Ansatz ermöglichte es unserer Engineering-Organisation, schnell von nur 4–5 Teams im Jahr 2019 auf heute über 40 Teams und etwa 350 Ingenieure zu wachsen.

Durch die lockere Kopplung zwischen Veranstaltungsherausgebern und -abonnenten konnten sich Teams auf unterschiedliche Bereiche wie Datenaufnahme, Identifikationsdienste und Data Lakes konzentrieren. Teams könnten unabhängig voneinander Lösungen innerhalb ihrer Domänen entwickeln und über Kafka-Themen ohne enge Kopplung kommunizieren. Diese Architektur beschleunigte die Funktionsentwicklung, indem sie das Risiko minimierte, dass sich neue Funktionen auf bestehende auswirken. Teams könnten von anderen veröffentlichte Ereignisse effizient nutzen, neue Funktionen schneller anbieten und gleichzeitig teamübergreifende Abhängigkeiten reduzieren.

Die folgende Abbildung veranschaulicht den nahtlosen Arbeitsablauf beim Hinzufügen neuer Domains zu unserem System.

Darüber hinaus ermöglichte das ereignisgesteuerte Design den Teams den Aufbau zustandsloser Dienste, die sich basierend auf MSK-Metriken wie Nachrichten pro Sekunde nahtlos automatisch skalieren ließen. Durch diese ereignisgesteuerte Skalierbarkeit entfällt die Notwendigkeit einer umfangreichen Kapazitätsplanung und manueller Skalierungsaufwände, wodurch Entwicklungszeit frei wird.

Durch den Einsatz einer ereignisgesteuerten Microservices-Architektur auf Amazon MSK haben wir organisatorische Agilität, verbesserte Skalierbarkeit und beschleunigte Innovation erreicht und gleichzeitig den Betriebsaufwand minimiert.

Nahtlose Skalierung der Infrastruktur

Das Geschäft von Nexthink verzehnfachte sich innerhalb von drei Jahren, und dem Produkt wurden viele neue Funktionen hinzugefügt, was zu einem erheblichen Anstieg des Datenverkehrs von 3 MB pro Sekunde auf 200 GB pro Sekunde führte. Dieses exponentielle Datenwachstum wurde durch die robuste Skalierbarkeit von Amazon MSK ermöglicht. Eine solche Größenordnung mit einer Lösung vor Ort zu erreichen, wäre schwierig und teuer, wenn nicht sogar unmöglich gewesen.

Der Versuch, Kafka selbst zu verwalten, verursachte unnötigen Betriebsaufwand, ohne einen geschäftlichen Mehrwert zu schaffen. Der Betrieb mit nur 5 % des heutigen Verkehrs war bereits komplex und erforderte zwei Ingenieure. Wir schätzten, dass wir bei den heutigen Volumina 6–10 engagierte Mitarbeiter benötigen würden, was die Kosten erhöhen und Ressourcen von den Kernprioritäten ablenken würde.

Echtzeitfähigkeiten

Indem wir alle unsere Daten über Amazon MSK kanalisierten, ermöglichten wir die Verarbeitung von Ereignissen in Echtzeit. Dadurch wurden Funktionen wie Echtzeitwarnungen, ereignisgesteuerte Auslöser und Webhooks freigeschaltet, die zuvor nicht erreichbar waren. Daher war Amazon MSK maßgeblich daran beteiligt, unsere ereignisgesteuerte Architektur zu ermöglichen und wirkungsvolle Innovationen voranzutreiben.

Sicherer Datenzugriff

Beim Übergang zu unserer neuen Architektur haben wir unsere Sicherheits- und Datenintegritätsziele erreicht. Mit Kafka-ACLs haben wir strenge Zugriffskontrollen durchgesetzt, sodass Verbraucher und Produzenten nur mit autorisierten Themen interagieren können. Wir basierten diese granularen Datenzugriffskontrollen auf Kriterien wie Datentyp, Domäne und Team.

Um die dezentrale Themenverwaltung sicher zu skalieren, haben wir proprietäres Management eingeführt Kubernetes Custom Resource Definitions (CRDs). Diese CRDs ermöglichten es Teams, ihre eigenen Themen, Einstellungen und ACLs unabhängig zu verwalten, ohne die Sicherheit zu beeinträchtigen.

Amazon MSK-Verschlüsselung stellte sicher, dass die Daten im Ruhezustand und während der Übertragung verschlüsselt blieben. Wir haben außerdem die Option „Bring Your Own Key“ (BYOK) eingeführt, die eine Verschlüsselung auf Anwendungsebene mit Kundenschlüsseln für alle Single-Tenant- und Multi-Tenant-Themen ermöglicht.

Verbesserte Beobachtbarkeit

Amazon MSK verschaffte uns einen hervorragenden Einblick in unsere Datenflüsse. Das Out-of-the-Box Amazon CloudWatch Metriken Lassen Sie uns die Menge und Art der Daten sehen, die durch jedes Thema und jeden Cluster fließen. Dies hat uns dabei geholfen, die Nutzung unserer Produktfunktionen zu quantifizieren, indem wir das Datenvolumen auf Themenebene verfolgt haben. Die Betriebsmetriken von Amazon MSK ermöglichten eine mühelose Überwachung und richtige Dimensionierung von Clustern und Brokern. Insgesamt erleichterte die umfassende Beobachtbarkeit von Amazon MSK datengesteuerte Entscheidungen über Architektur und Produktfunktionen.

Zusammenfassung

Der Weg von Nexthink von einem lokalen Monolithen zu einem Cloud-SaaS wurde durch den Einsatz von Amazon MSK, einem vollständig verwalteten Kafka-Dienst, optimiert. Amazon MSK ermöglichte uns eine nahtlose Skalierung und profitierte gleichzeitig von Zuverlässigkeit und Sicherheit auf Unternehmensniveau. Durch die Auslagerung des Kafka-Managements auf AWS konnten wir uns weiterhin auf unser Kerngeschäft konzentrieren und schneller Innovationen einführen.

Für die Zukunft planen wir, Leistung, Kosten und Skalierbarkeit durch die Einführung von Amazon MSK-Funktionen weiter zu verbessern abgestufter Speicher und AWS Graviton-basierte EC2-Instance-Typen.

Wir arbeiten außerdem eng mit dem Amazon MSK-Team zusammen, um uns auf kommende Servicefunktionen vorzubereiten. Die schnelle Einführung neuer Funktionen wird uns helfen, an der Spitze der Innovation zu bleiben und gleichzeitig unser Geschäft weiter auszubauen.

Um mehr darüber zu erfahren, wie Nexthink AWS nutzt, um seinen globalen Kundenstamm zu bedienen, erkunden Sie die Nexthink zur AWS-Fallstudie. Entdecken Sie außerdem weitere Kundenerfolgsgeschichten mit Amazon MSK, indem Sie die besuchen Amazon MSK-Blogkategorie.

Über die Autoren

Moe Haidar ist Chefingenieur und Leiter spezieller Projekte im CTO-Büro von Nexthink. Er ist seit 2018 bei AWS tätig und trägt maßgeblich zur Cloud-Transformation der Nexthink-Plattform zu AWS bei. Sein Schwerpunkt liegt auf der Produkt- und Technologieentwicklung sowie der Architektur, aber er liebt auch praktische Aktivitäten, um sein Wissen über Technologien auf dem neuesten Stand zu halten. Er leistet immer noch einen großen Beitrag zur Codebasis und liebt es, komplexe Probleme anzugehen.

Simone Pomata ist Senior Solutions Architect bei AWS. Er arbeitet seit mehr als 10 Jahren mit Begeisterung in der Technologiebranche. Bei AWS hilft er Kunden jeden Tag dabei, beim Aufbau neuer Technologien erfolgreich zu sein.

Magdalena Gargas ist ein Lösungsarchitekt mit Leidenschaft für Technologie und die Lösung von Kundenherausforderungen. Bei AWS arbeitet sie hauptsächlich mit Softwareunternehmen zusammen und unterstützt diese bei Innovationen in der Cloud. Sie nimmt an Branchenveranstaltungen teil, tauscht Erkenntnisse aus und trägt zur Weiterentwicklung des Containerisierungsbereichs bei.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/big-data/nexthink-scales-to-trillions-of-events-per-day-with-amazon-msk/