PlusPlus

Herausforderung

PlusPlus ist ein Chatbot für Slack, der für Unterhaltung gedacht ist. Er ermöglicht es, Dinge, die Ihre Freunde in Slack sagen und tun, mit „Plus“, „Minus“ und Bewertungen zu versehen, indem man sich auf Objekte und Benutzer mit „@“ bezieht. Es gibt ein globales Leaderboard und jede Aktion beeinflusst die allgemeinen Ergebnisse.

Die Herausforderung für das Redwerk-Team bestand darin, den bestehenden Bot, der ursprünglich in Python entwickelt wurde, komplett neu zu schreiben und Ruby als Kerntechnologie zu verwenden. Wir mussten auch die Stabilität erhöhen, die Skalierbarkeit ermöglichen und die Gesamtleistung dieses hochbelasteten Projekts optimieren.

Lösung

Wir begannen mit dem wichtigsten Teil – der Code-Refaktorisierung und -Reparatur. Die alte Version des Bots war in Python geschrieben und wir mussten sie auf Ruby portieren, dabei alle zusätzlichen Änderungen berücksichtigen, bestehende Probleme beheben und neue Funktionen implementieren. Als die Infrastruktur geplant wurde, basierten wir unsere Annahmen zur Last auf den durchschnittlichen Statistiken der Nutzung des alten Python-Bots: ca. 500-700 Tausend Benutzeraktionen pro Minute. Wir erweiterten dieses Niveau auf ~1 Million Benutzeraktionen pro Minute, um eine gewisse Reservekapazität zu haben, und führten eine Reihe von Stresstests auf der Staging-Umgebung durch.

Hier trat eine weitere Herausforderung auf. Es stellte sich heraus, dass Slack das Testen auf 1 Nachricht pro Sekunde beschränkt und keine Funktionalität zur Prüfung hochbelasteter Projekte bietet. Die tatsächliche Live-Belastung von PlusPlus zeigte über 20-50 Millionen Aktionen pro Minute, und die bestehende Infrastruktur konnte dies nicht unterstützen. Um die neue Nachfrage zu decken, musste ein großer Teil der Anwendungslogik überarbeitet werden.

Optimierung der Benutzer- und Objektlogik

Das Entwicklungsteam von Redwerk musste sorgfältig alle Lücken und selbst die kleinsten Speicher- und CPU-Nutzungslücken definieren und optimieren. Die tatsächliche Projektlast sendete Millionen von Aktionen, die sowohl @Benutzernamen als auch @Dinge in einer einzigen Zeile enthielten. Objekte erforderten eine fortschrittlichere Logik als Benutzer, da sie geparst, dann überprüft werden mussten, ob sie in der Datenbank existieren, ein neuer Eintrag erstellt werden musste, falls nicht, dann die Bewertung aktualisiert, das Leaderboard und das globale Trending aktualisiert werden mussten. Mit Millionen solcher Aktionen, die meist in einer einzigen Nachricht vorkamen, wurde die Datenbank sehr schnell überlastet, ebenso wie der Speicher und die CPU.

Eine weitere hochbelastete Aufgabe war die Optimierung der Bewertungsaktualisierungen in den Leaderboards, da jede Aktion die Position in den globalen Leaderboards der Benutzer und Objekte beeinflussen musste. Die unglaublich hohe Anzahl an Elementen, die geparst, überprüft und aktualisiert werden mussten, stellte zusätzliche Herausforderungen für die Entwicklung dar.

Um all diese Aktionen zu optimieren, entwickelte unser Team eine Funktionalität, die mehrere CPU-Kerne auf jedem Server nutzt, zusammen mit einem speziellen Bot-Manager, der jeden Bot einem bestimmten Knoten (Server + CPU-Kern) zuweist – eine Art Aufgabe, die der Amazon-Load-Balancer nicht bewältigen konnte. Danach haben wir die Anforderungslogik neu aufgebaut, um die Anzahl der Anfragen zu reduzieren.

Wir sind auch von Ubuntu zu CentOS gewechselt. Ubuntu erlaubte uns nicht, zusätzliche Verbindungen zu einer Datenbank zu erstellen. CentOS bot hingegen eine stabilere Umgebung beim Arbeiten mit MongoDB und unterstützte die übermäßige Aktionslast. Es ermöglichte uns auch, den AWS-Server neu zu konfigurieren und die Kernel-Einstellungen des Betriebssystems auf den Knoten zu aktualisieren, um die Dateideskriptor- und Thread-Limits zu verbessern.