Comment OpenAI a maintenu Azure Cosmos DB sous la charge d'un milliard d'utilisateurs ChatGPT

Habitat est la plateforme interne de stockage de données d'OpenAI, par laquelle transitent les requêtes de ChatGPT, de l'API, de Codex et de dizaines de services internes. Elle doit répondre en quelques millisecondes tout en servant plus d'un milliard d'utilisateurs dans le monde, et stocke plus de 500 pétaoctets de données. Le moteur principal sous le capot est Azure Cosmos DB. Les ingénieurs d'OpenAI John Lee, Grachya Hakobyan et Chaoming Yu ont décrit comment ils ont reconstruit trois fois le principe de répartition de la charge entre les produits au sein de cette base, avant de trouver un schéma qui fonctionne.

Le problème de la base commune et des « voisins bruyants »

Au départ, tous les produits écrivaient leurs données dans une base (conteneur) Cosmos DB commune. Chaque clé — par exemple un identifiant utilisateur — est soumise à une limite de 10 000 opérations par seconde, mais en pratique, cette limite s'applique non pas à la clé elle-même, mais à la partition physique du disque où cette clé est stockée avec d'autres. Cela créait deux problèmes :

• Des produits différents utilisant des clés sémantiquement similaires (par exemple user_id) se partageaient cette limite, bien qu'ils ne devaient logiquement pas se recouper.
• Si un client augmentait brusquement la charge sur « sa » partition, tous les autres utilisateurs et fonctionnalités dont les données se trouvaient par hasard à proximité en pâtissaient — jusqu'à provoquer des pannes de connexion au système.

De plus, l'équipe a découvert le problème des « partitions faibles » : lorsqu'une partition de disque grossissait et que Cosmos DB la divisait en deux, la bande passante de chacune était divisée par deux — c'est-à-dire que la simple croissance du volume de données réduisait la vitesse, même sans augmentation du nombre de requêtes.

L'isolation via des bases séparées — et son coût

La solution a consisté à créer des bases séparées pour chaque produit ou fonctionnalité majeure. Cela a effectivement éliminé l'effet des « voisins bruyants » — la surcharge d'un service ne perturbait plus les autres. Mais cette approche avait un revers :

• Les équipes produit devaient elles-mêmes réserver à l'avance la bande passante nécessaire pour leur lancement — et oubliaient souvent de le faire, ce qui transformait les lancements en réunions d'urgence de mise à l'échelle de dernière minute.
• Une charge qui, dans une base commune, aurait été une simple goutte d'eau négligeable (passer de 1 000 à 1 million de requêtes par seconde ne représente que 5 % de la capacité totale) pouvait, dans une base séparée, représenter un dépassement de mille fois les ressources prévues.
• La planification de capacité s'est dispersée dans toute l'entreprise au lieu de rester centralisée au sein d'une seule équipe, et sa qualité variait fortement d'une équipe à l'autre.

Retour à la base commune — mais avec un équilibrage intelligent

Ayant compris qu'aucune des deux approches n'était organisationnellement évolutive, l'équipe Habitat, avec les ingénieurs de Microsoft, a retravaillé la mécanique même de Cosmos DB :

• Ajout d'une limitation prioritaire des clés les plus « chaudes », afin qu'un client agressif ne puisse pas monopoliser toute la bande passante d'une partition.
• Introduction d'une priorisation des requêtes (QoS) : les tâches en arrière-plan comme les exportations massives de données sont désormais limitées les premières, tandis que les requêtes interactives des utilisateurs le sont en dernier.
• Avec Azure, amélioration du mode serverless de Cosmos DB, qui relève la limite de 5 000 à 10 000 opérations par seconde par partition et ajoute une répartition automatique basée sur la charge, et non plus seulement sur le volume de données.

Cela a permis de revenir à une base commune unique sans planification manuelle de capacité — et, selon les auteurs, aucun incident lié à une surcharge ou à des « voisins bruyants » n'est survenu durant les mois qui ont suivi la transition.

Une ingénierie conjointe avec Microsoft

Le plus grand compte Cosmos DB d'OpenAI stocke des dizaines de pétaoctets et encaisse plus de 20 millions de requêtes par seconde — les auteurs qualifient cela du plus grand déploiement connu du service. À cette échelle, le support classique d'un fournisseur cloud cesse de fonctionner : fin 2024, une panne de courant dans une région a montré que le basculement vers une région de secours pour des comptes de cette taille prenait plusieurs heures — un scénario jamais testé à un tel volume. Un mois plus tard, lors du basculement inverse, un second incident est survenu : les clients se sont massivement reconnectés à la région d'origine, surchargeant sa passerelle, alors que seule une partie des données y était revenue.

Après ces incidents, les équipes d'OpenAI et d'Azure ont mis en place une collaboration directe : tableaux de bord partagés, tests conjoints sur une copie du compte de production, canaux de communication directs sur Teams, et possibilité de se « pager » directement l'une l'autre en contournant le support technique standard. Au cours de la dernière année, elles ont conjointement amélioré l'évolutivité de la passerelle Cosmos DB, ajouté une mise en cache des métadonnées, réduit le nombre de connexions des services Python d'Habitat, et séparé les charges critiques des charges d'arrière-plan sur des réseaux distincts.

La principale leçon pour les équipes d'ingénierie : les systèmes multi-locataires (partagés) sont moins coûteux et plus simples à exploiter, mais nécessitent des mécanismes d'isolation intégrés fournis par le fournisseur lui-même — sans eux, la seule alternative est une séparation manuelle en bases distinctes, qui ne fait que transférer le problème de planification de capacité vers des dizaines d'équipes.