OpenAI retrace l’itinéraire de sa plateforme de stockage Habitat, passée par l’isolation en conteneurs dédiés avant de revenir à un modèle mutualisé sur Azure Cosmos DB. À la clef, de meilleures performances de lecture à l’échelle mondiale, mais aussi des arbitrages serrés entre fiabilité, capacité et effets de voisinage, pour plus d’un milliard d’utilisateurs et plus de 500 pétaoctets de données.
Incidents en hausse et pannes majeures évitées grâce au cloisonnement
Avec la croissance, la pression sur le conteneur par défaut et les incidents de production ont augmenté. OpenAI a alors provisionné des conteneurs pour chaque nouveau service ou grande fonctionnalité afin d’épargner le conteneur partagé d’une charge additionnelle. Cette stratégie a permis d’éviter de nombreuses pannes à l’échelle du site, en limitant l’impact à des dégradations de fonctionnalités ou de services. Le coût de création et de gestion de nouveaux conteneurs a toutefois fini par s’accumuler.
L’isolation coûte en capacité ce que le multi‑tenant absorbe
Dans l’ancien conteneur partagé, un cas d’usage passant de 0 QPS à 1 million QPS modifiait peu l’usage agrégé. En conteneur isolé, le même passage pouvait atteindre 1,000 fois la charge de la référence interne. Les équipes devaient alors pré‑provisionner le débit attendu avant les lancements, avec des oubliés qui se traduisaient par des cellules SEV le jour J pour monter en charge à la dernière minute. L’avantage de mélange de charges inhérent aux systèmes multi‑locataires disparaît avec cette isolation accrue.
Retour à un multi‑tenant co‑géré pour de meilleures lectures globales
OpenAI détaille l’évolution du composant de stockage sous‑jacent basé sur Azure Cosmos DB et une collaboration serrée avec l’équipe Azure. L’issue est un modèle multi‑tenant avec des conteneurs co‑gérés, donnant d’excellentes performances de lecture à grande échelle mondiale. Habitat est aujourd’hui une couche base de données mutualisée pour de nombreux produits, après un parcours allant du multi‑tenant au mono‑tenant de secours puis de nouveau au multi‑tenant par défaut. OpenAI indique en être encore au début de ce cycle et s’appuyer sur les primitives intégrées de Cosmos DB pour différer certains investissements.
Vous suivez la course aux modèles IA ?
Chaque sortie (GPT, Claude, Gemini, Mistral…) décryptée le soir même, en 5 min. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisissez votre rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
Pourquoi l’isolation n’a pas tout réglé
Séparer des conteneurs a partiellement résolu les limites liées aux clés logiques et aux voisins bruyants, chaque conteneur disposant de partitions physiques propres. Mais chaque conteneur exige une planification de capacité dédiée. OpenAI a réservé cette approche aux cas d’usage critiques, appuyée par un script alignant le débit total provisionné sur le nombre de partitions physiques, ce qui a surtout évité les problèmes. Des contraintes historiques ont toutefois laissé des cas critiques dans le conteneur partagé, d’où la recommandation de créer des conteneurs séparés pour les nouveaux services majeurs dépendant encore des données communes.
Les limites concrètes rencontrées avec Cosmos DB au départ
Au départ, OpenAI s’appuyait sur la limite de 10K RU/s par clé de partition logique, avec un conteneur par défaut unique par compte. L’exposition de la clé de partition aux clients a généré des collisions sur des clés communes, contraignant le débit pour un même utilisateur. Dans la pratique, les plafonds s’appliquent aux partitions physiques : des clés co‑localisées partagent les ressources et peinent à atteindre 10,000 RU/s, au risque de voir des workloads de niche perturber des flux essentiels comme la connexion et l’inscription. La répartition du débit provisionné entre partitions, qui se multiplient quand les données grossissent, diminue le plafond effectif par partition et peut réduire la capacité de traitement de charges actives même à taux de requêtes constants.
L’échelle visée et la feuille de route d’ingénierie
Tous les produits d’OpenAI utilisent Habitat pour accéder aux données en millisecondes et servir plus d’un milliard d’utilisateurs répartis sur 40 régions. L’objectif cumulait croissance des cas d’usage, fiabilité accrue, performances et vitesse de développement, ce qui a imposé de repenser la conception et l’exploitation du stockage en ligne. La trajectoire a suivi trois paliers : fiabilité pour le trafic critique, rapidité pour un public mondial, puis exploitation à l’échelle. Habitat est une plateforme de stockage distribuée mondialement gérant plus de 500 pétaoctets. La première étape du projet a fait passer Habitat d’une bibliothèque Python à un service, avec des techniques poussant le cadre Python. Côté Cosmos DB, un compte définit conteneurs et réplication, chaque conteneur est provisionné en RU/s, les données sont shardées par clé logique avec des limites par clé, et le service gère la division en partitions physiques selon le stockage et le débit provisionné.
