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.).

[davidshim]

L’idée est bonne, mais pour réduire la latence des requêtes, un state devient inévitable. Par rapport à MySQL, PostgreSQL, etc., la latence des requêtes semble presque 100 fois plus élevée. Cela ressemble presque à de l’entrée-sortie sur un système de fichiers.

[stevenk]

Merci pour votre commentaire. Le point que vous avez soulevé, à savoir qu’un state est nécessaire pour réduire la latence, touche précisément le compromis central de notre architecture.

Pour commencer, en ce qui concerne la latence des requêtes, dans nos benchmarks le p99 (99e percentile) se situe autour de 130-210 ms. Je pense que la différence d’un facteur 100 que vous mentionnez vient probablement du cas le plus défavorable mentionné dans l’article, selon lequel « le cold start peut prendre quelques secondes ». Comme vous l’avez noté, ce point est clairement un inconvénient de notre architecture, et comme indiqué dans l’article, il se produit dans moins de 0,01 % des cas (P99.99) en production.

En dehors de cela, la plupart des autres requêtes sont conçues pour offrir des performances stables en exploitant la mémoire locale et le disque de chaque Lambda comme cache.

Par conséquent, comme vous l’avez souligné, cette architecture peut ne pas convenir à des systèmes comme les transactions financières à ultra-faible latence, où chaque requête doit être garantie en dessous de 10 ms. Toutefois, pour la majorité des applications de recherche et de recommandation basées sur l’IA, une latence de l’ordre de 100 à 200 ms au niveau du P99 est déjà une performance très satisfaisante, et je pense que l’avantage de réduire de plus de 90 % les coûts d’infrastructure et la charge opérationnelle est bien plus important.

Merci encore pour vos commentaires approfondis.

[davidshim]

Comme vous l'avez dit, il semble s’agir davantage d’une solution qui peut être utilisée de manière réellement serverless dans des cas précis, plutôt que d’une base de données universelle.

[davidshim]

Je ne pensais pas avoir une réponse rédigée en coréen ! (J'ai écrit ça de manière trop cynique...)

J’ai d’abord pensé que c’était une idée vraiment innovante. En fait, le principal problème des bases de données serverless est qu’un vrai serveur tourne là où il n’est pas censé être vu. Donc, quand le trafic augmente fortement, il faut attendre que ce serveur soit alloué, et il devient indisponible (environ 5 minutes). C’est pourquoi les bases de données serverless existantes dans le cloud (AWS, etc.) sont difficiles à utiliser au niveau production.

J’ai pensé : « et si j’essayais ? ». La raison qui me faisait m’inquiéter était : est-ce qu’il faudrait réimplémenter des logiques binaires d’indexation, de tri, etc., déjà présentes dans MySQL, PostgreSQL, etc. ? Et à quel point serait-il difficile de reconstruire sur Lambda un projet de base de données open source fiable ? C’est ce à quoi j’ai pensé.

Puisque c’est un produit que vous développez vous-même, j’espère que vous ferez de grands progrès ~!

[stevenk]

Merci pour votre bon commentaire. Comme vous l'avez dit, ce n’est pas adapté aux cas d’usage des bases de données relationnelles (RDB) et il serait plus approprié de le considérer comme une position d’Elasticsearch (moteur de recherche) et de vector DB (Pinecone). En interne, nous utilisons également Lucene, éprouvé pendant longtemps, pour prendre en charge des fonctionnalités telles que l’indexation, le tri et l’agrégation. Merci :)