SentiOne

SentiOne, das von Deloitte als eines der am schnellsten expandierenden Technologieunternehmen in Mitteleuropa anerkannt wurde, bietet eine einzigartige Conversational KI-Plattform, mit der Sie Online-Diskussionen beaufsichtigen, mit Ihrem Publikum in Kontakt treten und den Kundenservice über alle Webkanäle hinweg automatisieren können.

Während die meisten KI-Unternehmen, die Chatbots anbieten, Probleme mit Trainingsressourcen haben, nutzt SentiOne reale Internet-Diskussionen, um seine NLU-(Natural Language Understanding)-Engine zu trainieren. Dank des umfangreichen Datenbestandes, der bei der Entwicklung eines umfassenden Social-Listening-Tools gesammelt wurde, ist SentiOne in der Lage, besonders genaue Deep-Learning-Engines zu trainieren.

„Im Laufe unserer mehrjährigen Zusammenarbeit mit OVHcloud waren wir in der Lage, unser Geschäft reibungslos zu skalieren und Terabyte an Daten zu verarbeiten, um unseren Kunden qualitativ hochwertige Erkenntnisse zu verschaffen."

Michał Brzezicki, Mitbegründer und Chief Technical Officer von SentiOne

Aufgrund der zunehmenden Menge an Daten, die in Echtzeit gesammelt und analysiert werden müssen, stand das Unternehmen vor zahlreichen Herausforderungen in den Bereichen Infrastruktur und Software. Zum einen verringerte sich die Leistung des Elasticsearch-Clusters, die für ein reibungsloses Kundenerlebnis auf der Plattform entscheidend ist. Zum anderen stellte SentiOne fest, dass bestimmte Cluster unverhältnismäßig stark beansprucht wurden, was bei einigen zu einer Überlastung führte, während andere ungenutzt blieben.

Um die Geschwindigkeit seiner Conversational KI-Plattform zu verbessern, startete SentiOne einen umfangreichen Wartungsplan, um die Hardware zu migrieren und gleichzeitig die Software zu aktualisieren. Michał Brzezicki, Mitbegründer und CTO von SentiOne, sprach mit uns, um im Detail zu erläutern, wie dieses komplexe Projekt von seinem Team gemanagt wurde.

Das IT-Expertenteam von SentiOne listete mehrere mögliche Gründe auf, die zum Leistungsabfall eines Elasticsearch-Clusters führen können, darunter unzureichende CPU- oder Speicherleistung, Hardwareausfälle, fehlerhafte Softwarekonfiguration sowie Verbindungs- und Netzwerkprobleme.

Netzwerk
Elasticsearch ist sehr anfällig für Verbindungsprobleme. Wenn zwischen zwei Nodes im Cluster eine Netzwerkinstabilität auftritt, verlangsamt sich der gesamte Cluster. Um zuverlässige und sichere Verbindungen zwischen den Nodes zu gewährleisten, entschied sich SentiOne für vRack, eine von OVHcloud entwickelte private Netzwerklösung.

Die Netzwerkprobleme waren nach der Aktivierung dieser Lösung nahezu dauerhaft gelöst, da SentiOne mithilfe von vRack unabhängig vom öffentlichen Netzwerk stabile Verbindungen zwischen Nodes herstellen konnte.

Für ein tieferes Verständnis für den Zustand seiner Infrastruktur benutzt das SentiOne-Team Grafana mit Sensu-Plugin, um alle Statuswerte des Systems und von Elasticsearch zu speichern. Da weder mit öffentlichen noch mit vRack Interfaces Anomalien festgestellt wurden, konnte das Team das Netzwerk als Ursache der Performance-Probleme ausschließen.

CPU
Bei der weiteren Suche nach möglichen Ursachen von Leistungsabfällen sah sich das Team die CPU-Auslastung und das Thread-Management genauer an. Die allgemeine CPU-Auslastung im Cluster betrug knapp 80 %, was als angemessen betrachtet wurde, da sie, gemessen an den Kosten, auf eine vernünftige Nutzung der Ressourcen hindeutete. Das Team stellte jedoch fest, dass der Cluster während des Rebalancings erheblich langsamer war.

In Verlangsamungsphasen war die CPU-Auslastung gering und auf nur einen Kern beschränkt. Eine eingehendere Analyse ergab, dass der größte Teil der CPU-Zeit für I/O-Operationen benutzt wurde. Da das Team das Netzwerk bereits als Ursache ausgeschlossen hatte, begann es daher, die Speicherung zu untersuchen.

