¿Cómo jugar el tráfico contra una red en la sombra?

Lo siento si esta es una pregunta nueva ...

He escuchado historias de que Netflix y Twitter pueden duplicar el tráfico web entre dos infraestructuras separadas: una es la autorizada / confiable que se remonta al usuario; y el otro es una infraestructura de 'sombra' o prueba que cree que está regresando al usuario pero no lo hace. El punto es probar la infraestructura secundaria con carga y sincronización de la vida real.

Estoy bastante seguro de que hay una palabra para describir esto, pero "puente" no parece ser el correcto, ni "reproducir".

¿Alguien puede ayudarme con cómo se llama esta técnica y / o qué herramientas se pueden utilizar para lograr esto?

Supongo que debería agregar que he escuchado sobre técnicas que efectivamente están 'reproduciendo registros', pero eso es realmente difícil de conseguir a velocidades / distribuciones reales.

Y, no estamos tratando de verificar la 'corrección' de la salida, sino solo asegurarnos de que no veamos errores / stacktraces / etc. en la nueva infraestructura.

Yo lo llamaría "prueba de carga mediante reproducción de sesión", personalmente. No conozco ningún término general para este tipo de técnica de prueba.

La estrategia básica que he visto empleada para este tipo de pruebas de carga es ingerir archivos de registro del sistema de producción y reproducirlos en un sistema de prueba.

Puede usar herramientas como JMeter o Apache Bench para reproducir solicitudes de archivos de registro. Si está buscando reproducir interacciones cliente / servidor muy complejas (con detalles de tiempo específicos basados ​​en la secuencia de registro original) con la esperanza de ejercer realmente las entrañas de su aplicación (buscando condiciones de carrera, errores relacionados con el tiempo, etc.) podría mire cómo escribir herramientas de prueba específicas de la aplicación que simulan clientes a escala.

No podrá capturar simplemente cargas de tráfico de red sin procesar y "reproducirlo" con cualquier protocolo basado en TCP o IP. Los números de secuencia TCP no coincidirán con el tráfico capturado original y no funcionará. Las capturas de la capa IP serán problemáticas porque sus clientes simulados deberán responder por la dirección IP del remitente capturado. Sería mejor capturar el tráfico más cerca de la capa 7 y usarlo para reproducir sesiones porque, de lo contrario, también está buscando escribir un simulador TCP. (Me imagino usando algo como tsharkextraer los datos de la capa 7 y el tiempo de una secuencia TCP y reproducir eso, por ejemplo).

Simplemente reproducir el tráfico de red simula la carga, pero no necesariamente captura los defectos. Su cliente simulado necesitaría recibir respuestas del servidor de prueba y analizarlas para verificar que sean correctas si desea probar con carga cualquier prueba de que la aplicación está respondiendo correctamente. Dado que su aplicación va a generar datos de respuesta dinámica, es poco probable que su cliente simulado pueda simplemente comparar la respuesta del servidor de prueba con la respuesta registrada del servidor de producción. Aquí es donde vas a escribir un arnés de prueba específico para tu aplicación y su salida.

Utiliza un servicio como BrowserMob que simula que muchas personas acceden simultáneamente a su sitio web a la vez. Estos servicios no reproducen el tráfico registrado, porque entonces faltaría el lado del cliente de la conversación. Por ejemplo, sus servidores estarían intentando enviar paquetes a computadoras en Internet que no esperan recibirlos. Pero lo que hacen estas compañías es estudiar los registros (generalmente a nivel de aplicación, no a nivel de paquete) y usar esa información para determinar en qué páginas están haciendo clic las personas, con qué frecuencia y en qué secuencia. Estos datos se utilizan para escribir scripts / macros que BrowserMob luego repite.

ApacheBench, como lo mencionó otro usuario, en realidad no se usa mucho en estos días. Fue más útil hace 10 años cuando solo tenía que averiguar qué tan rápido se podía entregar un documento HTML estático o JPEG bajo una carga pesada. No es muy diferente a un montón de personas haciendo clic en recargar, recargar, recargar una y otra vez en su navegador web. Necesita algo un poco más inteligente cuando prueba una aplicación web que tiene un flujo de trabajo más complejo.

No creo que pueda hacer esto en una capa de red, aunque posiblemente podría obtener un núcleo especializado para un equilibrador de carga de hardware para manejar el segundo servidor. Básicamente, el tráfico web (TCP) requerirá un acuse de recibo de cada paquete que se envía / recibe. Entonces, si un usuario envía un paquete a su red, se duplicaría tanto en su red de productos como en su red en la sombra. Los servidores en cada red responden, y el paquete del servidor prod se reenvía a su máquina, lo que le devuelve un acuse de recibo y ellos continúan su conversación. Sin embargo, si descarta el paquete de su servidor de sombra, no verá un reconocimiento. Por lo tanto, intentará reenviarlo y, al mismo tiempo, reducirá la velocidad de transmisión para toda la actividad de la red (esto se llama ventanas). Seguirá intentando enviarlo hasta que se agote el tiempo de espera, y la sesión se derriba. Honestamente, ni siquiera podrías completar un apretón de manos para establecer una conexión en primer lugar.

Lo más cercano que podría llegar a esto sería reenviar el paquete de sincronización original a su servidor de sombra y luego establecer la puerta de enlace predeterminada para esos cuadros como una ubicación inexistente. Luego, cada vez que un usuario intente establecer una conexión, obtendrá un servidor real en su red de productos y, al menos, enviará un paquete de sincronización a la red en la sombra. Maldición, ahora me tienes preguntándome cómo podrías hacer que esto funcione también :)

Pude preguntarle a @adrianco sobre esto en una reunión de Netflix.

La respuesta fue que escribieron su propia herramienta, que es básicamente un ServletFilter (lo siento, terminología específica de Java) que recrea la solicitud actual y realiza una invocación asíncrona de disparar y olvidar en un servidor de destino.

Los beneficios son:

• Patrones de tráfico del "mundo real" contra su infraestructura de prueba ("oscura")
• No es necesario grabar y luego reproducir

El inconveniente:

• Tengo que tener los hilos / ciclos de CPU de sobra en sus cajas de producción
• La latencia en su infraestructura de prueba podría respaldar y afectar sus cajas de producción