OpenAI desarrolla Pando para escalar el backend de Git para el desarrollo a gran escala

OpenAI ha desarrollado Pando, un nuevo backend para repositorios de Git diseñado para gestionar la creciente escala y las demandas del monorepo de la empresa. Según OpenAI, el sistema fue construido para soportar el nivel de trabajo concurrente habilitado por Codex sin interrumpir los flujos de trabajo de ingeniería existentes ni cambiar la forma en que el equipo utiliza Git.

Escalabilidad y Rendimiento

OpenAI afirma que Pando fue diseñado para lograr dos objetivos principales: proporcionar escrituras escalables horizontalmente optimizadas para empujes concurrentes a muchas ramas, y maximizar el rendimiento de lectura para permitir que los clientes descarguen datos a velocidades que saturan el ancho de banda de red disponible.

En producción, OpenAI reporta que Pando ha logrado lo siguiente:

• Redujo la latencia de empuje mediana casi 5 veces.
• Entrega casi un petabyte de datos de Git por día.

Arquitectura Técnica

Para lograr estos objetivos, Pando utiliza un modelo de consistencia relajado conocido como consistencia causal. Este enfoque permite que las actualizaciones a ramas no relacionadas procedan en paralelo coordinando las actualizaciones de cada rama de forma independiente. Según OpenAI, esto significa que un lector que mira varias ramas puede verlas en diferentes puntos en el tiempo.

A diferencia de los patrones tradicionales de servicios de Git, Pando emplea los siguientes métodos:

• Optimización de escritura: Pando valida los archivos de paquete entrantes mientras los transmite al almacenamiento de blobs sin desempaquetarlos en un repositorio local. Utiliza una transacción de múltiples claves para registrar las versiones de ref en un almacén de metadatos, lo que OpenAI dice requiere lecturas y escrituras de metadatos de $O(1)$.
• Optimización de lectura: Pando reutiliza archivos de paquete entre las operaciones de recuperación en lugar de generar archivos de paquete individuales para cada cliente. Esto permite que el servidor sirva los mismos bytes a muchos clientes con un mínimo de computación.

Comparación con Métodos Existentes

OpenAI evaluó dos enfoques convencionales para escalar Git: tres fases de compromiso (3PC) y diseños basados en registro de escritura anticipada (WAL).

Según las simulaciones y pruebas de OpenAI:

• Tres fases de compromiso (3PC): Este método requiere múltiples rondas de comunicación entre un coordinador y réplicas, lo que OpenAI dice conduce a una latencia de escritura significativamente mayor bajo carga a medida que los discos se saturan.
• Registro de escritura anticipada (WAL): Este método utiliza un manifiesto compartido en el almacenamiento de blobs para ordenar las actualizaciones. OpenAI reporta que estos sistemas muestran una latencia de lectura significativamente mayor porque los servidores luchan por mantenerse al día leyendo del diario.

OpenAI afirma que Pando soporta miles de clientes empujando simultáneamente sin impactar el rendimiento bajo carga.

Fuentes (en inglés)

• openai.com: Scaling Git at OpenAI | OpenAI

Traducción con IA del artículo original en inglés, revisada automáticamente para que diga lo mismo que el original. Las fuentes fueron verificadas en inglés.