Speicher
Dank der Einrichtung eines Grafana-Dashboards für die I/O-Zeitmessung von Sensu erhielt das SentiOne-Team schließlich Antworten. Aus dem Ergebnisdiagramm ging deutlich hervor, wie viel Zeit die CPU in einem bestimmten Zeitraum für I/O-Operationen aufwendete. Es stellte sich heraus, dass diese Zahl sich auf fast 100 % belaufen konnte!

Das erklärte auch, warum sich der Cluster während des Rebalancings verlangsamt hatte. Wenn ein zufälliger Node, von dem ein Shard kopiert wurde, unter hoher I/O-Belastung stand, verschlimmerte das Kopieren des Shards alles nur.

Elasticsearch-Cluster-Konfiguration
Die SentiOne-Infrastruktur basierte auf „heißen und kalten“ Nodes. Die Hot Nodes enthielten beliebte, regelmäßig abgefragte Indizes, während die Cold Nodes Daten enthielten, auf die nur selten zugegriffen wurde. Obwohl das Hinzufügen weiterer Replika-Nodes für heiße Indizes eine scheinbar naheliegende Lösung für eine ausgewogenere Lastverteilung war, erwies sich dies als Irrtum. Erstens wurden Abfragen den Shards nach dem Zufallsprinzip zugeordnet. Wenn daher eine stark belastende Abfrage oft wiederholt wurde (z. B. verschiedene Aggregationen derselben Abfrage), dann wurden alle Replikas mit ähnlichen oder gleichen Berechnungen überlastet. Außerdem ermöglichte die damals auf dem SentiOne-Cluster installierte Elasticsearch-Version keine Adaptive Replica Selection (ARS). Es wurde deutlich, dass neue Nodes im Cluster die Leistung nicht skalieren würden, solange das Team die Software nicht aktualisierte.

Nachdem das IT-Team die Bottlenecks identifiziert hatte, die für den Leistungsabfall des Elasticsearch-Clusters verantwortlich waren, konnte es mit der Planung von Software-, Architektur- und Hardwareänderungen beginnen, um die Reaktionsfähigkeit der Plattform zu verbessern.

Der Austausch der Hardware und die horizontale Skalierung der Cluster schien die nächstliegende Option zu sein. Da allerdings das SentiOne-Budget zwar groß, aber nicht grenzenlos war, begann man mit der Bereinigung der Cluster-Nutzung.

Bevor das Team bereit war, auf eine neue Dedicated-Server-Infrastruktur zu migrieren, mussten noch einige andere Dinge erledigt werden.

Intelligentere Datenaufteilung
Zunächst analysierten die SentiOne-Ingenieure Benutzerabfragen und ihre Auswirkungen auf die Cluster-Performance. Es besteht ein direktes Verhältnis zwischen der Abfragezeit und der Anzahl und Größe abgefragter Shards. Je größer die Shards, desto länger dauert jede Abfrage, und je mehr Shards abgefragt werden, desto länger dauert der Gesamtprozess.

Um die Abfragezeit zu verbessern, beschloss SentiOne, die Daten in kleinere Shards von maximal 30 GB aufzuteilen. Einmal abgefragt, passten so die Daten eines einzelnen Shards zumindest theoretisch in den Dateisystem-Cache im RAM.

Nachdem man die von den Benutzern abgefragten Zeiträume analysiert hatte, änderte SentiOne auch die Art und Weise, wie Daten in Indizes aufgeteilt wurden. Sie unterteilten die Daten entsprechend dem Nutzerverhalten, reduzierten die Anzahl der Shards pro Abfrage und verkürzten die Spanne von monatlichen auf wöchentliche Indizes.

Umsetzung
Das SentiOne-Team überarbeitete die Punkte, an denen der Elasticsearch-Cluster abgefragt wird, optimierte die Aufrufe und änderte die Benutzeroberfläche, damit die Benutzer nicht mehr den Eindruck hatten, dass das System „einfriert“. Sie führten auch Kontrollen ein, die übermäßig belastende Abfragen blockieren, und zwar basierend auf den Ausführungszeiten innerhalb eines gleitenden Zeitrahmens. In der Vergangenheit konnte eine einzige belastende Abfrage die Leistung des gesamten Clusters beeinträchtigen. Diese Sicherheitskontrolle war daher eine Notwendigkeit, auch wenn einige Benutzer dadurch Einschränkungen hinnehmen mussten.

