Entrega de la configuración de red de Databricks a decenas de millones de VMs serverless

Resumen

• La plataforma serverless de Databricks lanza decenas de millones de VMs al día, y cada VM necesita una configuración de red (como destinos permitidos y endpoints privados) antes de procesar las cargas de trabajo de los clientes. Dado que cada nodo obtiene la configuración al arrancar y realiza sondeos periódicos para recibir actualizaciones durante su ciclo de vida, esto se traduce en miles de millones de solicitudes de configuración de red al día. La arquitectura anterior obtenía esta información de múltiples servicios upstream de forma síncrona, lo que creaba cuellos de botella en la latencia y la disponibilidad.
• Rediseñamos la arquitectura de entrega de configuración de red utilizando pipelines basados en eventos y precomputación de snapshots, lo que redujo la latencia de RPC en un 97.5% (5,000 ms → 125 ms) y logró una disponibilidad del servicio del 99.99%.

Planteamiento del problema

La plataforma de computación serverless de Databricks impulsa prácticamente todos nuestros productos de datos e IA, como SQL warehouses, notebooks, endpoints de servicio de ML y más. La plataforma lanza decenas de millones de VMs al día en AWS, Azure y GCP.

Antes de que se pueda ejecutar cualquier carga de trabajo serverless, la VM necesita conocer su configuración de red: ¿A qué destinos de almacenamiento puede acceder? ¿Existen endpoints de private link a través de los cuales deba enrutar el tráfico? ¿Hay cambios recientes en Unity Catalog que otorguen acceso a nuevos destinos de almacenamiento? ¿Comenzamos a consumir nuevos destinos compartidos a través de Delta Sharing?

El desafío es que la configuración de red no se almacena en un solo lugar. Debe compilarse a partir de múltiples servicios upstream, donde cada uno aporta una pieza del panorama completo.

La arquitectura anterior

En el diseño original, cada vez que se iniciaba un clúster serverless, nuestro servicio de configuración de red llamaba de forma síncrona a todos los servicios upstream, agregaba sus respuestas, calculaba la configuración de red por workspace y la devolvía al dataplane serverless. Esto ocurría en la ruta crítica de la creación del clúster.

Aunque la arquitectura anterior era simple y funcionaba bien a pequeña escala, sufría de problemas fundamentales que se reflejaban en las siguientes métricas que seguimos en nuestro panel de control operativo:

1. Latencia: Con múltiples servicios upstream en la ruta crítica, la latencia de RPC para entregar la configuración de red era de 5,000 ms en el p99. Esto afectaba la latencia de inicio de los clústeres serverless.
2. Tasa de éxito del servidor: Cada servicio upstream tiene sus propias características de disponibilidad. Con varios servicios en serie, la disponibilidad compuesta disminuye rápidamente, lo que se traduce en una mayor probabilidad de fallos en el lanzamiento de clústeres serverless al año.

A medida que el uso de serverless continuó su rápido crecimiento, el modelo síncrono se volvió cada vez más insostenible. Cada llamada síncrona desencadenaba operaciones costosas en todos los workspaces, a menudo realizando cálculos duplicados. Esto añadía una carga que crecía proporcionalmente con el número de tenants y sus recursos configurados.

Solución: Precomputación basada en eventos

Rediseñamos desde cero la arquitectura de cómo Databricks entrega la configuración de red. Se basa en los siguientes principios fundamentales:

1. Pipeline basado en eventos: En lugar de realizar llamadas síncronas a todos los servicios upstream, el nuevo sistema se suscribe a eventos de cambio a través de una cola de mensajes. Cuando un cliente crea una nueva conexión de Unity Catalog o modifica una política de red, el servicio upstream emite un evento. El sistema lo procesa y actualiza la configuración precomputada.
2. Precomputación de snapshots: Las configuraciones de red se calculan de forma asíncrona en segundo plano y se almacenan en un repositorio de snapshots precomputados. La ruta de entrega se convierte en una única y ligera lectura de almacenamiento, completamente desacoplada de los servicios upstream.
3. Estabilidad estática: En caso de que se produzca una interrupción en cualquier servicio upstream, podemos mantener una configuración estática, lo que proporciona estabilidad estática a los clústeres serverless.

