Update hydra
parent
2f8eb699f2
commit
ef1263d311
@ -1,6 +1,8 @@
|
||||
# Étude liée au problèmes de BDD Hydra
|
||||
|
||||
## Problématiques :
|
||||
|
||||
1. La taille de la BDD
|
||||
### 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 :
|
||||
|
||||
@ -18,12 +20,12 @@ Pour résoudre le problème, plusieurs actions ont été réalisées lors du pas
|
||||
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
|
||||
### 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,
|
||||
- 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.
|
||||
@ -33,7 +35,7 @@ Décaler le logging ailleurs nous permettrait de vider la BDD sans se préoccupe
|
||||
|
||||
## Les solutions
|
||||
|
||||
1. Ory Enterprise License (OEL)
|
||||
### 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.
|
||||
|
||||
@ -52,13 +54,13 @@ Mettre en place cette solution a un coût :
|
||||
- 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
|
||||
### 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é
|
||||
### 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
|
||||
@ -74,46 +76,3 @@ Comme hydra janitor arrive à être exécuté toutes les heures sans ralentissem
|
||||
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.
|
||||
|
Loading…
x
Reference in New Issue
Block a user