OpenAI développe Pando pour mettre à l'échelle le backend Git pour le développement à grande échelle

OpenAI a développé Pando, un nouveau backend pour les dépôts Git conçu pour gérer l'échelle croissante et les exigences du monorepo de l'entreprise. Selon OpenAI, le système a été construit pour supporter le niveau de travail concurrent permis par Codex sans interrompre les flux de travail d'ingénierie existants ou modifier la manière dont l'équipe utilise Git.

Scalabilité et Performance

OpenAI indique que Pando a été conçu pour atteindre deux objectifs principaux : fournir des écritures horizontalement scalables optimisées pour les pushes concurrents à de nombreuses branches, et maximiser le débit de lecture pour permettre aux clients de télécharger des données à des vitesses saturant la bande passante réseau disponible.

En production, OpenAI rapporte que Pando a atteint les résultats suivants :

• Réduction de la latence médiane des pushes de près de 5x.
• Livraison de près d'un pétaoctet de données Git par jour.

Architecture technique

Pour atteindre ces objectifs, Pando utilise un modèle de cohérence assoupli connu sous le nom de cohérence causale. Cette approche permet aux mises à jour de branches non liées de se dérouler en parallèle en coordonnant les mises à jour de chaque branche indépendamment. Selon OpenAI, cela signifie qu'un lecteur examinant plusieurs branches peut les voir à des points différents dans le temps.

Contrairement aux modèles de services Git traditionnels, Pando emploie les méthodes suivantes :

• Optimisation des écritures : Pando valide les packfiles entrants tout en les streamant vers le stockage blob sans les décompresser dans un dépôt local. Il utilise une transaction multi-clés pour enregistrer les versions de ref dans un magasin de métadonnées, ce qu'OpenAI dit nécessiter des lectures et écritures de métadonnées en $O(1)$.
• Optimisation des lectures : Pando réutilise les packfiles entre les fetchs plutôt que de générer des packfiles individuels pour chaque client. Cela permet au serveur de servir les mêmes octets à de nombreux clients avec un calcul minimal.

Comparaison avec les méthodes existantes

OpenAI a évalué deux approches conventionnelles pour mettre à l'échelle Git : trois-phase commit (3PC) et les conceptions basées sur le journal d'écriture (WAL).

Selon les simulations et tests d'OpenAI :

• Three-phase commit (3PC) : Cette méthode nécessite plusieurs tours de communication entre un coordinateur et des réplicas, ce qu'OpenAI dit entraîner une latence d'écriture significativement plus élevée sous charge lorsque les disques sont saturés.
• Write-ahead log (WAL) : Cette méthode utilise un manifeste partagé dans le stockage blob pour ordonner les mises à jour. OpenAI rapporte que ces systèmes montrent une latence de lecture significativement plus élevée car les peines à suivre la lecture du journal.

OpenAI indique que Pando supporte des milliers de clients pushant en même temps sans impacter les performances sous charge.

Sources (en anglais)

• openai.com: Scaling Git at OpenAI | OpenAI

Traduction réalisée par IA de l’article original en anglais, vérifiée automatiquement pour dire la même chose que l’original. Les sources ont été vérifiées en anglais.