hydra

étude_hydra2

@@ -0,0 +1,119 @@
+## 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 logger 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 grosse source 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 coté pour le moment.
+
+3. Nettoyage automatisé
+
+Comme sur MSE2, un nettoyage scripté peut être mis en place. Cette solution n'est pas approuvé par Ory (l'éditeur d'hydra) ce qui est logique vu qu'ils on un produit à vendre.
+D'autres usagers sur le web 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 similaire :
+- 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.
+2 possibilités concernant ce script :
+- version douce où on séléctionne les entrées à supprimer selon si elles ne sont plus actives et assez agées
+- version brutale où on supprime les données antérieur à une date (comme sur MSE2)
+
+Plusieurs test sont en cours de préparation pour valider cette solution :
+1. 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
+2. 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
+
+
+
+
+
+
+
+
+Message Slack
+
+Hello,
+
+I manage a platform which serve as a portal to many partners. One goal of this platform is to provide an authentication source to these partners. So, we chose to use hydra for the OIDC server.
+We have multiple OIDC clients, and 2 login apps (technically, 3 login apps, but one of them is just there to allow a user to chose between 2 identity sources).
+Last year, our infrastructure was:
+- 1 Mysql database server (physical)
+- 4 instances of hydra 1.11.7 (VMs)
+- multiple instance of OIDC clients and login Apps
+
+Today, we have migrated to Kubernetes and to PostgreSQL. Our infrascture looks like:
+- 1 Postgres v17.0 database cluster (handled with cnpg)
+- multiple instance of hydra v2.1.2 (pods)
+- multiple instance of OIDC clients (external and pods) and login Apps (pods)
+
+About metrics, we handle about 5 millions accounts.
+About 500.000 of them try to connect to our platform over a period of 1 week in July.
+
+What struggle made me join the community chat is the database size which grows too quickly.
+
+Last year was catastrophic. Hydra queries to the database were too slow. The fault was probably on mysql side, because of the size of the database: over 90GB. Hydra Janitor was not able to clean data without locking the database for too long.
+We truncated almost all tables and then we could authenticate more than 100.000 accounts a day (from 8am to 10pm).
+So, to keep our platform running we had to truncate almost all tables every 3 days (backing up dumps for legal retention of information)
+
+Today, we run janitor every hour (`hydra janitor --read-from-env --grants --requests --tokens`), but it's not enough. Our database grows about 15GB every week. We generate about 70.000 oauth2 code per day.
+So, we have 3 issues:
+1. The disk space is not infinite, we can't keep growing 15GB per week (when there's "little" traffic)
+2. We fear that after a certain size, queries will become slow, hydra janitor will not be able to keep up, etc.
+3. We must still keep legal information: what and when an account logged in/logged out/tried to log in, with what redirection URL.
+
+-> We are looking for help in order to keep the database size quite small (< 50GB) without downtime and without losing important data.
+Do you have any link that could help us? For now, the most relevant information I could get is a comment on issue: https://github.com/ory/hydra/issues/2514#issuecomment-1050754956 but we are not sure that we can safely remove data without creating a problem in hydra, without locking the database (and thus, preventing people from connecting).
+
+Btw, I'm french, sorry for the english mistakes.