Dark Launch es el mejor Light Launch

Huevos de Pascua por todos

En mi último trabajo, solíamos crear sistemas de recomendación de productos para empresas de comercio electrónico, lo que significa que nuestras API estaban activas en todas las páginas de su sitio web. Conseguimos un nuevo cliente, que fue nuestra primera oferta de 7 cifras, y fuimos tan cautelosos con ellos que inicialmente los incorporamos en marzo con recomendaciones basadas en reglas. No queríamos arriesgarnos a tener una mala experiencia de usuario con nuestros incipientes modelos de aprendizaje automático.

Más adelante, en abril, desarrollamos modelos de aprendizaje automático y realizamos extensas pruebas fuera de línea y una gran cantidad de control de calidad manual. Finalmente, confiamos en que nuestro modelo funcionaría bien y, luego, lo lanzamos y sucedieron dos cosas:

1. Llamada de emergencia: Recibimos una llamada telefónica de emergencia de ellos en unos minutos cuando ya estábamos perplejos con los resultados de las recomendaciones e intentábamos depurarlos. Teníamos recomendaciones sobre huevos de pascua en casi todas las páginas de su sitio web. ¡Resulta que habíamos configurado mal la identificación del modelo con el modelo que entrenamos en abril con sus datos de compras de Pascua! Cambiamos inmediatamente la identificación del modelo por la nueva y el problema se solucionó.
2. Aumento de la latencia p90: Resulta que utilizábamos las descripciones de los productos como características de nuestro modelo y que algunas de las descripciones eran muy largas, lo que aumentaba el tiempo de cálculo de las funciones. Esto no fue fácil de detectar durante nuestras pruebas offline porque la latencia del modelo parecía adecuada en la mayoría de los casos. Este problema no se solucionó de forma inmediata y, básicamente, tuvimos que volver al sistema basado en reglas hasta que solucionáramos las características y volviéramos a probar el modelo.

En general, esto se tradujo en muchos combates, mucha pérdida de credibilidad y casi pérdida de clientes. Tras una retrospectiva interna posterior, nos dimos cuenta de que, si bien el #1 era un error manual, era casi imposible detectar problemas como el #2 fuera de línea. Desde entonces, ¡hemos pasado al lado positivo de hacer lanzamientos oscuros!

¿Qué es Dark Launch?

El lanzamiento oscuro es una estrategia de implementación que te permite reproducir tu tráfico de producción real en el servicio recién implementado y descartar la respuesta antes de devolverla al usuario. Se comporta como si el servicio estuviera realmente activo, pero no afecta en absoluto a los usuarios. Esto le permite verificar que su nuevo servicio no tiene ningún error, tiene un rendimiento comparable o mejor en comparación con el servicio anterior y puede gestionar la carga de producción. Una vez que se haya verificado todo esto, es casi trivial cambiar al nuevo servicio de forma gradual. Así que, en cierto modo,

El lanzamiento oscuro es una forma ligera de lanzar tus servicios.

con una desventaja mínima y un enorme potencial alcista.

¿Cómo lanzar en la oscuridad?

El lanzamiento oscuro de sus servicios es una de las formas realistas de probar sus servicios y modelos en un sistema similar al de producción. Sin embargo, ejecutar un lanzamiento oscuro puede requerir una gran cantidad de preparación y madurez dentro de la organización desde el punto de vista del desarrollo, la supervisión y la infraestructura.

1. Adopte una arquitectura de microservicios: Es importante adoptar una arquitectura de microservicios basada en API para poder probar los nuevos servicios de forma incremental. La forma de ejecutar un lanzamiento oscuro consiste en reproducir una copia del tráfico de producción en un nuevo backend, lo que es mejor si el servicio de producción actual y el nuevo están disponibles como microservicio y la comunicación se realiza mediante una llamada REST o gRPC.
2. Bifurcación del tráfico: La mayoría de las veces, la interfaz de la aplicación es donde las personas hacen la bifurcación del tráfico, donde un porcentaje del tráfico de producción se dirige al nuevo servicio.
3. Llamadas asíncronas: Un principio general de las pruebas es que no deben afectar negativamente a su experiencia de producción real. Cuando se pone a oscuras, prácticamente se duplica el tráfico de producción, lo que puede duplicar la latencia, a menos que las llamadas de backend sean asincrónicas. Si tu servicio no es crítico desde el punto de vista de la latencia, fijar tiempos de espera razonables también puede ser una solución.
4. Infraestructura: Lo ideal es que su organización haya creado una infraestructura que sea fácil de escalar horizontalmente porque, a medida que aumenta el porcentaje de tráfico a su servicio de lanzamiento oscuro, también necesita escalar su infraestructura de forma gradual. En la mayoría de los casos, puede incluso tener sentido replicar todos los picos de tráfico y más allá para garantizar que el nuevo servicio escale realmente.
5. Explotación: Deberás registrar la solicitud y la respuesta de tus servicios de backend antiguos y nuevos para poder comparar la respuesta y el rendimiento del servicio. Si se trata de un modelo de aprendizaje automático, debes asegurarte de que las predicciones de tu modelo sean al menos tan buenas como las del modelo anterior. Esto requiere un registro exhaustivo.
6. Monitorización: Dark Launch es bastante inútil si no tienes buenos paneles de monitoreo e instrumentación en los que puedas comparar el tiempo de actividad, la latencia, la escalabilidad y la calidad de respuesta de tu nuevo servicio. Lo ideal es que esto ocurra en tiempo real para que las anomalías puedan detectarse y detectarse rápidamente.

¿Dark Launch es solo una sofisticada prueba offline?

Las pruebas fuera de línea le permiten comprobar la comportamiento de su sistema, normalmente de forma aislada. Rara vez le permitiría probar el sistema de extremo a extremo junto con el estado de sistema circundante con configuraciones realistas de tráfico y red, como la producción? Puedes lograr el 70% de todo esto mediante un registro meticuloso y pruebas fuera de línea muy complicadas, pero Dark Launch resulta ser un sistema mucho más simple. Esto se debe a que, de todos modos, terminas realizando la mayoría de los pasos anteriores para iniciar y monitorear un servicio con normalidad. Una vez que hayas realizado un lanzamiento oscuro exitoso, el lanzamiento real del nuevo servicio es casi trivial, por lo que la relación entre esfuerzo y recompensa vale la pena.

Hay un par de casos en los que esto podría ser difícil de justificar en la práctica, por ejemplo, si su servicio tiene estado o si realmente cambia la base de datos entonces hacer un lanzamiento oscuro es mucho más complicado. Según mi experiencia personal, garantizar la corrección del sistema se vuelve tan difícil que ¡es casi mejor conformarse con las pruebas fuera de línea que con un lanzamiento oscuro!

Si sientes más curiosidad por los lanzamientos oscuros o quieres compartir algo de tu experiencia, ¡ponte en contacto conmigo en nikunj@truefoundry.com!

True Foundry es un PaaS de implementación de aprendizaje automático sobre Kubernetes para acelerar los flujos de trabajo de los desarrolladores y, al mismo tiempo, permitirles una flexibilidad total a la hora de probar e implementar modelos, al tiempo que garantiza una seguridad y un control totales para el equipo de Infra. A través de nuestra plataforma, permitimos a los equipos de aprendizaje automático implementar y supervisar modela en 15 minutos con un 100% de confiabilidad, escalabilidad y la capacidad de revertirse en segundos, lo que les permite ahorrar costos y lanzar los modelos a la producción más rápido, lo que permite obtener un verdadero valor empresarial.