Vous n’avez peut-être pas besoin de Redis

• Redis fait partie des technologies qui jouissent de la réputation la plus positive dans l’industrie tech
  • C’est une technologie remarquablement bien conçue, sans défaut intrinsèque, mais elle n’est pas forcément nécessaire dans tous les cas
• Sur plus de 10 ans, dans 3 entreprises différentes, le même schéma s’est répété :
  • Un problème surgissait et Redis semblait adapté, mais en réalité cela n’améliorait pas la situation ou ne résolvait pas le problème de fond
  • Cela n’a fait qu’ajouter de la complexité pour le plaisir de la complexité

Premier cas : l’expérience chez Tantan

• Tantan est la deuxième plus grande application de rencontre en Chine et exploite 50 à 100 serveurs de base de données haute performance basés sur PostgreSQL
• Chaque serveur est shardé par ID utilisateur, de sorte que les données d’un utilisateur donné ne sont stockées que sur un seul serveur
• Le problème
  • Un besoin est apparu : stocker le nombre de « swipes » et le mettre à jour rapidement
  • Au départ, il a été jugé pertinent de le stocker dans Redis
  • L’équipe a configuré la solution en pensant que quelques serveurs Redis haute performance suffiraient
• Réévaluation et solution
  • L’équipe a discuté d’une approche consistant à stocker directement les données dans PostgreSQL plutôt que dans Redis
  • Comme la charge des serveurs PostgreSQL était déjà élevée, la charge supplémentaire attendue devait rester marginale
  • Après stockage dans PostgreSQL, aucune baisse de performance n’a été observée, et l’adoption de Redis s’est révélée inutile

Deuxième cas : l’expérience chez Bannerflow

• Contexte
  • Bannerflow est une plateforme de création et de diffusion publicitaire
  • Il a été décidé d’introduire Redis dans un nouveau microservice afin de prendre en charge la publication de publicités sur des réseaux sociaux comme Facebook
• Le problème
  • Étant donné une charge nettement plus faible que chez Tantan, il n’était pas clair que l’introduction de Redis soit nécessaire
  • Après le départ du développeur initial, plus personne ne pouvait expliquer clairement pourquoi Redis avait été adopté
• Résultat
  • Redis n’était pas vraiment nécessaire compte tenu de la faible charge
  • La conclusion a été qu’à long terme, le mieux serait de supprimer Redis

Troisième cas : l’expérience chez MAJORITY

• Contexte
  • MAJORITY est une entreprise fintech qui a introduit Redis pour mettre en cache les résultats d’appels à des API externes
  • Redis a été adopté pour mettre en cache des données de géolocalisation afin d’accélérer le traitement et de réduire les coûts
• Le problème
  • Les mêmes données étaient également stockées dans la base de données (Azure SQL)
  • Il était prévu que remplacer les appels Redis par des appels directs à la base n’augmenterait presque pas la charge
  • L’utilisation de Redis devait être maintenue pour gérer les verrous (lock), mais Azure SQL pouvait le faire suffisamment bien
• Résultat
  • La conclusion a été que l’introduction de Redis était inutile
  • Un plan a été établi pour passer d’une utilisation de Redis à Azure SQL

Conclusion

• Ces trois cas se sont produits dans des domaines, des stacks techniques et des conditions de charge différents
• Leur point commun était une adoption inutile de Redis
• Avant d’adopter Redis, il faut évaluer soigneusement le besoin réel et les gains de performance
• Recommandation de la conférence de Dan McKinley, "Choose Boring Technology"

[iolothebard]

Que vous utilisiez Redis ou non, intercaler une couche de cache entre le domaine et la persistance (avec une implémentation par défaut en bypass) n’est pas du tout de l’over-engineering. Pour le logging, les fausses données, le débogage, le profiling, et peut-être même un vrai cache…

[nodelay]