La arquitectura separa claramente dos rutas. La ruta de gestión se ejecuta de forma asíncrona en segundo plano: los servicios upstream emiten eventos de cambio a una cola de mensajes, que un procesador de eventos consume para determinar qué workspaces se ven afectados y distribuir las notificaciones de actualización por workspace. A continuación, un gestor de eventos local obtiene los detalles pertinentes de los servicios upstream, vuelve a calcular la configuración de red del workspace y almacena el resultado en un repositorio de snapshots precomputados. Un reconciliador periódico también vuelve a sincronizar todos los workspaces en segundo plano, lo que garantiza la consistencia eventual incluso si se pierden eventos. Por el contrario, la ruta de entrega es crítica y rápida: cuando un clúster serverless se inicia y necesita la configuración de red, el servicio de configuración de red la entrega directamente desde el repositorio de snapshots con una sola lectura de almacenamiento, sin requerir llamadas a servicios upstream y reduciendo significativamente la carga sobre estos.

Decisiones de diseño clave

• Los servicios upstream envían (push) eventos de cambio a la cola de mensajes. El sistema procesa estos eventos en segundo plano. Un reconciliador de baja frecuencia vuelve a sincronizar periódicamente todos los workspaces como red de seguridad, lo que proporciona la fiabilidad de un marco síncrono con la eficiencia del modelo push.
• Las configuraciones de red se calculan y almacenan localmente dentro de cada partición de servicio, ubicadas junto con los workspaces a los que sirven. Esto distribuye el cálculo, reduce el radio de impacto (blast radius) durante los incidentes y elimina las dependencias entre particiones en la ruta de entrega.
• Los eventos contienen únicamente identificadores de recursos y de workspaces. Esto hace que los eventos sean ligeros, idempotentes (se pueden reproducir en cualquier orden) y evita la transferencia de datos confidenciales de los clientes a través del pipeline de mensajería.

Cómo fluyen los eventos

Cuando un cliente crea una nueva conexión de Unity Catalog, Unity Catalog emite un evento de cambio a la cola de mensajes. A continuación, el procesador de eventos recibe el evento, determina qué workspaces están vinculados al metastore afectado y distribuye una notificación de actualización por workspace. En la partición de cada workspace, el gestor de eventos recibe esta notificación, obtiene los detalles de la conexión actualizada, vuelve a calcular la configuración de red del workspace y la almacena con una nueva marca de versión. A partir de ese momento, cuando un clúster serverless solicita la configuración de red, esta se entrega directamente desde el repositorio de snapshots sin necesidad de realizar llamadas upstream.

Impacto

Tras implementar la nueva arquitectura, los resultados fueron transformadores en todas las métricas operativas:

Más allá de las métricas principales:

1. El volumen de llamadas upstream se redujo en un 86%. El sistema solo llama a los servicios upstream cuando un evento indica un cambio, no con cada solicitud.
2. Observamos una mejora significativa en la actualización de la configuración de red.
3. El marco síncrono heredado se ha retirado por completo.

Conclusión

Este proyecto nos dejó varias lecciones sobre el funcionamiento de la infraestructura de red a escala de la nube:

La precomputación desacopla las rutas críticas. Al trasladar la costosa agregación al segundo plano, la ruta de entrega se vuelve sumamente sencilla y rápida. Esta es la decisión arquitectónica más importante. Transformó una cadena de dependencias multiservicio en una única lectura de almacenamiento.

La arquitectura basada en eventos prioriza la escalabilidad frente a la consistencia, y la reconciliación proporciona la red de seguridad. El modelo push basado en eventos gestiona los casos comunes de forma eficiente, mientras que un reconciliador periódico detecta cualquier anomalía que pueda haberse pasado por alto.

Diseñar para la extensibilidad desde el primer día. La arquitectura modular basada en etapas significa que añadir soporte para una nueva fuente de datos upstream solo requiere la implementación de una nueva etapa, sin realizar ningún cambio en el pipeline principal. A medida que la oferta de productos de Databricks se expande, el sistema de configuración de red escala con ella.

Hoy en día, este sistema atiende miles de millones de solicitudes de configuración de red al día en toda la flota global serverless de Databricks, con una latencia de aproximadamente 125 ms y una disponibilidad del 99.99%. A medida que la computación serverless continúa su rápido crecimiento, la arquitectura basada en eventos garantiza que la entrega de la configuración de red escale a la par.

Siempre estamos buscando ingenieros que disfruten resolviendo desafíos de sistemas distribuidos a escala global. Si te entusiasman este tipo de problemas, ¡nos encantaría saber de ti! Consulta las vacantes disponibles en databricks.com/careers.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original