Étude liée au problèmes de BDD Hydra

Problématiques :

1. La taille de la BDD

La BDD grossit très vite (~8Go par semaine, très fluctuant d'une semaine à l'autre) et ne se vide pas (ou presque). Cela pose 2 problèmes :

l'espace dique n'est pas infini et un disque plein résultera en un arrêt brutal de la partie authentification de la plate-forme ;
les performances de la base de données sont liées à la quantité de données stockées.

Sur MSE2, à partir d'une certaine taille, les requêtes en BDD devenaient trop lentes et les utilisateurs ne pouvaient plus de connecter sur la plate-forme.

Pour résoudre le problème, plusieurs actions ont été réalisées lors du passage à MSE3 :

passage de mysql à postgresql ;
migration vers Hydra 2 ;
séparation de la BDD Hydra et de la BDD mse sur 2 clusters BDD différents.

Aujourd'hui, un script de nettoyage fourni avec Hydra (hydra janitor) vient nettoyer la BDD toutes les heures, sans interruption de service. Sur MSE2, ce script n'était exécuté qu'une fois par jour, provoquant des ralentissements de la plate-forme la nuit et sans qu'hydra janitor n'ait le temps de supprimer toutes les données souhaitées. Il y a donc déjà de très claires améliorations. Cependant, ce script de nettoyage ne suffit pas à supprimer les données obsolètes qui encombrent la BDD.

2. Rétention d'information

Il y a une obligation légale de tracer avec horodatage sur une plage horaire, vers quelle URL (redirection) un utilisateur :

se connecte,
tente de se connecter,
se déconnecte.

Sur MSE2, ces informations étaient extraites d'Hydra tous les jours et envoyées vers le NAS de NUO avant destruction des données dans la BDD pour alléger la BDD. Une partie de ces informations peut être retrouvée autrement, en loggant les accès à certains endpoints par exemple. Décaler le logging ailleurs nous permettrait de vider la BDD sans se préoccuper de cette problématique.

-> Il faut faire un point avec NUO sur ce qu'ils veulent logger et comment le faire

Les solutions

1. Ory Enterprise License (OEL)

Après avoir exposé notre problème sur le slack d'Hydra, un développeur nous conseille de partir sur Ory Enterprise License.

we provide the Ory Enterprise License (OEL) for commercial users of Ory Hydra - this would solve your problems with database issues https://www.ory.sh/docs/self-hosted/oel/quickstart

This is a perfect use case for OEL - we have many heavy users of Ory Hydra who migrated to the OEL for similar reasons as yours. For example one heavy user of OEL is the biggest AI company on the planet with around 4000 logins per second. We are looking to scale this to more than 6000 logins per second in the coming months. It is not something we can help you with as part of community support - it is only intended for hobby or small personal projects.Please contact the Ory team at https://ory.sh/contact or book a meeting directly at https://meetings-eu1.hubspot.com/jonathan-clark to talk about the details.

You probably want to use cockroachdb to solve the hydra janitor issues. There are also things we can do when you continue to use mysql but we work closely with crdb and scalability etc. is optimized for that db.

Mettre en place cette solution a un coût :

Il faudrait payer 2 licenses, une pour OEL et une pour CockRoachDB Enterprise (la version communautaire n'est pas supportée par OEL).
Il faudrait intégrer dans kubernetes CockRoachDB et OEL
Il faudrait migrer les données existantes (en particulier les clients et secrets des partenaires)
La question de la rétention d'information ne semble pas répondue. En particulier, cette solution promet de nettoyer les données obsolètes de manière automatique, mais il ne semble pas y avoir de logging d'informations.

2. Refresh-token

L'une des plus grosses sources de données dans la BDD est la génération de jetons d'authentification (token). L'utilisation de resfresh-token permettrait de réutiliser les jetons d'authentification. En théorie donc, les refresh-token peuvent permettre de diminuer l'utilisation de la BDD. Cependant, il est certain que cela ne suffira pas à cause du nombre d'utilisateur différent. Cette solution est donc mise de côté pour le moment.

3. Nettoyage automatisé

Comme sur MSE2, un nettoyage scripté peut être mis en place. Cette solution n'est pas approuvée par Ory (l'éditeur d'Hydra) ce qui est logique vu qu'ils ont un produit à vendre. D'autres usagers l'ont fait : https://github.com/ory/hydra/issues/2514#issuecomment-1050754956 Sur MSE2, le nettoyage avait lieu la nuit comme l'utilisation d'hydra janitor et les problèmes étaient assez similaires :

ralentissements de la plate-forme ;
incapacité à supprimer toutes les données à temps lors de jours avec une forte affluence.

Comme hydra janitor arrive à être exécuté toutes les heures sans ralentissement, nous avons bon espoir de pouvoir faire de même avec un script de nettoyage toutes les heures. Plusieurs possibilités concernant ce script :

version douce où on sélectionne les entrées à supprimer selon si elles ne sont plus actives et assez agées
version brutale où on supprime les données antérieures à une date (comme sur MSE2)

Plusieurs test sont en cours de préparation pour valider cette solution :

Avec une grosse base Hydra (alimentée via un test de charge), faire tourner le script de nettoyage tout en exécutant un test de charge pour vérifier que les utilisateurs peuvent toujours se connecter
Se connecter sur un autre client, faire tourner le script de nettoyage puis se connecter sur le MSE. Normalement, le MSE ne devrait pas demander de nouveau les identifiants