Construire un service web hautement disponible sans base de données

Construire un service web hautement disponible sans base de données

Exploration

• Pour une nouvelle startup, on choisit généralement un framework web comme Rails, Django ou Node, ainsi qu'une base de données comme MySQL, PostgreSQL ou MongoDB
• Mais que se passerait-il s'il était possible de fusionner le service web et l'instance de base de données en un seul ensemble ? Il est possible d'adopter une approche où toutes les données sont stockées en RAM
• En utilisant la RAM comme base de données, il n'est plus nécessaire de sérialiser les données via des requêtes SQL
• Les index peuvent être implémentés à l'aide de tables de hachage en mémoire
• Les tâches en arrière-plan peuvent être traitées par des threads au sein d'un grand processus
• En cas de crash du processus, la récupération est possible en prenant périodiquement des instantanés de la RAM et en enregistrant les modifications sur disque

Passage à l'échelle

• Lorsqu'apparaissent des clients exigeant une haute disponibilité, les serveurs sont répliqués à l'aide de l'algorithme de consensus Raft
• Si le serveur leader tombe en panne, un nouveau leader est élu pour traiter les requêtes
• Cette approche permet des déploiements progressifs sans redémarrer les serveurs

Extraction

• Lorsqu'il y a beaucoup de grands clients, il est possible de répartir le service web par sharding
• Un cluster dédié est fourni à chaque client entreprise
• Le principal goulet d'étranglement peut être la performance du thread de commit

Notre stack

• Utilisation de Common Lisp : excellente prise en charge du multithreading et bien adapté au hot reloading du code
• Utilisation de bknr.datastore et bknr.cluster : la bibliothèque Braft de Baidu est utilisée pour implémenter Raft
• Utilisation d'EFS pour stocker les fichiers image : la gestion des erreurs et les tests y sont plus simples qu'avec S3

Résumé

• Cette architecture convient bien aux nouvelles startups, et avec Common Lisp, de nombreux outils sont déjà disponibles
• Merci aux contributeurs de bknr.datastore, Braft et Raft

Le récapitulatif de GN⁺

• Cet article présente une nouvelle architecture pour construire un service web hautement disponible sans base de données
• La RAM est utilisée comme base de données, et la haute disponibilité est assurée via l'algorithme de consensus Raft
• Common Lisp est utilisé pour prendre en charge le multithreading et le hot reloading du code
• Cette architecture convient aux nouvelles startups et permet un développement et un débogage rapides
• Parmi les projets offrant des fonctionnalités similaires, on peut citer Redis et Memcached

[GN⁺]

Avis Hacker News

• Créer son propre journal de transactions au lieu d’utiliser SQLite, c’est étrange

  • Si les données tiennent sur un seul serveur, mieux vaut simplement exécuter la base de données sur ce serveur
  • Si les données tiennent en RAM, utiliser un ramdisk et répliquer vers un stockage persistant avec des outils standard est plus simple

• Créer sa propre base de données en mémoire au lieu d’utiliser MySQL, Postgres, Redis ou MongoDB est complexe

  • Il faut sérialiser les transactions et les écrire sur disque
  • Il faut synchroniser les journaux de transactions entre les serveurs web et mettre à jour la base de données en mémoire
  • Il faut écrire un algorithme de résolution des conflits
  • Il faut sharder les serveurs web par tenant et écrire une couche de load balancing

• Ne pas vouloir apprendre les aspects de base de MySQL ou Postgres est une perte de temps

  • En l’exécutant chez un fournisseur de cloud public, on peut résoudre les problèmes de concurrence avec le tuning par défaut
  • Ajouter 10 millions de lignes n’est pas un gros problème
  • Il est plus sage d’attendre qu’une situation pire se présente avant de la résoudre

• C’est une architecture similaire à celle de HashiCorp avec Nomad, Consul et Vault

  • L’expérience développeur est bonne
  • On peut configurer l’état en mémoire comme on le souhaite
  • Ce n’est pas adapté à une nouvelle startup
  • Les mises à niveau sont particulièrement difficiles

• Il existe une idée fausse selon laquelle la RAM serait très bon marché

  • Les performances des SSD et des vCPU se sont fortement améliorées, mais le prix de la RAM n’a pas beaucoup baissé
  • Le prix de la DRAM fluctue par cycles, et ce n’est que récemment qu’elle est devenue un peu moins chère

• J’ai déjà vu un projet qui utilisait les répertoires du système de fichiers comme tables et des fichiers JSON comme lignes

  • Ils avaient envisagé Redis, Mongo et Postgres, mais ont construit leur propre base de données
  • Utiliser des jetons innovants pour construire une base de données est inefficace

• Utiliser une base de données relationnelle est plus fiable

  • Elle intègre de la redondance, un journal de transactions, des sauvegardes et des fonctions de reprise
  • Dans la plupart des cas, il vaut mieux utiliser une base de données

• Ils ont implémenté leur propre couche de consensus Raft pour éviter quelque chose de complexe

  • Utiliser Redis pourrait être plus simple

• Les applications desktop et mobiles modernes utilisent souvent des bases de données comme SQLite

  • Le stockage et les requêtes de données relationnelles sont utiles

• Construire sa propre base de données en mémoire n’est pas plus simple qu’installer Postgres ou SQLite

  • Écrire du SQL est plus facile qu’écrire du code de concurrence