Reverse ETL frente a la nube privada: guía de supervivencia conceptual

Reverse ETL frente a la nube privada: guía de supervivencia conceptual

La “fuerza imparable” se encuentra con el “objeto inamovible”"

Las arquitecturas de datos modernas a menudo tienen un objetivo común: poner los datos del almacén en manos de los equipos que los necesitan. Sin embargo, cuando trabajas con una seguridad de red estricta, sueles llegar a un punto muerto.

Por un lado, tienes Segment Reverse ETL, que necesita un punto final HTTPS público para hacer su trabajo. Por el otro, tienes un Databricks SQL Warehouse escondido de forma segura dentro de una red virtual privada de Azure (VNet), invisible para el Internet público.

Esto introdujo dos restricciones clave:

• Segment requiere un punto final HTTPS de acceso público
• Databricks SQL Warehouse no era de acceso público

Esto creó una brecha entre los requisitos de conectividad y el aislamiento de la red, lo que hizo que la integración directa fuera inviable. La seguridad dice "Sin acceso público". Segment dice: "No puedo verte". Así es como creamos un puente entre ellos sin romper las reglas.

Segment Reverse ETL en acción: Tres formas de fallar (y una forma de ganar)

Para enfrentar este desafío, se evaluaron varios enfoques durante la prueba de concepto (POC). No lo hicimos correctamente el primer día. Tratamos este POC como una carrera de velocidad para encontrar los "bloqueadores" específicos en la cadena de conectividad. Cada paso ayudó a identificar lo que se requería para una solución funcional.

Intento de conectividad directa

Primero probamos la línea recta. Intentamos conectar Segment Reverse ETL directamente a Databricks SQL Warehouse.

• El resultado: silencio total.
• La lección: no puedes hacer un "handshake" con un servidor que no está en la lista de invitados. Los puntos finales privados son privados por un motivo.

Esto no fue exitoso porque:

• Databricks no era de acceso público
• Segment no pudo alcanzar puntos finales privados

Esto confirmó que la conectividad directa no era factible en una configuración de red privada.

El siguiente enfoque implicó el uso del conector Databricks de Segment con configuración estándar.

Configuración estándar del conector

Posteriormente, probamos el conector Databricks de Segment con configuración estándar. Topamos con dos paredes de inmediato:

Discrepancia de OAuth: Segment esperaba un flujo de autenticación específico (credenciales básicas/del cliente), mientras que Databricks quería un handshake OAuth completo que el conector actual no estaba listo para manejar.

El filtro de nombre de host: el controlador de Databricks es exigente. Utiliza una verificación de strings.Contains para buscar azuredatabricks.net en el nombre de host. Si no está allí, ni siquiera intentará hablar.

En aras de la conveniencia, la introducción de una capa de proxy externo se identificó como el enfoque más práctico.

Asignación personalizada de nombre de host y DNS

Para satisfacer los requisitos de validación de conectores, se introdujo un nombre de host personalizado que incluía azuredatabricks.net.

Ejemplo de patrón:

• dev.staging.azuredatabricks.net.<custom-domain>

Este nombre de host se asignó a la IP pública de Azure Application Gateway.

Este enfoque garantizó lo siguiente:

• Resolución exitosa de DNS
• Compatibilidad con la validación del nombre de host del conector

Además, se consideró el comportamiento del controlador SQL de Databricks:

• El controlador determina el contexto del proveedor de la nube mediante la coincidencia del nombre de host
• Debido a que utiliza la coincidencia de subcadenas (strings.Contains), se puede crear un nombre de host compatible mientras sigue enrutando a través de la infraestructura personalizada

Sin embargo, este enfoque por sí solo no fue suficiente porque:

• No existía una lógica de back-end para procesar solicitudes
• No se implementó el manejo de autenticación
• No había lógica de transformación o enrutamiento de solicitudes

Esto confirmó que la alineación de DNS era necesaria para la validación, pero no suficiente para la integración.

Enfoque de solo puerta de Application Gateway

Agregamos una Azure Application Gateway para manejar el ingreso público. Esto resolvió el problema de "visibilidad", pero Gateway no es un cerebro, así que no pudo manejar el complejo intercambio de tokens necesario para mantener contento a Databricks.

Application Gateway proporcionó correctamente:

• Ingreso público
• Finalización de TLS
• Enrutamiento de solicitudes

Sin embargo, este enfoque falló porque:

• No pudo realizar el intercambio de tokens OAuth
• No pudo exponer los puntos finales de autenticación
• No pudo manejar transformaciones a nivel de solicitud

Esto confirmó que el enrutamiento solo no era suficiente para permitir la integración.

Autenticación y enrutamiento a través de la capa de proxy

Se introdujo un servicio de proxy personalizado para cerrar las brechas de autenticación y conectividad entre Segment y Databricks.

El proxy se diseñó para alinearse con las expectativas de Segment mientras interactúa de manera segura con Databricks.

Capa de autenticación

• Expone los puntos finales compatibles con OIDC:
• /oidc/v1/token
• /oidc/.well-known/oauth-authorization-server
• /oidc/jwks.json
• Acepta la autenticación básica de Segment
• Emite tokens JWT firmados (RS256)
• Valida los tokens JWT entrantes mediante pares de claves públicas/privadas
• Mantiene el ciclo de vida del token mediante identificadores únicos (jti)

Intercambio de tokens con Databricks

• Recupera los tokens de acceso de Databricks mediante el flujo client_credentials
• Almacena en caché los tokens para minimizar las llamadas de autenticación repetidas
• Reemplaza los tokens entrantes emitidos por proxy con tokens OAuth válidos de Databricks

Capa de reenvío de solicitudes

• Enruta las solicitudes a los puntos finales de Databricks (/api, /sql)
• Normaliza y elimina los encabezados contradictorios antes del reenvío
• Preserva la compatibilidad con las API de Databricks SQL

Capacidades operativas

• Punto final de salud (/health) para el monitoreo
• Compatibilidad con TLS para una comunicación segura
• Solicita seguimiento con visibilidad de latencia (tiempo de respuesta del proxy frente al del servidor de origen)

Esto resolvió:

• Problemas de validación de conectores
• Incompatibilidad de autenticación
• Fallas en la ejecución de consultas

El proxy actuó eficazmente como una capa de traducción de autenticación y un mecanismo de enrutamiento controlado.

El avance: El proxy de "intercambio de identidad"

Para ganar, necesitábamos más que un proceso,; necesitábamos un traductor. Creamos un servicio de proxy personalizado entre Gateway y Databricks.

La salsa secreta

Nuestro proxy realizó un poco de "magia" técnica para mantener contentas a ambas partes:

• La máscara DNS: le dimos al proxy un nombre de host personalizado como dev.staging.azuredatabricks.net.custom-domain.com. Debido a que contenía la "cadena mágica", el controlador de Databricks aceptó la conexión.
• El intercambio de tokens: el proxy expone los puntos finales compatibles con OIDC. Toma las credenciales de Segment, se dirige a Databricks para obtener un token OAuth "real", lo almacena en caché para mayor velocidad y lo inyecta en la solicitud.
• Limpieza de encabezados: elimina y normaliza los encabezados sobre la marcha, lo que garantiza que para el momento en que una solicitud llegue a Databricks, se vea perfectamente nativa.

La arquitectura final

Flujo de solicitudes: