OpenAI reescribe el almacenamiento Habitat: 500 PB de datos y 1000 millones de usuarios sobre Cosmos DB

Habitat, la plataforma sobre la que funcionan ChatGPT, la API, Codex y los servicios internos de OpenAI, atiende a más de 1000 millones de usuarios en 40 regiones geográficas y almacena más de 500 petabytes de datos. Las respuestas deben llegar en milisegundos. En la segunda parte de su análisis de ingeniería, Jon Lee, Hrachya Hakobyan y Chaomin Yu cuentan cómo el equipo exprimió Azure Cosmos DB al máximo, pasó por tres modelos de multitenencia y acabó volviendo a un único contenedor compartido.

Fase I: contenedor compartido y tres problemas de fondo

Al principio, OpenAI aceptaba cualquier carga de cliente y confiaba en el límite documentado de Cosmos DB, 10K RU/s por clave de partición lógica, como back pressure natural. Cada cuenta tenía un solo contenedor, el predeterminado. Funcionó hasta que la escala dejó al descubierto tres problemas.

El primero: por decisiones tempranas de diseño de la API, la elección de la clave de partición quedó en manos de los clientes. Claves populares como user_id o workspace_id coincidían en distintos casos de uso de producto, que acababan compartiendo el límite de una misma clave. El segundo: los límites se aplican en realidad a nivel de partición física, de modo que una clave lógica nunca llega a los 10 000 RU/s y los vecinos de partición se perjudican entre sí.

Funciones secundarias afectaban a flujos críticos como el inicio de sesión y el registro. El tercero: el rendimiento del contenedor se reparte a partes iguales entre las particiones físicas. Cuando los datos crecen y las particiones se dividen, el aprovisionamiento total sigue igual, pero el límite por partición baja.

En los casos de uso pesados, similares a blobs, el simple crecimiento del almacenamiento reducía el rendimiento disponible con un tráfico estable.

Fase II: un aislamiento que no escalaba a nivel organizativo

Los contenedores separados resolvieron parte de los problemas. Cada uno tiene sus propias particiones físicas, y solo las cargas de su interior pueden ser vecinos ruidosos. Para los nuevos casos de uso críticos se asignaban contenedores, y un script sincronizaba el aprovisionamiento con el número de particiones físicas y reparaba las particiones débiles. Esto evitó las caídas a escala de todo el sitio: los fallos se limitaban a la degradación de una función o de un servicio.

Pero los costes de gestión crecían. La razón principal: en un contenedor compartido, que un nuevo caso de uso pasara de 0 a 1 millón de QPS apenas movía el agregado. En un contenedor dedicado de 10K RU/s, el mismo salto desde 1K RU/s en la prueba de carga hasta 1M RU/s en el lanzamiento suponía un 10 000% del margen, mientras que en un contenedor compartido de 100M RU/s con un 80% de utilización ocupaba cerca de un 5%.

Los equipos lanzaban funciones y se olvidaban de escalar con antelación, y el día del lanzamiento los ingenieros acababan en salas SEV. La planificación de capacidad exigía que cada equipo conociera su producto a fondo, y la calidad de ese trabajo variaba mucho.

Fase III: regreso al contenedor compartido junto con Azure

OpenAI volvió a la multitenencia por defecto y, junto con el equipo de Azure, corrigió las carencias originales:

• Hot key throttling. El throttling de las claves más calientes impide, ante todo, que una sola clave consuma todo el rendimiento de una partición física.
• Quality of Service. Consultas por niveles: las cargas offline, como las inserciones masivas y las exportaciones, reciben baja prioridad y se limitan primero, mientras que el tráfico interactivo de los usuarios queda intacto.
• Nuevo modo serverless. El anterior solo escalaba según el almacenamiento y limitaba cada partición física a 5K RU/s. El nuevo permite que cada partición crezca hasta 10K RU/s y añade splits por carga de RU además de los splits por volumen. Ya no hace falta monitorizar ni subir el aprovisionamiento a mano.

El resultado: un único contenedor compartido, una planificación de capacidad mucho más sencilla para los equipos de producto y el aislamiento de cargas conservado. En los meses posteriores a la migración no hubo incidentes de aprovisionamiento ni de vecinos ruidosos, y el desarrollo de productos se aceleró.

Qué conviene llevarse

La experiencia de OpenAI sirve como lista de comprobación para cualquier equipo que construya una plataforma de datos compartida.

• No dejéis que los clientes elijan la clave de partición. Esa decisión temprana en la API obligó después a compensarla con toda una infraestructura.
• Vigilad el límite efectivo por partición física, no el de la clave lógica. Con los splits baja aunque el tráfico no cambie.
• Aislar con contenedores sale caro a nivel organizativo: cada equipo se convierte en planificador de capacidad y desaparece el crecimiento agregado estable.
• Priorizad el tráfico. Las inserciones masivas y las exportaciones deben limitarse antes que las consultas de los usuarios.
• Si la escala es grande, exigid mejoras al proveedor. OpenAI consiguió de Azure un modo serverless específico, en lugar de sortear las limitaciones por su cuenta.

La propia OpenAI dice que aún está al principio de su camino en multitenencia. Pero, de momento, el beneficio es evidente: menos salas SEV en los lanzamientos y menos trabajo manual para los equipos de producto.