OpenAI adapte le stockage Habitat à plus d'un milliard d'utilisateurs

Habitat à l'échelle de ChatGPT

Le post d'ingénierie du 23 octobre d'OpenAI décrit la deuxième partie de son histoire de stockage en ligne Habitat. La société dit que la plateforme sert plus d'un milliard d'utilisateurs dans 40 régions géographiques et gère plus de 500 pétaoctets de données. Ces chiffres décrivent son propre système et ne constituent pas une référence indépendante. La partie I couvrait la transition de la bibliothèque client Python au service de stockage; la partie II se concentre sur Azure Cosmos DB comme composant de stockage sous-jacent et les choix opérationnels nécessaires à grande échelle.

La leçon centrale est un renversement, pas un slogan pour la multitenance universelle. Habitat a d'abord utilisé un conteneur Cosmos DB partagé, puis fourni des conteneurs dédiés pour les charges de travail qui avaient besoin d'isolement, et finalement est revenu à la mutualisation par défaut après l'ingénierie conjointe avec Azure. Les conteneurs séparés ont réduit les interférences, mais ont rendu chaque équipe responsable de la planification des capacités. Un nouveau service pourrait passer du trafic de test à un million de requêtes par seconde, nécessitant une mise en service anticipée que les équipes oublient parfois. L'article décrit les incidents et la pression à l'échelle du jour du lancement causés par ce fardeau organisationnel.

Pourquoi revenir aux conteneurs partagés

OpenAI dit que la conception révisée réduit d'abord les clés de partition les plus chaudes de sorte qu'une charge de travail bruyante est moins susceptible de consommer le débit d'une partition physique entière. Un mode sans serveur Azure Cosmos DB amélioré prend en charge jusqu'à 10 000 unités de requête par seconde par partition physique et ajoute la division en fonction de l'utilisation des unités de requête ainsi que du stockage. Ce nombre est une limite de conception de service indiquée pour l'arrangement d'OpenAI, et non une promesse de latence de l'application. L'approche réduit le pré-escalage manuel, mais n'élimine pas le besoin de tester les clés chaudes et les limites des utilisateurs.

L'article indique que le plus grand compte Cosmos DB d'OpenAI stocke des dizaines de pétaoctets et traite plus de 20 millions de requêtes par seconde. Une panne d'électricité régionale fin 2024 a aussi révélé que le basculement des plus grands comptes vers une région secondaire prendrait plusieurs heures ; ce chiffre ne mesure pas la durée de la panne d'électricité. Même un stockage géré exige des essais conjoints à cette échelle exceptionnelle. La documentation générale du fournisseur sur le basculement ne remplace pas un exercice complet avec le volume de données et le profil de trafic réels du client.

OpenAI rapporte des améliorations des performances de lecture, y compris des lectures 12 fois plus rapides dans ses travaux de stockage, mais les lecteurs doivent localiser chaque réclamation dans le contexte de charge de travail et de mesure particuliers de l'entreprise. Cet article n'extrapole pas ces ratios à un autre déploiement. L'article original contient plus de détails sur la mise en cache, les conteneurs et le partenariat avec le fournisseur; une équipe qui planifie sa propre architecture doit mesurer sa propre distribution de lecture, sa propre pression d'écriture et son comportement d'échec avant de copier un composant.

Ce que d'autres équipes peuvent vérifier

Pour un service plus petit, le choix utile n'est ni « toujours partager » ni « toujours isoler ». Classez les utilisateurs selon le débit, distribution par clé de partition, croissance du stockage et tolérance aux pannes. Répétez un pic de lancement et une défaillance régionale, y compris le temps pour restaurer les lectures utiles. Suivre qui possède des changements de capacité et qui peut ralentir un utilisateur chaud. L'expérience d'OpenAI montre que la propriété opérationnelle peut surpasser un modèle d'isolement théorique propre.

La source est l'article du 23 octobre Habitat Part II. Cet article du 26 octobre présente son architecture et ses limites. Il ne prévoit pas d'accès à la télémétrie OpenAI, aux contrats de services Azure ou à la reproduction indépendante des chiffres de performance.