Rearchitektur: Wechsel von Redis zu SQLite

Hintergrund

• Wafris ist ein Open-Source-Unternehmen für Web Application Firewalls und bietet einen Rails-Middleware-Client an
• Der ursprüngliche v1-Client benötigte einen lokalen Redis-Datenspeicher, nun wurde jedoch ein v2-Client veröffentlicht, der SQLite verwendet
• Dieser Artikel behandelt den Entscheidungsprozess bei der Migration von Redis zu SQLite, Performance-Überlegungen und Architekturänderungen

Zusammenfassung

• SQLite, Redis und traditionelle RDBMS (Postgres/MySQL) haben jeweils Vor- und Nachteile
• Diese Datenspeicher sind nicht gegeneinander austauschbar, und der Versuch dazu kann Probleme verursachen
• Dieser Artikel beschreibt den Prozess, den Redis-basierten v1-Client in einen SQLite-basierten v2-Client umzubauen

Warum wurde diese Änderung erzwungen?

• Das Ziel von Wafris ist es, Entwicklern zu ermöglichen, ihre Websites einfach zu schützen
• Der v1-Client nutzte einen Redis-Datenspeicher, jedoch hatten viele Nutzer Probleme mit der Bereitstellung von Redis
• Um Nutzern die Last zu nehmen, selbst Redis-Administratoren zu werden, erfolgte der Wechsel zu SQLite

Was ist Geschwindigkeit?

• Redis ist schneller als traditionelle RDBMS, bringt aber weiterhin viel Verwaltungsaufwand mit sich
• In Cloud-Umgebungen ist Netzwerklatenz ein großes Problem
• SQLite kann durch die Reduzierung von Netzwerk-Roundtrips eine höhere Performance bieten

Monolithische Annahmen

• Viele verteilte Anwendungen verursachen Probleme beim Einsatz von Redis
• Um die Komplexität der Redis-Nutzung zu reduzieren, wurde die Architektur neu überdacht

Einführung von SQLite

• SQLite reduziert Engpässe bei der Netzwerk-I/O
• SQLite konkurriert mit dem Öffnen von Dateien (fopen()) und nicht mit Client/Server-Datenbanken

Benchmarking von SQLite und Redis

• SQLite ist in bestimmten Anwendungsfällen etwa dreimal schneller als Redis
• Auch ohne Berücksichtigung von Netzwerklatenz ist SQLite schneller

Was in den Diagrammen fehlt

• Selbst wenn SQLite in Benchmarks schlechter abschneidet, kann es in realen Umgebungen aufgrund der Netzwerklatenz dennoch schneller sein
• SQLite lässt sich leicht horizontal skalieren und reduziert den Installations- und Konfigurationsaufwand für Nutzer

Aufbau einer Synchronisierungsarchitektur

• In v1 (Redis) wurden bei Regel-Updates durch den Nutzer die Änderungen im Redis-Datenspeicher gespeichert
• In v2 (SQLite) prüft der Client regelmäßig auf aktualisierte Regeln und lädt eine neue SQLite-Datenbank herunter

Verteilte Architektur mit SQLite

• Durch die Synchronisierung der SQLite-DB auf jede Compute-Instanz werden Datenbank-Engpässe vermieden

Fazit

• Die SQLite-basierte v2-Architektur hilft vielen Websites, Angriffe zu überstehen und online zu bleiben
• Sie verringert den Aufwand für Nutzer und trägt zu einem sichereren, besser geschützten Internet bei

Zusammenfassung von GN⁺

• Dieser Artikel erklärt den Migrationsprozess von Redis zu SQLite und die Gründe dafür
• SQLite verbessert die Performance, indem es Netzwerklatenz reduziert, und verringert den Installations- und Konfigurationsaufwand für Nutzer
• Die verteilte Architektur von SQLite löst Datenbank-Engpässe
• Der Artikel bietet Einblicke, wie sich eine Web Application Firewall einfach bereitstellen und schnell betreiben lässt

[GN⁺]

Hacker-News-Kommentare

• Interesse an einem Modell, bei dem jeder Anwendungsserver eine SQLite-Datenbankdatei kopiert und regelmäßig austauscht

  • Wird für Regeln einer Web Application Firewall verwendet
  • Könnte auch für die Konfiguration von Feature Flags genutzt werden
  • Bei Feature Flags ist es in Ordnung, wenn Updates ein paar Sekunden dauern

• Die Lese-/Schreiblatenz von Redis ist proportional zur Anzahl der abgefragten Schlüssel

  • Eine monolithische App mit Postgres und Redis hat gut funktioniert
  • Redis ist Single-Threaded, daher können umfangreiche Lesevorgänge andere Arbeiten verlangsamen
  • Redis eignet sich gut zum Lesen und Schreiben einzelner Schlüssel oder kleiner, fester Schlüsselmengen
  • Es war interessant, dass SQLite im Vergleich zu einer lokalen Redis-Instanz leistungsstark war

• Der Datensatz sieht nach 1,2 Millionen Einträgen aus, ist tatsächlich aber nicht groß

  • IPv4-Adressen belegen 4,8 MB und könnten mit einfacher Komprimierung noch kleiner werden
  • Wenn Ruby mmap unterstützen würde, wäre es gut, die IP-Liste direkt zu verwenden

• Bei einem internen Hackathon von Neon wurde ein Node.js-Server geschrieben, der das Redis-Protokoll in Postgres-Abfragen umwandelt

  • Das war ein unterhaltsames Hacking-Projekt

• Auf der RailsWorld 2023 gab es eine negative Stimmung gegenüber Redis

  • Es gab die Annahme, dass ein Redis-Server nötig sei
  • Wegen geringer eigener Erfahrung mit Redis kam die Frage auf, ob das aktuelle Ökosystem gegen Redis eingestellt ist

• SQLite scheint ein Nischen-Anwendungsfall zu sein, der serverseitig auch ohne Replikation gut funktioniert

  • Eine andere Alternative wäre, eine in den Speicher geladene statische Datei zu verwenden
  • SQLite ist eine gute Alternative

• Es gibt ein Projekt namens Redka, das Redis mit SQLite implementiert

• Bestes Zitat: "SQLite konkurriert nicht mit Client/Server-Datenbanken. SQLite konkurriert mit fopen()."

• Redis ist im Vergleich zu traditionellen RDBMS schnell, erfordert aber Verwaltung

  • Jede Datenbank erfordert ein gewisses Maß an Verwaltung
  • Wenn man sich nicht um Joins kümmern muss, sind auch das Einfügen und Abrufen von Zeilen sehr schnell

• Benchmarking ist eine dunkle Kunst, mit sehr präzisen Zahlen sich selbst zu täuschen