- OpenAI a massivement étendu son infrastructure PostgreSQL pour faire face à la forte hausse du trafic de ChatGPT et de l’API, en traitant plusieurs millions de QPS avec un serveur flexible Azure PostgreSQL unique et environ 50 réplicas de lecture
- Tout en conservant une architecture optimisée pour les workloads centrés sur la lecture, une partie des workloads a été migrée vers Azure Cosmos DB afin de réduire la charge d’écriture
- Diverses optimisations, comme le pooling de connexions avec PgBouncer, le verrouillage de cache, le rate limiting et l’isolation des workloads, ont permis d’améliorer la stabilité et la latence
- Pour dépasser les limites d’une architecture à primaire unique, des tests ont été menés en parallèle sur une configuration de haute disponibilité (HA), le hot standby et la réplication en cascade (cascading replication)
- Cette approche a permis d’atteindre une disponibilité de 99,999 % et une latence p99 de l’ordre de quelques dizaines de millisecondes, tout en ouvrant la voie à une future extension vers un PostgreSQL shardé ou des systèmes distribués
Vue d’ensemble de l’extension de PostgreSQL
- PostgreSQL est le système de données central de ChatGPT et de l’API OpenAI, avec une charge multipliée par plus de 10 au cours de l’année écoulée
- Une instance primaire unique et environ 50 réplicas de lecture répartis dans le monde traitent les requêtes de 800 millions d’utilisateurs
- Tout en conservant une architecture centrée sur la lecture, une partie des workloads a été déplacée vers Azure Cosmos DB pour alléger la charge d’écriture
- L’ajout de nouvelles tables est interdit, et les nouveaux workloads sont par défaut placés sur un système shardé
Défis de l’architecture à primaire unique et réponses apportées
- Une architecture à rédacteur unique pose des limites de scalabilité en écriture et un problème de point unique de défaillance (SPOF)
- Le trafic de lecture est réparti sur les réplicas, tandis que le trafic d’écriture pour les workloads shardables est déplacé vers Cosmos DB
- Une configuration de haute disponibilité via hot standby permet une promotion rapide en cas de panne (failover)
- Lors de pics soudains de charge en lecture, des ratés de cache ont provoqué une saturation CPU
- Un mécanisme de verrouillage du cache a été introduit pour éviter les requêtes dupliquées sur une même clé
Optimisation des requêtes et des ressources
- Des requêtes complexes à multiples jointures monopolisaient excessivement le CPU et provoquaient de la latence
- Les SQL inefficaces générées par l’ORM ont été revues, et les logiques de jointure complexes ont été déplacées vers la couche applicative
- Le paramètre idle_in_transaction_session_timeout a été utilisé pour éviter les requêtes inactives de longue durée
- Pour résoudre le problème du "noisy neighbor", le trafic a été séparé sur des instances selon le niveau de priorité
- Cette isolation empêche les requêtes de faible priorité d’affecter les services à haute priorité
Gestion des connexions et contrôle de charge
- Pour contourner la limite de 5 000 connexions d’Azure PostgreSQL, PgBouncer a été introduit comme couche proxy
- La réutilisation des connexions a réduit le temps moyen de connexion de 50 ms à 5 ms
- Afin de réduire la latence réseau interrégionale, le proxy, les clients et les réplicas ont été placés dans la même région
- Le rate limiting a été appliqué aux niveaux application, proxy et requête afin d’éviter les brusques explosions de trafic
- La couche ORM a également été améliorée pour pouvoir bloquer certains digest de requêtes spécifiques
Gestion de la réplication et des changements de schéma
- Comme le primaire doit streamer les logs WAL à tous les réplicas, l’augmentation de leur nombre accroît la charge réseau
- La réplication en cascade (cascading replication) est actuellement testée en collaboration avec l’équipe Azure
- Des réplicas intermédiaires transmettent le WAL à des réplicas en aval, ouvrant la possibilité de dépasser 100 réplicas
- Les changements de schéma qui provoquent une réécriture complète de table (full table rewrite) sont interdits
- Seuls des changements légers sont autorisés dans une fenêtre de timeout de 5 secondes, et la création ou suppression d’index peut être effectuée de manière concurrente
- Même lors des backfills, des limites de débit strictes sont appliquées
Résultats et feuille de route
- PostgreSQL traite plusieurs millions de QPS, avec une latence de quelques dizaines de millisecondes (p99) et une disponibilité de 99,999 %
- Au cours des 12 derniers mois, un seul incident SEV-0 a été enregistré (lors du lancement de ChatGPT ImageGen)
- Les workloads restants centrés sur l’écriture sont eux aussi migrés progressivement vers Cosmos DB
- Une fois la réplication en cascade finalisée, l’objectif est de renforcer encore la scalabilité et la stabilité des réplicas
- À plus long terme, l’adoption d’un PostgreSQL shardé ou d’un autre système distribué est à l’étude
Aucun commentaire pour le moment.