Cómo OpenAI mantuvo en pie Azure Cosmos DB bajo la carga de 1.000 millones de usuarios de ChatGPT

Habitat: la columna vertebral de datos interna de OpenAI

Habitat es la plataforma de almacenamiento interna de OpenAI por la que pasan las solicitudes de ChatGPT, la API, Codex y decenas de servicios internos. Debe responder en milisegundos mientras atiende a más de mil millones de usuarios en todo el mundo, y almacena más de 500 petabytes de datos. El motor principal detrás de todo es Azure Cosmos DB. Los ingenieros de OpenAI John Lee, Grach Hakobyan y Chaoming Yu describieron cómo reconstruyeron tres veces el principio de distribución de carga entre productos dentro de esta base, antes de dar con un esquema que funcionara.

El problema de la base compartida y los "vecinos ruidosos"

Originalmente, todos los productos escribían en una sola base de datos (contenedor) compartida de Cosmos DB. Cada clave —por ejemplo, un identificador de usuario— tiene un límite de 10.000 operaciones por segundo, pero en la práctica ese límite se aplica no a la clave en sí, sino a la partición física del disco donde esa clave se almacena físicamente junto con otras. Esto generaba dos problemas:

• Productos distintos que usaban claves con un significado similar (por ejemplo, user_id) compartían entre sí ese límite, aunque lógicamente no debían superponerse.
• Si un cliente aumentaba bruscamente la carga en "su" partición, sufrían todos los demás usuarios y funciones cuyos datos quedaban cerca por casualidad, hasta el punto de provocar fallos de inicio de sesión.

Además apareció el problema de las "particiones débiles": cuando una partición de disco crecía y Cosmos DB la dividía en dos, el ancho de banda de cada mitad se reducía proporcionalmente, es decir, el crecimiento del volumen de datos por sí solo reducía la velocidad, aunque el número de solicitudes no cambiara.

Aislamiento mediante bases separadas, y su precio

La solución fue crear bases de datos separadas para cada producto o función nueva importante. Esto realmente eliminó el efecto de los "vecinos ruidosos": ahora la sobrecarga de un servicio ya no afectaba a los demás. Pero el enfoque tuvo su contrapartida:

• Los equipos de producto debían solicitar ellos mismos el ancho de banda necesario con antelación para el lanzamiento, y a menudo se olvidaban de hacerlo, por lo que los lanzamientos iban acompañados de reuniones de emergencia de escalado de último momento.
• Una carga que en la base compartida habría sido una gota imperceptible (pasar de mil a un millón de solicitudes por segundo es solo el 5% de la capacidad total) podía representar, en una base separada, mil veces más de los recursos previstos.
• La planificación de capacidad quedó dispersa en toda la empresa en lugar de concentrarse en un solo equipo central, y la calidad de esa planificación variaba mucho de un equipo a otro.

Vuelta a la base compartida, pero con equilibrio inteligente

Al comprender que ninguno de los dos enfoques escalaba a nivel organizativo, el equipo de Habitat, junto con ingenieros de Microsoft, rediseñó la propia mecánica de Cosmos DB:

• Añadieron limitación prioritaria para las claves más "calientes", de modo que un cliente agresivo no pudiera apropiarse de todo el ancho de banda de una partición.
• Introdujeron la priorización de solicitudes (QoS): las tareas en segundo plano, como las exportaciones masivas de datos, ahora son las primeras en recortarse, mientras que las solicitudes interactivas de los usuarios son las últimas.
• Junto con Azure, mejoraron el modo sin servidor de Cosmos DB, elevando el límite de 5.000 a 10.000 operaciones por segundo por partición y añadiendo división automática según la carga, y no solo según el volumen de datos.

Esto permitió volver a una sola base de datos compartida sin planificación manual de capacidad, y según los autores, en los meses posteriores al cambio no hubo ningún fallo por sobrecarga o vecinos ruidosos.

Ingeniería conjunta con Microsoft

La cuenta de Cosmos DB más grande de OpenAI almacena decenas de petabytes y gestiona más de 20 millones de solicitudes por segundo; los autores la consideran el despliegue más grande que conocen del servicio. A esa escala, el soporte habitual de un proveedor de nube deja de funcionar: a finales de 2024, un corte de energía en una de las regiones mostró que el cambio a una región de respaldo para cuentas de ese tamaño tomaba varias horas, algo que nadie había probado a semejante escala. Un mes después, al revertir el cambio, se produjo un segundo incidente: los clientes se apresuraron en masa a reconectarse a la región original y sobrecargaron su puerta de enlace, aunque solo había vuelto una parte de los datos.

Tras estos incidentes, los equipos de OpenAI y Azure establecieron una colaboración directa: paneles compartidos, pruebas conjuntas sobre una copia de la cuenta de producción, canales directos en Teams y la posibilidad de contactarse directamente entre sí sin pasar por el soporte técnico estándar. Durante el último año, mejoraron juntos la escalabilidad de la puerta de enlace de Cosmos DB, añadieron almacenamiento en caché de metadatos, redujeron el número de conexiones de los servicios Python de Habitat y separaron las cargas críticas de las de fondo en redes distintas.

La principal conclusión para los equipos de ingeniería: los sistemas multiusuario (compartidos) son más baratos y simples de operar, pero requieren mecanismos de aislamiento integrados por parte del propio proveedor; sin ellos, la única alternativa es dividir manualmente en bases separadas, lo que simplemente traslada el problema de planificación de capacidad a decenas de equipos.