Réarchitecturation : passer de Redis à SQLite

Contexte

• Wafris est une entreprise open source de pare-feu pour applications web, qui fournit un client middleware Rails
• Le client v1 initial nécessitait un stockage de données Redis local, mais l’entreprise lance désormais un client v2 utilisant SQLite
• Cet article traite du processus de décision de migration de Redis vers SQLite, des considérations de performance et des changements d’architecture

Résumé

• SQLite, Redis et les SGBD relationnels traditionnels (Postgres/MySQL) ont chacun leurs avantages et leurs inconvénients
• Ces stockages de données ne sont pas interchangeables, et essayer de les substituer les uns aux autres peut poser problème
• Cet article explique le processus de refonte du client v1 basé sur Redis en un client v2 basé sur SQLite

Pourquoi ce changement a-t-il été imposé ?

• L’objectif de Wafris est de permettre aux développeurs de protéger facilement leurs sites
• Le client v1 utilisait un stockage Redis, mais de nombreux utilisateurs rencontraient des problèmes de déploiement de Redis
• Le passage à SQLite vise à leur éviter la charge de devoir devenir administrateurs Redis

Qu’est-ce que la vitesse ?

• Redis est rapide par rapport aux SGBD relationnels traditionnels, mais il reste encore beaucoup d’éléments à gérer
• Dans le cloud, la latence réseau constitue un problème majeur
• SQLite peut offrir de meilleures performances en réduisant les allers-retours réseau

L’hypothèse monolithique

• De nombreuses applications distribuées rencontrent des problèmes avec l’usage de Redis
• L’architecture a été repensée pour réduire la complexité liée à l’utilisation de Redis

Adoption de SQLite

• SQLite réduit les goulots d’étranglement liés aux IO réseau
• SQLite rivalise avec l’ouverture d’un fichier (fopen()), et non avec une base de données client/serveur

Benchmark SQLite vs Redis

• SQLite est environ 3 fois plus rapide que Redis dans certains cas d’usage
• Même sans prendre en compte la latence réseau, SQLite reste plus rapide

Ce qui manque dans les graphiques

• Même si les performances de SQLite étaient moins bonnes dans les benchmarks, il peut être plus rapide en conditions réelles à cause de la latence réseau
• SQLite facilite la montée en charge horizontale et réduit la charge d’installation et de configuration pour les utilisateurs

Mise en place d’une architecture de synchronisation

• En v1 (Redis), lorsqu’un utilisateur mettait à jour les règles, celles-ci étaient mises à jour dans le stockage Redis
• En v2 (SQLite), le client vérifie périodiquement les règles mises à jour et télécharge une nouvelle base de données SQLite

Architecture distribuée avec SQLite

• Le problème de goulot d’étranglement de la base de données est résolu en synchronisant la base SQLite sur chaque instance de calcul

Conclusion

• L’architecture v2 basée sur SQLite aide de nombreux sites à résister aux attaques et à rester en ligne
• Elle impose moins de contraintes aux utilisateurs et contribue à un Internet plus sûr et mieux sécurisé

Le résumé de GN⁺

• Cet article explique le processus de migration de Redis vers SQLite et les raisons de ce choix
• SQLite améliore les performances en réduisant la latence réseau et diminue la charge d’installation et de configuration pour les utilisateurs
• L’architecture distribuée de SQLite résout les problèmes de goulot d’étranglement de la base de données
• Cet article apporte des enseignements sur la manière de déployer facilement un pare-feu d’application web et de le faire fonctionner rapidement

[GN⁺]

Commentaires sur Hacker News

• Intérêt pour un modèle où chaque serveur applicatif copie le fichier de base de données SQLite et le remplace périodiquement

  • Utilisé pour les règles de pare-feu d’applications web
  • Pourrait aussi servir à la configuration des feature flags
  • Quelques secondes de délai pour mettre à jour des feature flags sont acceptables

• La latence en lecture/écriture de Redis est proportionnelle au nombre de clés interrogées

  • Une application monolithique utilisant Postgres et Redis fonctionnait bien
  • Redis étant mono-thread, une fonctionnalité de lecture massive peut ralentir les autres tâches
  • Redis est bien adapté à la lecture et à l’écriture d’une clé ou d’un petit ensemble fixe de clés
  • Il était intéressant de voir que SQLite offrait de bonnes performances par rapport à une instance Redis locale

• Le jeu de données semble contenir 1,2 million d’éléments, mais il n’est en réalité pas très volumineux

  • Les adresses IPv4 représentent 4,8 Mo, et pourraient être encore réduites avec une compression simple
  • Si Ruby prenait en charge mmap, il serait préférable d’utiliser directement une liste d’IP

• Lors d’un hackathon interne chez Neon, un serveur Node.js a été écrit pour traduire le protocole de Redis en requêtes Postgres

  • C’était un projet de bidouillage amusant

• À RailsWorld 2023, il y avait une certaine tonalité négative autour de Redis

  • L’hypothèse était qu’un serveur Redis était nécessaire
  • Avec peu d’expérience sur Redis, la question se pose de savoir si l’écosystème actuel est devenu hostile à Redis

• SQLite semble correspondre à un cas d’usage de niche où il fonctionne bien côté serveur sans réplication

  • Une autre alternative serait d’utiliser un fichier statique chargé en mémoire
  • SQLite est une bonne alternative

• Il existe un projet appelé Redka, qui implémente Redis avec SQLite

• Meilleure citation : "SQLite ne concurrence pas les bases de données client/serveur. SQLite concurrence fopen()."

• Redis est plus rapide qu’un SGBDR traditionnel, mais il demande de l’administration

  • Toutes les bases de données nécessitent un certain niveau d’administration
  • Si l’on ne se soucie pas des jointures, l’insertion et la recherche de lignes sont aussi très rapides

• Le benchmarking est un art obscur qui consiste à se tromper soi-même avec des chiffres d’une précision extrême