OpenAI réécrit le stockage Habitat : 500 Po de données et 1 milliard d'utilisateurs sur Cosmos DB

Habitat, la plateforme sur laquelle reposent ChatGPT, l'API, Codex et les services internes d'OpenAI, sert plus de 1 milliard d'utilisateurs dans 40 régions géographiques et stocke plus de 500 pétaoctets de données. Les réponses doivent arriver en quelques millisecondes. Dans la deuxième partie de leur analyse technique, Jon Lee, Hrachya Hakobyan et Chaomin Yu racontent comment l'équipe a tiré le maximum d'Azure Cosmos DB, traversé trois modèles de multitenancy et fini par revenir à un seul conteneur partagé.

Phase I : un conteneur partagé et trois problèmes systémiques

Au départ, OpenAI acceptait n'importe quelle charge cliente et s'appuyait sur la limite documentée de Cosmos DB, 10K RU/s par clé de partition logique, comme back pressure naturel. Chaque compte n'avait qu'un seul conteneur, celui par défaut. Le dispositif a fonctionné jusqu'à ce que l'échelle révèle trois problèmes.

Premier problème : à cause de choix d'API faits très tôt, le choix de la clé de partition était laissé aux clients. Des clés courantes comme user_id ou workspace_id se recoupaient entre différents cas d'usage produit, qui se partageaient alors la limite d'une même clé. Deuxième problème : les limites s'appliquent en réalité au niveau de la partition physique.

Une clé logique n'atteint donc jamais 10 000 RU/s, et les voisins d'une même partition se gênent mutuellement. Des fonctionnalités secondaires pénalisaient ainsi les flux critiques de connexion et d'inscription. Troisième problème : le débit d'un conteneur est réparti à parts égales entre les partitions physiques.

Quand les données croissent et que les partitions se divisent, le provisionnement total reste le même, mais la limite par partition baisse. Pour les cas d'usage lourds de type blob, la seule croissance du stockage réduisait le débit disponible, alors que le trafic restait stable.

Phase II : une isolation qui ne passait pas à l'échelle organisationnelle

Les conteneurs séparés réglaient une partie des problèmes. Chacun dispose de ses propres partitions physiques, et seules les charges internes à un conteneur peuvent devenir des voisins bruyants. L'équipe a alloué des conteneurs aux nouveaux cas d'usage critiques, tandis qu'un script synchronisait le provisionnement avec le nombre de partitions physiques et soignait les partitions faibles. Cela a évité les pannes à l'échelle du site : les défaillances se limitaient à une dégradation d'une fonctionnalité ou d'un service.

Mais les frais généraux augmentaient. La raison principale : dans un conteneur partagé, le passage d'un nouveau cas d'usage de 0 à 1 million de QPS ne bougeait presque pas l'agrégat. Dans un conteneur dédié à 10K RU/s, le même saut, de 1K RU/s lors du test de charge à 1M RU/s au lancement, représentait 10 000 % de la marge, alors que dans un conteneur partagé à 100M RU/s avec 80 % de charge, il en occupait environ 5 %.

Les équipes livraient leurs fonctionnalités en oubliant de monter en charge à l'avance, et le jour du lancement, les ingénieurs se retrouvaient en salle de crise SEV. La planification de capacité exigeait de chaque équipe une connaissance du produit, et la qualité de ce travail variait fortement d'une équipe à l'autre.

Phase III : retour au conteneur partagé, avec Azure

OpenAI est revenue à la multitenancy par défaut et, avec l'équipe Azure, a corrigé les défauts initiaux :

• Hot key throttling. Le throttling des clés les plus chaudes intervient en premier et empêche une seule clé d'avaler tout le débit d'une partition physique.
• Quality of Service. Les requêtes sont hiérarchisées par niveaux : les charges hors ligne, comme les insertions bulk et les exports, reçoivent une priorité basse et sont limitées en premier, tandis que le trafic interactif des utilisateurs reste intact.
• Nouveau mode serverless. L'ancien ne montait en charge qu'avec le stockage et plafonnait à 5K RU/s par partition physique. Le nouveau autorise chaque partition à monter jusqu'à 10K RU/s et ajoute des splits sur la charge en RU, en plus des splits sur le volume. La surveillance manuelle et le relèvement du provisionnement ne sont plus nécessaires.

Résultat : un seul conteneur partagé, une planification de capacité très simplifiée pour les équipes produit et une isolation des charges préservée. En plusieurs mois depuis la bascule, aucun incident de provisionnement ni de voisin bruyant n'est survenu, alors que le développement des produits s'est accéléré.

Ce qu'il faut en retenir

L'expérience d'OpenAI se lit utilement comme une checklist pour toute équipe qui construit une plateforme de données partagée.

• Ne laissez pas les clients choisir la clé de partition. Ce choix d'API, fait très tôt, a ensuite dû être compensé par toute une infrastructure.
• Surveillez la limite effective par partition physique, et non par clé logique. Elle baisse à chaque split, sans que le trafic change.
• L'isolation par conteneurs coûte cher sur le plan organisationnel : chaque équipe devient planificatrice de capacité, et la croissance agrégée stable disparaît.
• Priorisez le trafic. Les insertions bulk et les exports doivent être limités avant les requêtes des utilisateurs.
• Si l'échelle est importante, exigez des évolutions de la part du fournisseur. OpenAI a obtenu d'Azure un mode serverless spécifique, au lieu de contourner les limitations de son côté.

OpenAI estime elle-même n'en être qu'au début de son parcours en matière de multitenancy. Mais le gain est déjà net : moins de salles de crise SEV lors des lancements et moins de travail manuel pour les équipes produit.