Enrutamiento de tráfico de video en Asia-Pacífico con etcd
Una plataforma de streaming de video que presta servicio a ocho mercados de Asia-Pacífico detuvo un error de enrutamiento recurrente al trasladar la configuración específica de cada región a etcd. El tiempo de propagación de los cambios de enrutamiento se redujo a aproximadamente un segundo. Los editores ahora podían potenciar un grupo musical durante unas horas sin tocar el código, y la plataforma dejó de enviar la señal de Tokio a los espectadores de Corea del Sur.
Por qué fallaba el enfoque anterior
Cada router leía tres valores para cada solicitud: el grupo de tendencias (trending pool), el tokenizador específico de idioma y una cadena de respaldo (fallback chain). Las decisiones de negocio —promocionar a un nuevo artista, reaccionar a una interrupción regional o probar un algoritmo de recomendación— impulsaban esos valores, no los cambios de código.
Inicialmente, cada despliegue incluía un archivo JSON con la tabla de enrutamiento. Durante un incidente, un ingeniero de guardia editó el archivo en un nodo para dirigir el tráfico a un grupo de respaldo, pero nunca actualizó los otros siete nodos. Surgió una deriva de configuración (config drift): ocho países ejecutaban tablas divergentes y ninguna fuente única verificaba la "verdad". El error que enviaba a los espectadores de Seúl a Tokio persistía porque el código seguía siendo el mismo; solo difería la configuración oculta.
Elegir etcd como la única fuente de verdad
El equipo comparó tres opciones:
- SQLite/MySQL – obligaría a cada router a consultar una base de datos, añadiendo latencia o saturando con consultas.
- Consul – una herramienta sólida de descubrimiento de servicios, pero la plataforma no necesitaba todas sus funciones de malla (mesh).
- etcd – un almacén de clave-valor con consistencia fuerte que cuenta con una primitiva watch que notifica a los clientes en el momento en que una clave cambia.
La función watch inclinó la balanza. En lugar de que cada router preguntara repetidamente "¿ha cambiado algo?", los routers permanecían inactivos hasta que etcd enviaba una actualización. El tráfico de red innecesario desapareció y cada instancia se enteró del cambio simultáneamente.
Patrones que mantienen el sistema seguro
etcd por sí solo no resolvió todos los riesgos. Los ingenieros añadieron tres patrones complementarios:
- Leases (Arrendamientos) – un editor puede establecer un impulso temporal (por ejemplo, aumentar el peso de un grupo de K-pop durante seis horas). El arrendamiento expira automáticamente, por lo que el impulso desaparece sin necesidad de una reversión manual.
- Compare-and-swap (CAS) – cuando dos personas editan la misma configuración simultáneamente, el CAS falla de forma evidente para una de ellas, evitando sobreescrituras silenciosas.
- Proceso sidecar – PHP tiene dificultades con las conexiones de larga duración. Un pequeño sidecar en Go en cada máquina vigila etcd y escribe una instantánea de la tabla de enrutamiento en un archivo de memoria compartida (
/dev/shm). PHP lee ese archivo local, evitando cualquier viaje de ida y vuelta por la red durante el manejo de las solicitudes.
Resiliencia integrada en la arquitectura
El nuevo diseño añade varias redes de seguridad:
- Lecturas de latencia cero – la ruta crítica (hot path) de PHP lee desde la memoria local, por lo que las solicitudes nunca se detienen esperando un almacén remoto.
- Degradación controlada – si etcd deja de funcionar, los routers siguen sirviendo la última configuración válida conocida, evitando una interrupción repentina.
- Actualizaciones fiables – el sidecar gestiona la lógica de reconexión y garantiza que no se pierda ningún cambio, incluso si la conexión con etcd se interrumpe temporalmente.
Lo que cambió en la práctica
Tras la migración, el equipo observó una drástica disminución de los incidentes causados por datos de enrutamiento obsoletos o desajustados. Una única consola muestra ahora la configuración actual, y cualquier edición se propaga a las ocho regiones en menos de un segundo. Los impulsos temporales se eliminan automáticamente cuando expira su arrendamiento, eliminando los pasos de limpieza manual que anteriormente provocaban errores humanos.
Contrapunto: el coste de un sidecar
Añadir un sidecar significa un segundo proceso por servidor y un entorno de ejecución (runtime) de Go en una pila centrada en PHP. Algunos operadores se preocupan por el uso adicional de memoria y la necesidad de monitorizar otro binario. En la práctica, la huella del sidecar es modesta, y las ganancias en fiabilidad —especialmente la garantía de que PHP nunca se bloquee por una llamada de red— compensan la carga operativa.
Qué vigilar a continuación
Los equipos que gestionan servicios multirregión deben monitorizar:
- métricas de salud de etcd – la capa de enrutamiento depende de un único almacén; vigile el estado del quórum y la latencia.
- gestión de la expiración de los arrendamientos – ajuste los tiempos de los arrendamientos a las ventanas de negocio; los arrendamientos excesivamente largos dejan impulsos obsoletos activos.
- escalado de la carga de watch – a medida que crecen los routers, aumentan las conexiones de watch; planifique la capacidad de los servidores etcd en consecuencia.
Conclusión
Para cualquier servicio que necesite cambios de configuración rápidos y coordinados en múltiples regiones, las primitivas watch, lease y transaction de etcd ofrecen una alternativa ligera y de consistencia fuerte frente a las configuraciones basadas en archivos o a las mallas pesadas. Convertir la configuración en un almacén impulsado por push y de autolimpieza eliminó toda una clase de incidentes y le otorgó a la plataforma un control en tiempo real sobre su lógica de enrutamiento.