Comment OpenAI a fait passer sa plateforme de stockage Habitat à 70 millions de requêtes par seconde

Chaque action effectuée sur les outils d'OpenAI — qu'il s'agisse de se connecter, de modifier ses paramètres dans Codex (l'assistant de code d'OpenAI) ou de démarrer une conversation dans ChatGPT — nécessite de multiples accès aux données. Pour gérer cette charge sans ralentir les produits, OpenAI a développé Habitat, sa plateforme interne de stockage en ligne. Aujourd'hui, cette infrastructure traite plus de 70 millions de requêtes par seconde et gère 500 pétaoctets de données pour plus d'un milliard d'utilisateurs hebdomadaires répartis sur près de 40 régions géographiques.

De la simple bibliothèque Python au service centralisé

Lancé lors du DevDay 2023 pour supporter les GPT (les versions personnalisées de ChatGPT), Habitat n'était à l'origine qu'une simple bibliothèque client écrite en Python et reliée à Azure Cosmos DB (un service de base de données distribuée). Son objectif initial était de masquer la complexité aux développeurs de produits en prenant en charge le routage, la sérialisation (la conversion de données en format transmissible), le chiffrement et le connection pooling (la gestion d'un bassin de connexions réutilisables vers la base de données).

Cependant, vers le milieu de l'année 2025, cette architecture sous forme de bibliothèque client a atteint ses limites. Déployer des modifications de routage ou corriger des bugs nécessitait de coordonner les mises à jour sur des dizaines de microservices distincts, entraînant des retards de plusieurs jours et des risques d'interruption de service. OpenAI a donc fait le choix de transformer Habitat en un service autonome et centralisé, créant un point de contrôle unique pour la sécurité, l'observabilité et le routage des données.

"En acceptant les compromis de performance d'un service Python à court terme, nous avons pu donner la priorité aux défis immédiats, établir nos API principales et bâtir une infrastructure robuste."

Le pari du langage Python et l'optimisation de la latence

Conserver une infrastructure de backend écrite en Python pour un volume de trafic aussi massif représentait un défi technique majeur en raison des surcoûts en mémoire et en processeur. OpenAI a sciemment accepté cette dette technique pour privilégier la vitesse d'itération des équipes, en faisant le pari que ses propres modèles d'IA comme Codex faciliteraient une réécriture ultérieure dans un autre langage.

L'obstacle principal a résidé dans la gestion des tâches gourmandes en processeur (chiffrement, compression, vérification d'intégrité) face aux limites du GIL (Global Interpreter Lock, le verrou global d'interpréteur qui empêche Python d'exécuter plusieurs threads processeur en parallèle) et d'asyncio (la bibliothèque de gestion des tâches asynchrones en Python). Les opérations processeur bloquaient l'exécuteur d'événements, augmentant fortement la tail latency (la latence de traîne, c'est-à-dire le temps de réponse subit par le 1 % des requêtes les plus lentes, ou p99).

Pour résoudre ces engorgements, les ingénieurs d'OpenAI ont mis en place plusieurs mesures concrètes :

• Mesure en temps réel des délais d'exécution : suivi de l'écart entre le moment où une coroutine (une fonction asynchrone) est planifiée et son exécution réelle.
• Répartition des processus : limitation du nombre de requêtes simultanées traitées par un même processus worker (processus de travail), compensée par un déploiement massif de processus en parallèle.
• Correction des dépendances externes : identification d'un goulot d'étranglement lié à Statsig (un outil de gestion des feature flags ou drapeaux de fonctionnalités permettant d'activer des options à la volée), dont l'analyse systématique de fichiers JSON volumineux saturait le processeur chaque minute sur l'ensemble des pods (groupes de conteneurs de traitement).

Voici un exemple illustrant la logique de mesure du retard d'exécution de la boucle d'événements (event loop delay) sous Python asyncio pour détecter la saturation du processeur :

import asyncio
import time

async def monitor_event_loop_delay(interval_seconds=1.0):
    """Mesure le décalage de la boucle d'événements pour détecter la latence de traîne."""
    while True:
        before = time.monotonic()
        await asyncio.sleep(interval_seconds)
        delay = time.monotonic() - before - interval_seconds
        if delay > 0.05:  # Retard supérieur à 50ms
            print(f"[Alerte Latence] asyncio scheduling delay: {delay * 1000:.2f}ms")

Grâce à ces ajustements ciblés et au découpage de sa plateforme de stockage, OpenAI a pu stabiliser son infrastructure face à une croissance supérieure à 10x par an depuis trois ans, assurant la continuité de ses services à très grande échelle.