Despliegues blue-green y conmutación por DNS

Un despliegue blue-green mantiene en marcha dos entornos de producción completos (uno activo, «blue», y otro inactivo pero totalmente desplegado y listo, «green») y traslada el tráfico de uno a otro con un único cambio rápido, en lugar de una actualización gradual. Una forma habitual de implementar ese cambio, sobre todo entre infraestructuras o proveedores distintos, es un cambio de DNS: actualizar el registro del dominio para que apunte a la dirección del entorno green una vez verificado que está sano.

Dónde se queda corta la versión simple

Una conmutación por DNS no es instantánea como suele serlo cambiar el grupo de destino de un balanceador de carga. Cada resolvedor que guardó en caché la respuesta antigua (blue) sigue sirviéndola hasta que caduca el TTL de ese registro; es decir, durante una ventana de tiempo proporcional al TTL, una parte del tráfico sigue llegando al entorno que acabas de intentar abandonar. Con un TTL de una hora, eso supone potencialmente una hora de tráfico dividido entre ambos entornos hasta que la conmutación esté completa en todas partes.

• Reduce el TTL con bastante antelación a la conmutación prevista, idealmente al menos un ciclo completo del TTL antiguo antes, de modo que en el momento del cambio todos los resolvedores ya hayan vuelto a guardar en caché el valor con el nuevo TTL, más corto.
• Mantén el entorno antiguo (blue) en marcha y sano al menos durante la ventana del TTL posterior a la conmutación, sin retirarlo de inmediato: durante esa ventana sigue recibiendo tráfico real.
• Verifica la conmutación consultando el DNS directamente en lugar de limitarte a revisar los registros de la aplicación: así confirmas que el propio registro cambió, con independencia de cuánto tráfico lo haya alcanzado ya.
• Vuelve a subir el TTL a su valor normal solo cuando estés seguro de que la conmutación está completa y es estable.

La alternativa gradual: DNS ponderado

En lugar de cambiar todos los resolvedores a la vez y confiar en que el entorno green aguante de inmediato toda la carga de producción, varios proveedores de DNS admiten políticas de enrutamiento ponderado (o basado en porcentajes): el 95 % de las respuestas apunta a blue, el 5 % a green, y ese reparto se va desplazando gradualmente (80/20, 50/50 y así sucesivamente) a medida que crece la confianza en el nuevo entorno.

Sacrificas la simplicidad de un cambio único y limpio a cambio de poder detectar un problema mientras solo afecta a una porción pequeña del tráfico, y de volver al 100 % en blue en segundos si green no estaba listo, en lugar de tener que revertir una conmutación completa bajo presión.

Verificar cualquiera de los dos enfoques de la misma manera

Sea cual sea la estrategia, el paso de verificación es idéntico: resuelve el dominio repetidamente, desde más de un punto de observación, y confirma que el reparto observado coincide con el configurado. Una política ponderada que debía enviar el 10 % del tráfico a green pero en realidad envía el 40 % (por un peso mal configurado, o porque algunos resolvedores guardan en caché y no repiten el sorteo del reparto tan a menudo como se esperaba) es justo el tipo de desviación que solo se detecta comprobando las respuestas resueltas reales, en lugar de confiar en que el panel del proveedor de DNS refleje la realidad a la perfección.