Instacart diminue latence de 50 % et nœuds de 70 % avec Dragonfly

Présentation

Instacart a migré son cache de données de Redis vers Dragonfly, un moteur de stockage en mémoire conçu pour exploiter les serveurs à forte densité de cœurs. La migration a permis de réduire la latence moyenne des requêtes de 50 % et de diminuer le nombre de nœuds d’infrastructure de 70 %, passant d’un cluster de plusieurs machines à une seule instance capable de supporter la charge.

Architecture de Dragonfly

Dragonfly adopte une architecture thread‑per‑core et shared‑nothing. Chaque cœur possède son propre thread dédié, éliminant la contention sur les verrous classiques de Redis. Le moteur utilise une table de hachage repensée qui réduit l’empreinte mémoire d’environ 40 % par rapport à la structure dict de Redis. Sur un serveur moderne à 64 cœurs, cette approche permet d’utiliser pleinement la capacité de calcul sans gaspiller de cycles CPU inutilisés, contrairement à Redis, qui a été initialement optimisé pour les machines à cœur unique.

Performances observées

Les mesures publiées par Instacart indiquent un débit d’environ 6 M opérations par seconde sur une seule instance Dragonfly. Cette performance suffit à faire tenir la charge de travail entière sur un seul nœud, ce qui explique la réduction de 70 % du nombre de serveurs. La latence, quant à elle, a été divisée par deux, passant d’une valeur non précisée à une réponse deux fois plus rapide, ce qui améliore l’expérience utilisateur finale et réduit les coûts d’infrastructure.

Analyse des impacts et limites

Dragonfly conserve la compatibilité avec les protocoles wire de Redis et Valkey. Les clients existants peuvent donc être migrés sans modification du code ni des commandes, ce qui minimise les risques de rupture. Cependant, la dépendance à une architecture à 64 cœurs implique que les gains sont proportionnels au nombre de cœurs disponibles ; sur des serveurs moins parallélisés, les avantages seront moindres. De plus, la conception shared‑nothing ne fournit pas de réplication native, ce qui oblige les équipes à mettre en place des mécanismes de haute disponibilité externes. Enfin, le passage à un modèle monolithique sur un seul nœud augmente la criticité du serveur unique, nécessitant des stratégies de sauvegarde et de basculement robustes.