Les bases de données « serverless » actuelles ne sont pas vraiment serverless

Le mythe du serverless

• Le serverless est devenu une tendance majeure des technologies cloud.
• Ce paradigme permet aux développeurs de se concentrer uniquement sur la logique métier, sans charge de gestion des serveurs.
• Modèle de facturation : vous ne payez que ce que vous utilisez, et les coûts opérationnels sont en pratique quasi nuls.
• Plusieurs bases de données serverless ont vu le jour, avec les leaders historiques Elastic, Confluent et Pinecone face à de nouveaux entrants comme Neon, WarpStream, Upstash et Turbopuffer.

Problèmes des bases de données serverless existantes

• De nombreuses bases de données serverless ne sont pas de vraies solutions serverless.
• La plupart des services reposent sur une architecture cloud-native, une approche innovante de l’ère des pools de serveurs.
• Elles exploitent des clusters de serveurs et s’appuient sur des logiciels complexes ainsi que sur l’intervention humaine pour prévoir la charge et gérer la capacité.
• Cette illusion cause des problèmes concrets aux utilisateurs.

Impact d’une architecture inefficace

• Le décalage d’architecture n’est pas un simple détail technique : il provoque des problèmes réels pour les utilisateurs.
• Les utilisateurs paient pour des serveurs inactifs, tandis que les clusters de serveurs tournent en permanence pour différents usages.
• Scalabilité : il faut plusieurs minutes pour ajouter un nouveau serveur à un cluster, ce qui empêche de gérer instantanément une hausse soudaine du trafic.
• Options limitées : la nécessité de gérer l’infrastructure de chaque région cloud restreint les zones de service disponibles.

Un modèle difficilement durable

• Les bases de données dites « serverless » basées sur une architecture de server pool ne sont pas durables.
• Les fournisseurs doivent investir massivement dans l’exploitation de clusters de serveurs, ce qui peut entraîner des changements de prix.
• Les utilisateurs légers paient des coûts excessifs pour soutenir le système, et les utilisateurs en croissance sont confrontés à des hausse tarifaire inattendue.

Besoin d’une architecture serverless native

• Au début du cloud computing, la plupart des bases de données « cloud » étaient des bases de données héritées.
• Une architecture serverless native délègue toute la gestion de l’infrastructure au fournisseur cloud, et utilise des fonctions sans état ainsi que des services serverless à la place des clusters de serveurs.
• Cette approche considère l’infrastructure cloud comme un unique supercalculateur, ce qui permet une scalabilité instantanée et un véritable modèle de paiement à la requête.
• Test de litmus : pour vérifier qu’une base de données est vraiment serverless native, elle doit pouvoir être déployée sur un compte cloud sans provisionner de cluster Kubernetes ni de VM.

Présentation de LambdaDB

• LambdaDB est un nouveau moteur de recherche conçu en mode serverless native.
• Le système est exploité comme un ensemble de fonctions et de ressources serverless, en séparant totalement la logique de base de données de l’infrastructure.
• Les requêtes utilisateurs passent par une passerelle régionale, puis sont routées vers la Control Function (fonction de contrôle) ou la Data Function (fonction de données) selon le type de requête.
• Fonctionnalités entreprise : LambdaDB propose des fonctions comme la restauration ponctuelle et le clonage sans copie, sans nécessiter de gestion d’infrastructure.

Fonctionnement de LambdaDB

• Architecture LambdaDB : tous les composants sont construits avec des services cloud serverless.
• La passerelle valide la clé API des requêtes utilisateurs, puis oriente chaque requête vers la control function ou la data function.
• Les control functions traitent les opérations CRUD et les requêtes de gestion des données, tandis que les data functions effectuent les écritures et lectures réelles de données.
• Chemin d’écriture : la Writer Function enregistre la requête, l’écrit dans un tampon d’écriture serverless durable, puis répond au client.

Le paradoxe de l’efficacité des coûts

• LambdaDB réduit les coûts de calcul par rapport aux bases de données en server pool.
• Bien que le coût unitaire de Lambda soit supérieur à celui d’une instance EC2, les économies sont réalisables grâce à la redondance nécessaire pour garantir la haute disponibilité et la résilience aux pannes.
• Gaspillage de capacité fixe : avec une utilisation moyenne de calcul en entreprise limitée à 10–20 %, le serverless peut réduire les coûts de 50 à 90 %.

Performances et scalabilité

• Performances et scalabilité : LambdaDB a démontré sa capacité de traitement dans un test d’ingestion de millions de vecteurs en 960 dimensions.
• Latence d’écriture : avec 10 upserts par seconde, la latence médiane est de 43 ms, et elle reste similaire même quand le trafic est multiplié par 100.
• Latence de requête : la latence des requêtes reste stable sous diverses charges, avec un p99 compris entre 172 ms et 210 ms.
• Optimisation continue : le temps de latence des fonctions de requête est continuellement optimisé, tout comme l’infrastructure serverless.

Bénéfices pour les utilisateurs

• Réduction des coûts : LambdaDB coûte plus de 10 fois moins cher puisqu’il n’existe pas de serveurs inactifs.
• Scalabilité immédiate et illimitée : LambdaDB peut s’étendre en quelques millisecondes vers des milliers de fonctions parallèles.
• Démarrage et montée en charge simplifiés : il est possible de construire des applications IA puissantes, avec une architecture toujours simple et rentable à mesure de la croissance.
• Fonctionnalités entreprise : restauration ponctuelle et clonage sans copie sont disponibles sans complexité ni coûts additionnels.

Plan futur et vision

• LambdaDB traite déjà des centaines de millions de documents et des millions de requêtes chaque jour.
• Plan à long terme : l’entreprise prévoit de prendre en charge d’autres modèles de données (relationnelles, stream, key-value, graph, etc.).