Como jogar o tráfego contra uma rede de sombra?

Question

Desculpe se esta é uma questão newb ...

Eu ouvi histórias de Netflix e Twitter sendo capazes de duplicar o tráfego da Web entre duas infraestruturas separadas: uma é a autoridade / confiável que retorna ao usuário; e o outro é uma 'sombra' ou uma infraestrutura de teste que pensa estar retornando ao usuário, mas não está. O objetivo é testar a infraestrutura secundária na carga e no tempo real.

Tenho certeza de que há uma palavra para descrever isso, mas "bridge" não parece ser a correta, nem "replay".

Alguém pode me ajudar com o que essa técnica é chamada e / ou quais ferramentas podem ser usadas para realizar isso?

Acho que devo acrescentar que ouvi falar de técnicas que estão efetivamente "reproduzindo logs", mas é realmente difícil obter velocidades / distribuições reais.

E não estamos tentando verificar a "correção" da saída, mas apenas certifique-se de que não vemos erros / stacktraces / etc na nova infraestrutura.

    

Answer 1

Eu chamaria isso de "teste de carga por repetição de sessão", pessoalmente. Eu não sei de nenhum termo simples para esse tipo de técnica de teste.

A estratégia básica que vi empregada para esse tipo de teste de carga é ingerir arquivos de log do sistema de produção e reproduzi-los em um sistema de teste.

Você pode usar ferramentas como JMeter ou Apache Bench para reproduzir solicitações de arquivos de log. Se você está olhando para reproduzir interações cliente / servidor muito complexas (com detalhes de tempo específicos baseados no fluxo de logs original) na esperança de realmente exercitar as entranhas do seu aplicativo (procurando por condições de corrida, erros relacionados ao tempo, etc.) procure escrever ferramentas de teste específicas de aplicativos que simulem clientes em escala.

Você não será capaz de simplesmente capturar cargas de tráfego de rede bruto e "reproduzi-lo" com qualquer protocolo baseado em TCP ou IP. Os números de sequência do TCP não corresponderão ao tráfego capturado original e não funcionará. As capturas da camada IP serão problemáticas porque seus clientes simulados precisarão responder pelo endereço IP do remetente capturado. Seria melhor você capturar o tráfego mais próximo da camada 7 e usá-lo para reproduzir sessões porque, caso contrário, você também está tentando criar um simulador de TCP. (Eu poderia imaginar usar algo como tshark para extrair os dados e o tempo da camada 7 de um fluxo TCP e reproduzi-los, por exemplo).

Simplesmente repetir o tráfego da rede simula a carga, mas não necessariamente captura defeitos. Seu cliente simulado precisaria receber respostas do servidor de teste e analisá-las para correção se você quisesse testar qualquer teste que o aplicativo está respondendo adequadamente. Como seu aplicativo irá gerar dados de resposta dinâmica, é improvável que seu cliente simulado simplesmente compare a resposta do servidor de teste à resposta registrada do servidor de produção. É aqui que você vai começar a escrever um equipamento de teste específico para seu aplicativo e sua saída.

    

Answer 2

Você usa um serviço como BrowserMob , que simula muitas pessoas acessando simultaneamente seu site de uma só vez. Esses serviços não reproduzem o tráfego registrado, porque você estaria perdendo o lado do cliente da conversa. Por exemplo, seus servidores estariam tentando enviar pacotes para computadores na Internet que não esperam recebê-los. Mas o que essas empresas fazem é estudar os logs (geralmente em nível de aplicativo, não em nível de pacote) e usar essas informações para descobrir em quais páginas as pessoas estão clicando, com que frequência e em que sequência. Esses dados são usados para escrever scripts / macros que o BrowserMob repete.

ApacheBench, como mencionado por outro usuário, não é muito usado hoje em dia. Foi mais útil 10 anos atrás, quando você só precisava descobrir a rapidez com que um documento HTML estático ou JPEG pode ser exibido sob uma carga pesada. Não é muito diferente do que um monte de pessoas clicando recarregar, recarregar, recarregar uma e outra vez em seu navegador. Você precisa de algo um pouco mais inteligente ao testar um aplicativo da Web que tenha um fluxo de trabalho mais complexo.

    

Answer 3

Eu não acho que você poderia fazer isso em uma camada de rede, embora você possa obter um kernel especializado para um balanceador de carga de hardware manipular o segundo servidor. Basicamente, o tráfego da web (TCP) exigirá uma confirmação de cada pacote enviado / recebido. Portanto, se um usuário enviar um pacote à sua rede, ele será duplicado para a rede do produto e para a rede de sombra. Os servidores em cada rede respondem, e o pacote do servidor prod é encaminhado de volta para sua máquina, o que dispara uma confirmação, e eles continuam a conversa alegremente. No entanto, se você soltar o pacote do servidor de sombra, ele não verá uma confirmação. Então, ele tentará reenviá-lo e, ao mesmo tempo, reduzirá a velocidade de transmissão de toda a atividade da rede (isso é chamado de janelamento). Ele continuará tentando enviar para expirar e a sessão será interrompida. Honestamente, você nem conseguiria completar um aperto de mão para estabelecer uma conexão em primeiro lugar.

Sobre o mais próximo que você poderia chegar a isso seria encaminhando o pacote de sincronização original para o seu servidor de sombra e, em seguida, defina o gateway padrão para as caixas como algum local inexistente. Então, sempre que um usuário tentasse estabelecer uma conexão, receberia um servidor real em sua rede de produtos e, no mínimo, você enviaria um pacote syn para a rede shadow. Droga, agora você me pergunta como poderia fazer isso funcionar também:)

    

Answer 4

Eu pude perguntar @adrianco sobre isso em um encontro da Netflix.

A resposta foi que eles escreveram sua própria ferramenta, que é basicamente um ServletFilter (desculpem, terminologia específica de Java) que recria o pedido atual e faz uma invocação de ignorar e esquecer assíncrona em um servidor de destino.

Os benefícios são:

• Padrões de tráfego do 'mundo real' contra sua infraestrutura de teste ("escuro")
• Não é necessário gravar e reproduzir novamente

A desvantagem:

• Precisa ter os ciclos de threads / CPU de sobra em suas caixas de produção
• A latência em sua infraestrutura de teste pode fazer backup e afetar suas caixas de produção