• Réunion précédente
• Pad de la réunion

Heure de début : 14h

Présences:

• Célo
• Tharyrok
• HgO

Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion. Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire

Fin: grand max 18h

Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.

Nous avons plein d'applications qui utilisent déjà Redis ou pourraient l'utiliser. Pour les applications qui l'utilisent, on a pour le moment des Redis locaux. Ketupa aurait aussi besoin de Redis.

C'est une base de donnée NoSQL, qui peux servir de cache. Mais en vrai c'est surtout une base de donnée clés-valeurs.

Ca peut-être utilisé comme base de donnée avec une clé et une valeur, dont on peux expiré la valeur en fonction d'une date, c'est aussi comme ça que fonctionne un cache. Donc Redis est aussi un serveur de cache. Redis, dans les applications qu'on utilise, est utilisé plutôt comme un serveur de cache. Redis est optimisé pour être très rapide, et limiter les accès disques car ces donnée sont exclusivement dans la ram.

On peut avoir des bases de données clés valeur SQL, mais c'est un autre sujet.

Autre usage de Redis, couramment utilisé (mais pas dans notre cas) : message queue. On peut s'abonner à des clés qui ont un certain pattern et s'envoyer une info en conséquence. Ca permet de faire de la communication assynchrone. Par exemple, la génération d'un PDF : ça prend un peu de temps et on demande à être notifié quand le PDF est généré. Dans Ketupa, on en aura l'utilité de la message queue.

Il y a aussi un usage pour stocker de la configuration. Typiquement, les features flags permettent de dire à l'application de ne pas activer la fonctionnalité tout de suite, mais de l'activer pour certaines personnes seulement.

Un exemple de serveur de cache, pour un blog avoir les titre des dernier article on peux le mettre dans redis ceci évite de faire appel à la base de donnée. Un autre exemple c'est de généré des page dynamique et mettre le resultat dans redis, tant que cette page n'as pas changé on sert ce qui est dans redis.

Dans Redis, on pourrait imaginer que l'URL est la clé et la page HTML la valeur.

Pour le cache, il existe aussi MemCached qui est aussi un serveur de cache. Mais il a moins de fonctionnalités. Il y a aussi Varnish qui est plus récent, agnostique sur le langage (il se met entre l'application et le client web). Nginx peut aussi faire un truc similaire. Bref. Il y a aussi moyen de faire des serveurs de cache custom, mais on peut vite se faire piéger…

Pour la configuration pure, il y a Etcd ou Consult, HashiCorp Vault qui sont plus récents.

Un avantage de ce genre de système de cache, c'est que si on redémarre l'application, le cache reste. Ou si on a plusieurs instance de l'application, chaque instance a le même cache.

Redis peut se mettre en cluster. Mais ça peut-être pénible et il y a de multiples façons de faire. L'idée donc est de voir comment l'implémenter.

Au jour d'haujourd'hui la licence de redis a changé et n'est plus BSD, mais c'est devenu SSPL.

Avant, il y avait une société “Redis Lab” qui n'avait pas le droit de mainteneur sur le repo Redis, car apparue après. Puis ils sont devenus mainteneneur, et du jour au lendemain, ils ont dégagé les mainteneurs initiaux et changé de licence.

Dans les forks, il y a Valkey, Redict et keydb.

Pour Keydb, ils avaient proposés une PR pour intégrer le multithread, mais cela n'a jamais été accepté par Redis… Du coup ils ont proposé la fonctionnalité dans leur propre fork.

https://wiki.neutrinet.be/fr/rapports/2022/11-12-infra#dependence_des_services

Pour Zammad, depuis la version 6.0, il faut aussi un Redis.

Il y a différentes modes possibles pour la haute disponibilité.

https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/

Il faut voir Redis Sentinel comme l'équivalent de Patroni pour le cluster PostgreSQL. Il va s'occuper d'élire un seul serveur primaire, quels sont les secondaires, et lesquels sont en mode lecture seule ou peuvent aussi faire de l'écriture.

https://docs.keydb.dev/docs/active-rep

Dans Keydb, l'active replica fonctionne à peu près comme Sentinel mais sans logiciel en plus.

On réplique sur les deux serveurs en même temps, ils sont donc tous les deux des serveurs primaires en même temps. S'il n'y a plus qu'un seul serveur actif, alors il se met on mode lecture seule.

https://docs.keydb.dev/docs/multi-master

On peut avoir plus que deux serveurs dans le cluster (mais pas obligé), cela permet d'augmenter le débit de lecture, et si jamais un des serveurs tombe, le cluster reste en mode écriture.

https://docs.keydb.dev/docs/cluster-spec

Permet de dire “ma donnée sera répliqué deux fois sur trois serveurs”, c'est le même mode de réplication que ceph ou qu'un RAID5.

Tharyrok a une bonne expérience avec un multi-master, à deux nœuds, avec un HAProxy devant. Ca permet de perdre un noeud sans devoir reconfigurer les applications. Qaund le noeud reviens de récupéré les infos manquante sur l'autre master.

En terme de configuration, c'est le plus simple. Dans HAProxy, on dit dans le backend de parler toujours avec le même serveur. Donc, si une requête arrive sur HAProxy, celui-ci va transmettre au serveur A, toujours. Si serveur A kaput, HAProxy parle avec serveur B, même si serveur A plus kaput, et ce jusqu'à ce que serveur B devient kaput.

Dragonfly a une API qui a un usage dans le kernel qui change tout! Il se base sur la shared thread. Mais Dragonfly a une licence qui inspire moyennement confiance.

https://www.dragonflydb.io/docs

Pourquoi est-ce qu'on parle de libellule ?? Parce que les libellules c'est rapide.

Il y a une comparaison des différents outils ici: https://github.com/centminmod/redis-comparison-benchmarks

En gros, si on utilise 8 threads, ça devient intéressant d'utiliser Dragonfly, mais sinon on peut très bien rester sur Keydb.

Par contre, Dragonfly est très récent (première release en 2022), et n'implémente pas encore tout de Redis.

Maintenant qu'on sait de quoi on parle, on peut décider d'utiliser un cluster Redis dans patata. Il y a déjà des playbooks qui sont prêts.

On décide de verser une goutte de notre sang pour choisir la solution Keydb, avec deux nœuds, en multi primaires, et un haproxy devant.

Prochaine réunion : 05/01 à 14:00

Lieu : Caldarium

Garde-Pad :

Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.