Résumé Bref
Ce résumé explique comment Chajpt, avec 800 millions d'utilisateurs, gère son infrastructure de base de données avec un seul serveur principal PostgreSQL. Les points clés incluent :
- L'optimisation des requêtes en écriture pour éviter la surcharge de la base de données.
- L'implémentation de limites de débit (rate limiting) à plusieurs niveaux pour contrôler le flux de requêtes.
- L'utilisation de répliques en lecture seule et d'une réplication en cascade pour gérer les requêtes de lecture sans surcharger la base de données principale.
Introduction
OpenAI a connu une croissance rapide, passant de zéro à 100 millions d'utilisateurs en un an, puis ajoutant 100 millions d'utilisateurs supplémentaires en une semaine lors du lancement d'Imagè. Cette croissance a nécessité une infrastructure robuste pour gérer les pics d'utilisation, atteignant jusqu'à un million de nouveaux utilisateurs par heure.
Défis de l'infrastructure
Les serveurs applicatifs peuvent être facilement mis à l'échelle horizontalement, mais la base de données relationnelle PostgreSQL pose des défis. La mise à l'échelle horizontale des bases de données relationnelles est complexe en raison des problèmes de concurrence et de corruption potentielle des données. La seule solution initiale était la mise à l'échelle verticale, c'est-à-dire l'augmentation des ressources d'un seul serveur, ce qui a des limites. Les pics d'utilisation peuvent entraîner des ralentissements, des expirations de requêtes et une surcharge de la base de données.
Solutions initiales envisagées
Le "sharding", ou partitionnement des données sur plusieurs serveurs, était une solution potentielle, mais nécessitait une refonte complète de l'application, ce qui aurait pris des mois. Au lieu de cela, ils ont choisi d'optimiser PostgreSQL en réduisant les requêtes en écriture, qui sont les principales causes de ralentissement en raison du MVCC (Multiversion Concurrency Control).
Optimisation des requêtes en écriture
L'équipe a optimisé le code pour réduire les requêtes en écriture inutiles et a implémenté des "lazy writes" (écritures paresseuses) en regroupant les requêtes en lots pour des mises à jour plus efficaces. Ils ont également simplifié les requêtes complexes en les divisant en plusieurs requêtes plus petites et plus rapides.
Limitation du débit et mise en cache
Des limites de débit (rate limiting) ont été mises en place à plusieurs niveaux (load balancer, application, pooler) pour éviter de surcharger la base de données. Un système de cache a été ajouté pour réduire le nombre de requêtes envoyées à la base de données en stockant les données fréquemment consultées en mémoire vive.
Priorisation des requêtes et bases de données alternatives
Un système de priorité a été mis en place pour assurer que les fonctionnalités essentielles continuent de fonctionner même en cas de pics de charge. Les nouvelles fonctionnalités nécessitant beaucoup d'écritures ont été déportées vers une base de données non relationnelle, Cosmo DB, pour faciliter la mise à l'échelle.
Haute disponibilité et répliques en lecture seule
Pour assurer la haute disponibilité, une deuxième machine identique a été ajoutée pour prendre le relais en cas de panne de la base de données principale. Des répliques en lecture seule ont été créées pour servir les requêtes de lecture, libérant ainsi la base de données principale des charges de lecture.
Pooler de connexion
Un pooler de connexion a été utilisé pour gérer les connexions entre les serveurs applicatifs et la base de données, réduisant ainsi la charge sur la base de données principale.
Gestion des schémas de base de données
Les modifications de schéma de base de données sont strictement contrôlées pour éviter les réécritures complètes de tables, qui peuvent paralyser la base de données. Les changements sont limités à 5 secondes et les ajouts de colonnes sont soumis à des limites de débit strictes.
Réplication en cascade
Pour gérer le grand nombre de requêtes en lecture, 50 bases de données en lecture seule ont été ajoutées. Pour éviter de surcharger la base de données principale avec la synchronisation, une réplication en cascade a été mise en place, où la base de données principale se synchronise avec quelques serveurs, qui à leur tour se synchronisent avec d'autres, créant ainsi une cascade de réplication.
