El problema fundamental que aborda GitHub es la escalabilidad de su infraestructura Git bajo una carga de tráfico exponencial, impulsada por el "cambio agéntico" (tráfico de agentes automatizados). La arquitectura existente, basada en quorums de escritura a nivel de repositorio, se convierte en un cuello de botella insostenible cuando se introduce latencia de red significativa (ej. 25ms RTT entre data centers on-premise y Azure). Esto se debe a que cada escritura, que requiere un bloqueo a nivel de repositorio, espera la respuesta de la réplica más lenta, limitando drásticamente el throughput.
La tesis central es que la consistencia de Git, aunque crítica, no requiere serialización a nivel de repositorio para todas las operaciones. Al reconocer que las actualizaciones a diferentes referencias (ramas, tags) son en su mayoría independientes, se puede relajar el alcance de la serialización, permitiendo concurrencia y un mayor throughput de escritura. Simultáneamente, la separación del almacenamiento y el cómputo permite escalar las lecturas de forma elástica, un requisito clave para cargas de trabajo con alta proporción de lectura/escritura.
Arquitectura del Sistema
La arquitectura original de GitHub para Git se basa en un sistema de quorums llamado Spokes, que mantiene cinco réplicas por repositorio para durabilidad, disponibilidad y escala. Spokes utiliza enrutamiento preferencial para dirigir el tráfico a réplicas en la misma región/zona de disponibilidad para minimizar la latencia de lectura. Las escrituras requieren que una mayoría de réplicas persistan el cambio, pero el sistema espera la respuesta de todas las réplicas saludables (hasta un timeout) antes de confirmar, lo que significa que la réplica más lenta dicta la latencia de escritura y, por ende, el throughput debido a un bloqueo a nivel de repositorio.
La nueva arquitectura introduce dos cambios clave. Primero, el alcance del quorum se reduce de "repositorio completo" a "referencia individual". Esto permite que escrituras concurrentes a diferentes referencias (ej. diferentes ramas) procedan en paralelo, eliminando el cuello de botella del bloqueo a nivel de repositorio. Cada escritura individual aún experimenta la latencia cross-region, pero el throughput agregado aumenta significativamente. Segundo, se desacopla el almacenamiento del cómputo. Azure Blob Storage se integra como un "virtual replica" dentro del quorum de escritura. Este nodo efímero no sirve lecturas, sino que se encarga de persistir las escrituras de forma duradera en el almacenamiento de objetos. Una vez que los datos están en Blob Storage, se pueden desplegar "virtual read replicas" bajo demanda. Estas réplicas calientan su caché desde Blob Storage y sirven tráfico de lectura sin unirse al quorum de escritura, utilizando el almacenamiento de objetos como fuente de verdad y reconciliando su estado local en segundo plano. Esto permite escalar las lecturas independientemente de las escrituras y optimizar la configuración de caché para cada tipo de operación.
Flujo de Escritura con Quorum por Referencia
- 1 Cliente Git Inicia operación de push (actualización de referencia)
- 2 Spokes (API/LB) Recibe la solicitud, identifica la referencia a actualizar
- 3 Quorum Coordinator Inicia escritura concurrente para referencias no conflictivas
- 4 Réplicas (On-prem/Azure) Persisten la actualización de la referencia localmente
- 5 Virtual Replica (Azure Blob) Persiste la actualización de la referencia en Azure Blob Storage
- 6 Quorum Coordinator Espera confirmación de mayoría de réplicas (incl. Virtual Replica)
- 7 Spokes (API/LB) Confirma la escritura al cliente Git
Flujo de Lectura con Virtual Read Replicas
- 1 Cliente Git Inicia operación de pull/fetch (lectura de referencia)
- 2 Spokes (API/LB) Enruta la solicitud a una Virtual Read Replica disponible
- 3 Virtual Read Replica Sirve datos desde su caché en memoria
- 4 Virtual Read Replica Si no está en caché, recupera datos de Azure Blob Storage
- 5 Virtual Read Replica Reconcilia estado local con Azure Blob Storage en background
- 6 Cliente Git Recibe los datos del repositorio
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Azure Blob Storage | Almacenamiento duradero de objetos para datos de repositorio, actuando como fuente de verdad y permitiendo el desacoplamiento de almacenamiento/cómputo. |
| compute | Spokes | Capa de enrutamiento inteligente, balanceo de carga, API unificada para acceso a datos de repositorio y coordinador de quorums. Evoluciona para soportar réplicas virtuales y quorums por referencia. |
| orchestration | Virtual Read Replicas | Nodos de cómputo efímeros que calientan su caché desde Azure Blob Storage y sirven tráfico de lectura bajo demanda, escalando independientemente de las escrituras. |
Trade-offs
Ganancias
- ▲ Write Throughput
- ▲▲ Read Scalability
- ▲ Operational Flexibility
Costes
- △ Write Latency (individual write)
- ▲ Architectural Complexity
Fundamentos Teóricos
El problema de la consistencia y la disponibilidad en sistemas distribuidos, especialmente bajo latencia de red, es un tema central en la ciencia de la computación. El principio CAP Theorem (Consistency, Availability, Partition Tolerance) de Eric Brewer es fundamental aquí, donde GitHub debe elegir entre consistencia fuerte y alta disponibilidad en presencia de particiones de red. La decisión de relajar la serialización a nivel de repositorio y adoptar un quorum por referencia es una aplicación práctica de cómo se pueden ajustar los requisitos de consistencia para mejorar la disponibilidad y el rendimiento, sin comprometer la consistencia eventual de los datos de Git.
La idea de desacoplar el almacenamiento del cómputo resuena con los principios de diseño de bases de datos modernas y sistemas de almacenamiento en la nube, donde la elasticidad y la escalabilidad independiente son primordiales. Conceptos como el Write-Ahead Log (WAL) y las estructuras de datos inmutables (como los objetos Git) son precursores de la capacidad de reconstruir el estado a partir de un log de cambios y un almacenamiento de objetos duradero, permitiendo que las réplicas de lectura sean efímeras y se sincronicen asíncronamente.