OpenAI: estrategia de escalado masivo de PostgreSQL para sostener a 800 millones de usuarios

Resumen:

• OpenAI está manejando millones de QPS y 800 millones de usuarios con un solo Primary y alrededor de 50 Read Replica (Azure Flexible Server).
• Para distribuir la carga de escritura, migró a Azure Cosmos DB las cargas de trabajo que pueden particionarse, y también optimizó las escrituras a nivel de aplicación aplicando estrategias como 'Lazy Write'.
• Implementó PgBouncer para reducir la latencia de conexión de 50 ms a 5 ms, y desarrolló un mecanismo de cache locking para evitar tormentas de cache miss.
• Aseguró la estabilidad eliminando consultas con joins complejos, aplicando un timeout estricto de menos de 5 segundos para cambios de esquema y aislando cargas de trabajo según la prioridad del tráfico.

Resumen detallado:
1. Contexto y estado actual de la arquitectura
El tráfico de PostgreSQL de OpenAI creció más de 10 veces en el último año y hoy procesa 800 millones de usuarios y millones de QPS (consultas por segundo). Sorprendentemente, esta escala opera con una arquitectura de un solo Primary y alrededor de 50 Read Replica distribuidas globalmente. Para evitar que el diseño inicial se fracture, OpenAI realizó optimizaciones importantes tanto en la capa de infraestructura como en la de aplicación.

2. Principales cuellos de botella y estrategias de optimización

• Distribución de la carga de escritura:

  • La estructura de un solo Writer de PostgreSQL tiene límites de escalado y además presenta problemas de write amplification por MVCC (control de concurrencia multiversión).
  • Como solución, las cargas de trabajo intensivas en escritura que pueden dividirse horizontalmente (sharding) se migraron a sistemas como Azure Cosmos DB.
  • En el PostgreSQL existente se prohibió crear tablas nuevas, y se minimizó la carga sobre el Primary corrigiendo bugs de aplicación e incorporando Lazy Write (diferir escrituras para suavizar picos de tráfico).

• Optimización de consultas y control del ORM:

  • En el pasado, una consulta que hacía join sobre 12 tablas provocó un incidente grave (SEV), por lo que se evitó el uso de múltiples joins complejos y esa lógica se separó hacia la aplicación.
  • También se revisan continuamente las consultas ineficientes generadas por el ORM, y mediante la configuración idle_in_transaction_session_timeout se evitó que consultas inactivas bloquearan el Autovacuum.

• Connection pooling (PgBouncer):

  • Para evitar el límite de conexiones de Azure PostgreSQL (5,000) y los picos de conexiones simultáneas, se desplegó PgBouncer como capa de proxy.
  • Se usaron modos de pooling por transacción y por sentencia para aumentar la reutilización de conexiones, reduciendo el tiempo promedio de conexión de 50 ms a 5 ms.

• Prevención de cache miss masivos (Cache Locking):

  • Para evitar el problema de thundering herd, en el que muchas solicitudes golpean la base de datos al mismo tiempo cuando expira el caché, se introdujo un mecanismo de cache locking (leasing).
  • Cuando ocurre un cache miss para una clave específica, solo una solicitud obtiene el permiso (lock) para acceder a la base de datos y refrescar los datos, mientras que las demás esperan, bloqueando así la sobrecarga sobre la base de datos.

3. Estabilidad y políticas operativas

• Mitigación de punto único de falla (SPOF): incluso si falla el Primary, las solicitudes de lectura pueden seguir atendiéndose mediante las réplicas, reduciendo la severidad del incidente. Además, el Primary mantiene un Hot Standby en modo de alta disponibilidad (HA) para garantizar un failover rápido.
• Aislamiento de cargas de trabajo: para evitar el problema de noisy neighbor, el tráfico se enruta a instancias separadas según su importancia (Low/High Priority).
• Gestión estricta del esquema: se prohíben los cambios que provoquen un Full Table Rewrite, y en los cambios de esquema se aplica un timeout estricto de 5 segundos para evitar degradaciones del servicio.

4. Planes a futuro (The Road Ahead)
Aunque la arquitectura actual ya ofrece suficiente escalabilidad, OpenAI está probando Cascading Replication para seguir ampliando la cantidad de Read Replica, en lugar de usar una estructura donde el Primary envía el WAL a todas las réplicas. En este modelo, una réplica intermedia reenvía el WAL a las réplicas subordinadas. A largo plazo, también contempla el sharding del propio PostgreSQL.

[jaemkim]

Resumen de la discusión en Hacker News: https://news.ycombinator.com/item?id=46725300

La imponencia de una sola instancia: hubo muchas reacciones que reafirmaron la validez del escalado vertical, con comentarios como "definitivamente los servidores de BD grandes son nuestros amigos (Big DB servers are your friend)" ante el hecho de que manejan tráfico a escala de 800 millones de usuarios con un solo Postgres (Write) sin sharding.

La ironía de sharding vs. refactorización: sobre el pasaje del texto que dice que "eligieron no hacer sharding porque refactorizar la app existente era demasiado complejo", circularon bromas punzantes y críticas como "es irónico que una empresa que vende IA para programar diga que no puede refactorizar porque es difícil". (Por otro lado, también hubo defensas de que es una decisión razonable si se considera la complejidad operativa y el costo de migración que traería el sharding.)

Decepción por la falta de profundidad técnica: como el artículo se centra más bien en contenidos generales (caché, connection pooling, etc.), también hubo algunas miradas críticas diciendo que le faltan detalles concretos de ingeniería y que "parece un artículo promocional".

Discusión relacionada con Rust: en los comentarios, aparte del texto principal, también se compartieron técnicas para bloquear de raíz el problema de "Idle Transaction" usando verificaciones en tiempo de compilación de Rust, y eso llevó a una discusión técnica más profunda.

[jaemkim]

Personalmente, me pareció interesante cómo aplicaron una estructura como Cascading Replication o cómo superaron límites técnicos a través de la operación. Sobre eso, dejé mis ideas algo más desarrolladas en Facebook. https://www.facebook.com/share/p/1Kp8V917bL/