+1 Je suis d’accord aussi. Le simple fait d’ajouter une couche crée une marge de manœuvre et ouvre un espace pour résoudre une multitude de problèmes.

[galadbran]

Il ne s’agit pas tant de dire qu’il y a un problème avec Redis, mais plutôt d’adopter le point de vue suivant : si la base de données seule suffit, pourquoi introduire un composant supplémentaire et alourdir la charge de gestion ?
L’explication reste assez succincte, donc il vaut mieux le prendre comme une invitation à réfléchir aussi à cette perspective.
Cela dit, il peut aussi y avoir des situations où l’introduction d’un cache Redis est un meilleur choix pour garder une logique applicative simple,
il faudra donc choisir en fonction du contexte.

[zinisuni]

Le titre est accrocheur, hein. Haha, je suis d’accord aussi~~

[GN⁺]

Avis Hacker News

• En 2015, en travaillant chez Uber, il a été question de faire évoluer le découpage géographique basé sur les codes postaux vers une approche fondée sur des hexagones

  • Au lieu de diviser une ville en quelques dizaines de codes postaux, l’idée était de la diviser en plusieurs centaines de milliers d’hexagones et de générer dynamiquement des zones
  • Le premier lancement a eu lieu à Phoenix, et l’équipe a passé la nuit à faire monter en charge le système de tarification dynamique
  • Le lancement mondial a été retardé
  • Beaucoup d’ingénieurs appréciaient Redis
  • Le service de tarification reposait sur Redis et traitait des millions de requêtes
  • Cela coûtait cher et posait aussi des problèmes de scalabilité
  • En améliorant l’algorithme, il a été possible de calculer des zones dynamiques pour plusieurs villes sur une seule machine
  • Un ingénieur nommé Isaac l’a implémenté et déployé pendant un week-end

• Il y a eu un débat sur l’usage excessif de Redis

  • Redis est excellent, mais son utilisation implique de la latence réseau et un surcoût de sérialisation
  • Si les données sont déjà partitionnées, une simple table de hachage peut être préférable
  • En Java, on peut utiliser ConcurrentHashMap, les caches Guava ou les caches Caffeine
  • Une implémentation de cache local est presque toujours plus rapide qu’une solution passant par le réseau
  • Redis a tendance à être surutilisé

• La culture d’utilisation de Redis n’a pas évolué à la hauteur de sa popularité

  • Redis prend en charge diverses structures de données, et à mesure que la culture technique d’une entreprise progresse, elle peut apprendre davantage de patterns
  • Il est regrettable qu’il n’existe pas de recueil de patterns pour Redis

• Ce n’est pas vraiment une question de Redis contre non-Redis, mais plutôt de la difficulté à travailler avec des données qui se sérialisent mal

  • Pour des compteurs, des flux d’actualité ou des messages de chat, Redis peut être plus efficace
  • Dans la plupart des cas, MySQL suffit aussi largement

• Le développement logiciel tend souvent à répéter la manière de faire des autres

  • Cela a commencé avec Memcached avant d’évoluer vers Redis
  • Il existe une tendance à utiliser un cache pour éviter la complexité des bases de données
  • Les bases de données restent malgré tout complexes et difficiles

• Redis est le seul « serveur de structures de données » réellement prêt pour la production

  • C’est utile quand plusieurs instances doivent accéder au même service

• Il est possible que vous n’ayez pas besoin de cache

  • Certains retours d’expérience montrent qu’on peut se concentrer sur l’amélioration de l’architecture sans introduire de cache

• L’API de Redis est excellente, mais il existe des risques opérationnels

  • C’est bien comme cache, mais ce n’est pas fiable comme magasin de données de production

• Il est surprenant de voir une telle tendance à déconseiller Redis

  • Redis continue d’offrir d’excellentes structures de données et de très bonnes performances

• Redis convient comme cache temporaire, mais reste insuffisant pour les transactions ou le stockage distribué

  • Il faut se former aux problèmes des verrous distribués