Skalierung von Slacks Datastores mit Vitess

• Die Geschichte, wie Slack seine Active-Active-Cluster-Architektur auf Vitess umgestellt hat, ein horizontales Skalierungssystem für MySQL

• Die Migration begann 2017; inzwischen verarbeitet Vitess 99 % aller Queries, und die vollständige Umstellung ist bis Jahresende geplant

→ Der aktuelle Spitzenwert liegt bei 2,3 Millionen QPS (2,0 Millionen Lesezugriffe, 300.000 Schreibzugriffe)

→ Die mediane Query-Latenz beträgt 2 ms, die p99-Query-Latenz 11 ms

• Slack startete mit einem LAMP-Stack (Linux, Apache, MySQL, PHP)

• Drei DB-Cluster

→ Shards: alle Nutzerdaten wie Nachrichten, Kanäle, DMs usw. Partitioniert nach Workspace-ID, sodass ein Workspace genau einem Shard zugeordnet ist

Das heißt, die Slack-App muss nur eine einzige DB ansprechen

→ Metadaten-Cluster: Lookup-Tabelle, um Workspaces mit Shards zu verknüpfen

→ Kitchen-Sink-Cluster: speichert alle Daten, die nicht zu einem bestimmten Workspace gehören, z. B. das App-Verzeichnis

• Das Sharding wurde von der monolithischen "webapp" verwaltet und koordiniert

• Jeder Cluster besteht aus einem oder mehreren Shards, und jeder Shard wird mit mindestens zwei MySQL-Instanzen in unterschiedlichen Rechenzentren provisioniert

• Vorteile der Active-Active-Konfiguration

→ Hohe Verfügbarkeit

→ Hohe Geschwindigkeit bei der Produktentwicklung

→ Einfaches Debugging

→ Einfache Skalierung

Mit dem Wachstum der Organisation und neuen Features der Produktteams verlangsamte sich jedoch die Entwicklungsgeschwindigkeit

• Nachteile von Active-Active

→ Grenzen der Skalierung: Mit größeren Kunden stieß man an die Grenzen dessen, was leistungsstarke Hosts aufnehmen konnten

→ Festlegung auf ein einziges Datenmodell:

Funktionen wie Enterprise Grid und Slack Connect widersprachen dem Paradigma, nur einen einzelnen Server anzusprechen

→ Hotspots: Die Datenbank-Fleet wurde nicht effizient genutzt. Es war schwierig, Shards aufzuteilen und Teams zu verschieben, und da die Slack-Nutzung schwer vorherzusagen war, wurden die meisten Shards überprovisioniert, was die Nutzung des Long Tail erschwerte

→ Probleme bei der Verfügbarkeit von Workspaces und Shards: Wenn es ein Problem mit einem Shard gab, konnten alle Kunden auf diesem Shard Slack nicht nutzen

→ Betrieb: Da es keine Standard-MySQL-Konfiguration war, mussten viele interne Tools geschrieben werden

• Im Herbst 2016 verwaltete Slack bereits Hunderttausende MySQL-Queries pro Sekunde und Tausende geshardete MySQL-Hosts

• Regelmäßig traten Skalierungs- und Performance-Probleme auf, daher dachte man über einen neuen Ansatz nach

• Es wurde erwogen, das Bestehende weiterzuentwickeln oder ein neues Produkt einzuführen, aber

→ man wollte weiterhin MySQL nutzen, das in der eigenen Cloud läuft

→ es gab Tausende individueller Queries, von denen einige spezielle MySQL-Konfigurationen nutzten

→ Deployment, Backups, Data-Warehouse-ETL, Compliance usw. basierten alle auf MySQL

• Warum Vitess? Es erfüllte die meisten Anforderungen der App und des Betriebs

→ MySQL Core: Vitess basiert auf MySQL

→ Scalability: kombiniert die Hauptfunktionen von MySQL mit der Skalierbarkeit von NoSQL-Datenbanken. Dank integriertem Sharding ist flexible Skalierung ohne zusätzliche Speziallogik möglich

→ Operability: verarbeitet Failover, Backups usw. standardmäßig automatisch. Verfolgt Metadaten zur Cluster-Konfiguration und sorgt so für Konsistenz

→ Extensibility: Go-basiertes Open Source mit umfassender Testabdeckung und einer offenen Entwickler-Community

• Der praktische Einsatz von Vitess begann mit kleinen Features

→ 2017 wurde testweise eine Funktion entwickelt, die RSS-Feeds in Slack-Kanäle integriert

→ 2018 wurden alle neuen Tabellen nur noch auf Vitess angelegt

→ Mitte 2019 gab es bereits mehr Schreibzugriffe auf Vitess als auf die Legacy-DB

→ Slack hat außerdem fortlaufend zum Vitess-Open-Source-Projekt beigetragen

→ Über drei Jahre wurden 99 % auf Vitess migriert; das verbleibende 1 % soll noch dieses Jahr abgeschlossen werden

• War die Einführung von Vitess bei Slack erfolgreich?

→ In mehreren Regionen weltweit betreiben mehrere Vitess-Cluster Dutzende Keyspaces

→ Keyspaces sind logische Sammlungen, die je nach Anzahl von Nutzern, Teams und Kanälen skalieren

→ Durch flexibles Sharding konnte Slack besser skaliert werden

→ Während COVID-19 stieg die Zahl der Slack-Queries innerhalb einer Woche um 50 %

→ Die am stärksten ausgelasteten Keyspaces wurden mit dem Split-Workflow von Vitess horizontal skaliert

→ Früher wäre diese Skalierung nicht möglich gewesen, und es wäre zu Downtime gekommen.

[xguru]

https://vitess.io/

Vitess: "Sharding Middleware for MySQL"

• Eine Lösung, die entwickelt wurde, um MySQL und MariaDB in der Cloud einfach bereitzustellen, zu skalieren und zu verwalten

• Betreibt und verwaltet MySQL-Shards auf Docker (lokal) und Kubernetes

• Anwendungen verwenden einen Proxy namens VTGate, als würden sie mit MySQL kommunizieren; intern verbindet er sich per gRPC mit anderen Servern

[xguru]

Auch der E-Mail-Dienst Hey nutzt Vitess.

Der Tech-Stack von Hey: https://de.news.hada.io/topic?id=2355