Come riprodurre il traffico su una rete shadow?

Scusa se questa è una domanda newb ...

Ho sentito storie di Netflix e Twitter in grado di duplicare il traffico web tra due infrastrutture separate: una è quella autorevole / affidabile che risale all'utente; e l'altra è una 'ombra' o infrastruttura di test che pensa che stia tornando all'utente ma non lo fa. Il punto è testare l'infrastruttura secondaria con carichi e tempistiche di vita reale.

Sono abbastanza sicuro che ci sia una parola per descriverlo, ma "bridge" non sembra essere quello giusto, né "replay".

Qualcuno può aiutarmi con come si chiama questa tecnica e / o quali strumenti possono essere utilizzati per raggiungere questo obiettivo?

Immagino che dovrei aggiungere di aver sentito parlare di tecniche che stanno effettivamente "riproducendo i registri", ma è davvero difficile ottenere a velocità / distribuzioni reali.

Inoltre, non stiamo provando a verificare la "correttezza" dell'output, ma assicuriamoci di non vedere errori / stacktraces / ecc. Nella nuova infrastruttura.

Lo chiamerei "test di carico tramite replay di sessione", personalmente. Non conosco nessun termine generico per questo tipo di tecnica di test.

La strategia di base che ho visto impiegata per questo tipo di test di carico è quella di ingerire i file di registro dal sistema di produzione e riprodurli su un sistema di test.

È possibile utilizzare strumenti come JMeter o Apache Bench per riprodurre le richieste dai file di registro. Se stai cercando di riprodurre interazioni client / server molto complesse (con dettagli di temporizzazione specifici basati sul flusso di log originale) nella speranza di esercitare davvero le viscere della tua applicazione (alla ricerca di condizioni di gara, bug relativi ai tempi, ecc.) Potresti guardare a scrivere strumenti di test specifici dell'applicazione che simulano i clienti su vasta scala.

Non sarai in grado di catturare semplicemente carichi di traffico di rete non elaborato e "riprodurlo" con qualsiasi protocollo basato su TCP o IP. I numeri di sequenza TCP non corrisponderanno al traffico acquisito originale e non funzionerà. Le acquisizioni a livello IP saranno problematiche perché i client simulati dovranno rispondere per l'indirizzo IP del mittente acquisito. Faresti meglio a catturare il traffico più vicino al layer 7 e utilizzarlo per riprodurre le sessioni perché, altrimenti, stai anche cercando di scrivere un simulatore TCP. (Potrei immaginare di usare qualcosa di simile tsharkper sottrarre i dati e i tempi del layer 7 da un flusso TCP e riprodurlo, ad esempio.)

La semplice riproduzione del traffico di rete simula il carico ma non rileva necessariamente i difetti. Il client simulato dovrebbe ricevere le risposte dal server di prova e analizzarle per correttezza se si desidera testare il carico di qualsiasi test a cui l'applicazione sta rispondendo correttamente. Poiché l'applicazione genererà dati di risposta dinamici, è improbabile che il client simulato possa semplicemente confrontare la risposta del server di prova con la risposta registrata dal server di produzione. Qui è dove inizierai a scrivere un cablaggio di test specifico per la tua applicazione e il suo output.

Utilizzi un servizio come BrowserMob che simula molte persone che accedono contemporaneamente al tuo sito Web contemporaneamente. Questi servizi non riproducono il traffico registrato, perché in tal caso mancherebbe il lato client della conversazione. Ad esempio, i server tenterebbero di inviare pacchetti a computer su Internet che non si aspettano di riceverli. Ma ciò che fanno queste aziende è studiare i registri (generalmente a livello di applicazione, non a livello di pacchetto) e utilizzare tali informazioni per capire su quali pagine le persone fanno clic, con quale frequenza e in quale sequenza. Questi dati vengono utilizzati per scrivere script / macro che BrowserMob ripete.

ApacheBench, come menzionato da un altro utente, in questi giorni non è molto utilizzato. È stato più utile 10 anni fa quando dovevi solo capire quanto velocemente un documento HTML statico o JPEG può essere servito sotto un carico pesante. Non è molto diverso da un gruppo di persone che fanno clic su Ricarica, Ricarica, Ricarica più e più volte sul proprio browser Web. Per testare un'app Web che ha un flusso di lavoro più complesso è necessario qualcosa di più intelligente.

Non penso che potresti farlo a livello di rete, anche se potresti ottenere un kernel specializzato per un bilanciamento del carico hardware per gestire il secondo server. Fondamentalmente il traffico web (TCP) richiederà un riconoscimento di ciascun pacchetto inviato / ricevuto. Quindi, se un utente invia un pacchetto alla tua rete, verrebbe duplicato sia sulla tua rete di prodotti, sia sulla tua rete ombra. I server di ciascuna rete rispondono e il pacchetto del server prod viene inoltrato di nuovo alla macchina che restituisce un riconoscimento e continuano allegramente la loro conversazione. Tuttavia, se si rilascia il pacchetto del server shadow, non verrà visualizzato un riconoscimento. Quindi, proverà a rinviarlo e allo stesso tempo rallenterà le sue velocità di trasmissione per tutte le attività di rete (questo si chiama windowing). Continuerà a riprovare a inviarlo fino al timeout, e la sessione è stata demolita. Onestamente, non saresti nemmeno in grado di completare una stretta di mano per stabilire una connessione in primo luogo.

Per quanto riguarda il più vicino possibile, si dovrebbe inoltrare il pacchetto di sincronizzazione originale al server shadow e quindi impostare il gateway predefinito per tali caselle come posizione inesistente. Quindi, ogni volta che un utente prova a stabilire una connessione, ottiene un vero server sulla tua rete di prodotti e, per lo meno, invii un pacchetto syn alla rete shadow. Accidenti, ora mi stai chiedendo come potresti far funzionare anche questo :)

Sono stato in grado di chiedere a @adrianco di questo in un incontro di Netflix.

La risposta è stata che hanno scritto il proprio strumento, che è fondamentalmente un ServletFilter (scusate, terminologia specifica di Java) che ricrea la richiesta corrente ed esegue una chiamata asincrona di tipo "ignora e dimentica" su un server di destinazione.

I vantaggi sono:

• Modelli di traffico "reali" contro la tua infrastruttura di prova ("oscura")
• Non è necessario registrare e quindi riprodurre

Lo svantaggio:

• Devo avere i cicli di thread / CPU da risparmiare sulle scatole di produzione
• La latenza sull'infrastruttura di test potrebbe eseguire il backup e influire sulle caselle di produzione