Lavik : consolider 300 nœuds Redis en 3 serveurs NVMe
Sommaire
En bref
- Lavik est un moteur de stockage qui remplace Redis en utilisant des SSD NVMe à la place de la RAM, offrant un débit comparable (1,14 million GET/s) pour une fraction du coût.
- La source compare une migration théorique : 300 nœuds Redis (4 800 GiB RAM, 27 594 $ par mois) contre 3 nœuds Lavik (272 GiB RAM + 7,68 TB NVMe, 2 101 $ par mois).
- La réduction de coûts atteint 92 %, mais repose sur une thèse : les charges mémoire-bound (état d'agent, profils utilisateur) n'ont pas besoin de latence DRAM si le moteur accède efficacement au flash.
- La source reconnaît que Redis Flex accède au flash en millisecondes, trop lent pour les budgets sub-millisecondes, contrairement à Lavik qui prétend servir depuis NVMe sans cette pénalité.
- Le projet reste jeune (date : octobre 2026) ; le débat HN est minimaliste et sceptique sur la faisabilité pratique et les cas d'usage réels.
Ce que dit la source
Lavik affirme que les applications distribuées actuelles (agent AI, systèmes multi-agent) accumulent des états massifs (des TB à des dizaines de TB) qui obligent à multiplier les nœuds Redis coûteux, chacun répliqué. L'entreprise présente cela comme un problème d'architecture : on achète de la CPU, du réseau et des OS surtout pour acquérir de la RAM, alors que la majorité des requêtes pourraient être servies depuis un stockage dense et bon marché. La consolidation 300→3 illustre l'opportunité économique : séparer la densité de stockage de la puissance de traitement, et utiliser Raft pour la tolérance aux pannes sans surcoûts de réplication.
- 1,14 million GET/s sur NVMe selon les benchmarks Lavik publiés, présenté comme supérieur au débit Redis sur DRAM.
- Hypothèse de charge : un milliard d'agents avec 1–100 KB d'état chacun génère 1–100 TB de valeurs avant clés et réplication.
- Le modèle économique repose sur deux L16as_v4 Azure (128 GiB RAM + 3,84 TB NVMe chacun) + un voter E2s_v4, soit 272 GiB RAM total pour deux copies complètes du dataset.
- Différenciation vs Redis Flex : Lavik prétend servir du NVMe sub-milliseconde, tandis que Flex accède au flash en millisecondes, incompatible avec les workloads à latence stricte.
- Topologie : deux nœuds data complets + un voter Raft sans données, évite de répliquer trois fois et réduit les surcoûts de quorum par rapport à trois nœuds data identiques.
Dans les commentaires
Débat minimaliste et sceptique : trois commentaires substantiels soulèvent des doutes sur le cas d'usage réel, les comparaisons manquantes (Dragonfly), et la faisabilité architecturale (choix entre redondance, pas de Primary).
- Plusieurs commentateurs remettent en question la pertinence du déploiement : un interroge le public réel de ce type de blog, un autre doute que quelqu'un l'ait déjà lu. Cela suggère une réaction à la nature hautement spécifique (et potentiellement niche) du cas d'usage.
- L'absence de comparaison avec Dragonfly (concurrent connu pour optimiser Redis) est explicitement signalée comme un manque. Aucune réponse fournie.
- Un commentateur remet en cause l'architecture elle-même : pourquoi forcer une topologie Primary/Follower + voter ? Pourquoi ne pas offrir des choix RAID-like ou zéro redondance ? Cela suggère que le design proposé répond à une vision spécifique du problème, pas à une palette d'options pratiques.
- Faible volume de débat (6 commentaires) et peu de détails techniques échangés ; aucun retour d'expérience terrain ou benchmark indépendant fourni.
Alternatives citées : Dragonfly (mentionné par un commentateur), Redis Flex (cité par la source elle-même comme point de comparaison), probablement Memcached ou solutions de cache distribué standard.
Notre lecture
Lavik propose une idée logique : NVMe + moteur spécialisé pour remplir le fossé entre RAM (cher, rapide) et disque (bon marché, lent). Les chiffres de coûts affichés sont séduisants, mais reposent sur trois hypothèses non validées par le débat HN : (1) le débit sub-milliseconde sur NVMe est réel et stable en production, (2) le cas d'usage (état massif d'agent, accès imprévisible) est courant et urgent, (3) aucune alternative (Dragonfly, Redis Flex, ou même Memcached + cache tiers) ne résout le problème à moindre friction. Le projet est jeune et peu scruté en dehors du marketing produit. Pour une DSI, intéressant à monitorer en cas de charges agent-heavy, mais trop tôt pour une décision de migration ; attendre des benchmarks indépendants et des retours de production réels. Envisager également une comparaison honnête avec Dragonfly avant d'investir du temps.