Architekturänderungen
Mit der neuen Version des Clusters hat SentiOne sich aus mehreren Gründen vom „Heiß-kalt“-Ansatz verabschiedet. Erstens ist es schwierig, eine klare Unterscheidung zwischen heißen und kalten Indizes vorzunehmen. Ab wann gilt ein Index als „heiß“? Zweitens hatten die Cold Nodes eine sehr geringe I/O-Auslastung mit Spitzen der CPU-Auslastung, während die Hot Nodes durch I/O überlastet wurden, aber ungenutzte CPU-Ressourcen hatten. Dies war eine offensichtliche Verschwendung von Ressourcen und damit auch von Geld. Schließlich erwies sich die Suche nach dem richtigen Gleichgewicht zwischen Hot und Cold Nodes als knifflig und zog unnötige Kosten nach sich.

Neue Hardware
Die bisherige Infrastruktur bestand aus drei Master-Nodes, 82 Hot und 42 Cold Nodes, die alle mit derselben Speicherlösung ausgestattet waren: zwei Intel-SSD-DC-S4500-Laufwerken. Da das Hauptziel der Hardware-Migration die Verbesserung der Speicherleistung war, beschloss SentiOne, für seine neuen Data-Nodes Server der Advance Reihe, insbesondere ADV-2-Modelle mit NVMe-Laufwerken, einzusetzen.

NVMe-Festplattentechnologie ist eine Kombination aus Solid-State-Laufwerken, PCIe-Bussen und NVMe-Protokoll. Entwickelt wurde sie, um die Diskrepanz zwischen Rechen- und Speicherleistung zu überbrücken.

Die Schnittstelle zwischen den SSDs hat unter Umständen beträchtlichen Einfluss auf die Gesamtlatenzzeit, die der Benutzer auf Anwendungsebene erlebt, während zwei Elemente – die physische Schnittstelle (PCIe) und das Protokoll (NVMe) – die Gesamtleistung bestimmen. Eine PCIe 3.0 x4-Verbindung bietet fast fünfmal mehr Durchsatz als die schnellste SATA- und fast dreimal mehr als die beste SAS-Schnittstelle. Das NVMe-Protokoll lässt bis zu 64 000 Warteschlangen zu und gewährleistet so, dass die Schnittstelle die hohe Anzahl an I/O-Threads bewältigen kann, die von Multicore-CPUs erzeugt werden.

Um den neuen Cluster aus 121 Data-Nodes und drei Master-Nodes einzurichten, investierte SentiOne zwei Monate in Entwicklung, Tests und Planung. Obwohl die Migration und das Elasticsearch-Upgrade nicht ganz reibungslos abliefen und zu sechs Stunden Ausfallzeit des Clusters führten, brachten sie dennoch die erwarteten Vorteile mit sich.

Die Omnichannel-Plattform von SentiOne überwacht Milliarden von Diskussionen über Tausende von Webquellen hinweg. Um Unternehmen Erkenntnisse über das Publikum zu vermitteln und die KI-gestützte Automatisierung des Kundenservice zu ermöglichen, werden riesige Datenmengen gesammelt, verarbeitet und analysiert. Daher spielt die Speicherleistung eine zentrale Rolle.

Der neue Cluster, der auf ADV-2 Dedicated Servern basiert und mit NVMe-Laufwerken ausgestattet ist, brachte SentiOne den entscheidenden Durchbruch. Die Hardware-Migration hat zu einem sofortigen Leistungsschub geführt, und der Cluster ist jetzt sechs Mal schneller als zuvor.

Durch das Versionsupdate von Elasticsearch – wozu auch die Einrichtung der ARS-Funktion gehörte – kann der Cluster nun gleichmäßiger arbeiten und die Last in Stoßzeiten gleichmäßig über mehrere Nodes verteilen. Die Messungen des Teams ergaben, dass sich die Last im regulären Betrieb der 50-%-Marke nähert und auch unter hoher Belastung 80 % nicht überschreitet. So verfügt SentiOne über eine gesunde Reserve für zukünftige Skalierungen und neue Funktionen.

„Hinsichtlich des Budgets erwies sich der Migrationsprozess als äußerst vorteilhaft. Die Kosten für den Betrieb des Clusters wurden um circa 5 % gesenkt, und das bei erheblicher Verbesserung der Leistung."

Michał Brzezicki, Mitbegründer und Chief Technical Officer von SentiOne