OpenAI : stratégie de montée en charge massive de PostgreSQL pour soutenir 800 millions d’utilisateurs

Résumé :

• OpenAI gère des millions de QPS et 800 millions d’utilisateurs avec un unique Primary et environ 50 Read Replicas (Azure Flexible Server).
• Pour répartir la charge d’écriture, les workloads pouvant être shardés ont été migrés vers Azure Cosmos DB, et des optimisations d’écriture comme le Lazy Write ont été appliquées au niveau applicatif.
• L’adoption de PgBouncer a réduit la latence de connexion de 50 ms à 5 ms, et un mécanisme de verrouillage de cache (Cache Locking) a été mis en place pour éviter les tempêtes de cache miss.
• La stabilité a été assurée grâce à la suppression des requêtes avec jointures complexes, à un timeout strict de moins de 5 secondes pour les changements de schéma, et à l’isolation des workloads selon la priorité du trafic.

Résumé détaillé :
1. Contexte et état de l’architecture
Le trafic PostgreSQL d’OpenAI a été multiplié par plus de 10 au cours de l’année écoulée et traite désormais 800 millions d’utilisateurs ainsi que des millions de QPS (requêtes par seconde). Fait remarquable, cette échelle repose sur une architecture composée d’un unique Primary et d’environ 50 Read Replicas réparties dans le monde. Pour éviter que la conception initiale n’atteigne ses limites, OpenAI a mené de vastes optimisations à la fois au niveau de l’infrastructure et de la couche applicative.

2. Principaux goulots d’étranglement résolus et stratégies d’optimisation

• Répartition de la charge d’écriture :

  • L’architecture à writer unique de PostgreSQL limite la montée en charge, avec en plus un problème de write amplification lié au MVCC (contrôle de concurrence multi-version).
  • Comme solution, les workloads intensifs en écriture pouvant être répartis horizontalement (sharding) ont été migrés vers des systèmes comme Azure Cosmos DB.
  • Dans le PostgreSQL existant, la création de nouvelles tables a été interdite, et la charge sur le Primary a été minimisée via des corrections de bugs applicatifs et l’introduction du Lazy Write (traitement différé des écritures pour lisser les pics de trafic).

• Optimisation des requêtes et gestion de l’ORM :

  • Un cas passé de requête joignant 12 tables ayant provoqué un incident majeur (SEV), les jointures multiples complexes ont été évitées et la logique a été déplacée vers l’application.
  • Les requêtes inefficaces générées par l’ORM sont examinées en continu, et le paramètre idle_in_transaction_session_timeout est utilisé pour éviter que des requêtes inactives ne bloquent l’Autovacuum.

• Pooling de connexions (PgBouncer) :

  • Afin d’éviter la limite de connexions d’Azure PostgreSQL (5 000) et les embouteillages de connexions, PgBouncer a été déployé comme couche proxy.
  • Les modes de pooling par transaction / statement ont été utilisés pour accroître la réutilisation des connexions, réduisant le temps moyen de connexion de 50 ms à 5 ms.

• Prévention des cache miss (Cache Locking) :

  • Pour éviter le problème de thundering herd, où un grand nombre de requêtes convergent simultanément vers la base quand le cache expire, un mécanisme de cache locking (leasing) a été introduit.
  • Lorsqu’un cache miss survient sur une clé donnée, une seule requête obtient le droit d’accès à la base (lock) pour rafraîchir les données, tandis que les autres attendent, ce qui bloque la surcharge sur la base.

3. Fiabilité et politiques d’exploitation

• Réduction du point de défaillance unique (SPOF) : même en cas de panne du Primary, les requêtes de lecture continuent d’être servies via les Replicas, ce qui réduit la gravité de l’incident. Le Primary est maintenu en mode haute disponibilité (HA) avec un Hot Standby pour garantir un basculement rapide.
• Isolation des workloads : pour éviter le problème de noisy neighbor, le trafic est routé vers des instances séparées selon son niveau d’importance (Low / High Priority).
• Gestion stricte du schéma : les modifications provoquant une réécriture complète de table (Full Table Rewrite) sont interdites, et un timeout strict de 5 secondes est appliqué aux changements de schéma pour éviter toute latence de service.

4. Plans à venir (The Road Ahead)
Bien que l’architecture actuelle offre déjà une montée en charge suffisante, OpenAI teste actuellement la Cascading Replication pour augmenter encore le nombre de Read Replicas, en remplaçant le schéma où le Primary envoie le WAL à toutes les Replicas par une structure où des Replicas intermédiaires relaient le WAL vers les niveaux inférieurs. À long terme, le sharding de PostgreSQL lui-même est également envisagé.