Como reproduzir o tráfego em uma rede sombra?

Desculpe se esta é uma nova pergunta ...

Ouvi histórias de Netflix e Twitter capazes de duplicar o tráfego da web entre duas infraestruturas separadas: uma é a autorizada / confiável que retorna ao usuário; e o outro é uma 'sombra' ou infraestrutura de teste que pensa que está retornando ao usuário, mas não o faz. O objetivo é testar a infraestrutura secundária com carga e tempo da vida real.

Tenho certeza de que há uma palavra para descrever isso, mas 'bridge' não parece ser o caminho certo nem 'replay'.

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

Acho que devo acrescentar que ouvi falar de técnicas que efetivamente 'reproduzem logs', mas isso é realmente difícil de obter em velocidades / distribuições reais.

E não estamos tentando verificar a 'correção' da saída, mas apenas verifique se não vemos erros / traços de pilha / etc na nova infraestrutura.

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

A estratégia básica que eu 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ê estiver tentando reproduzir interações cliente / servidor muito complexas (com detalhes específicos de tempo com base no fluxo de logs original) na esperança de realmente exercitar as entranhas do seu aplicativo (procurando condições de corrida, bugs relacionados a tempo, etc.), observe a criação de ferramentas de teste específicas de aplicativos que simulam clientes em escala.

Você não poderá simplesmente capturar cargas de barco do tráfego bruto da rede e "reproduzi-lo" com qualquer protocolo baseado em TCP ou IP. Os números de sequência TCP não correspondem ao tráfego capturado original e não funcionam. As capturas na camada IP serão problemáticas porque seus clientes simulados precisarão responder pelo endereço IP do remetente capturado. Seria melhor capturar o tráfego mais perto da camada 7 e usá-lo para reproduzir sessões porque, caso contrário, você também está pensando em escrever um simulador de TCP. (Eu poderia imaginar o uso de algo como tsharkextrair os dados e o tempo da camada 7 de um fluxo TCP e reproduzir isso, por exemplo.)

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

Você usa um serviço como o BrowserMob, que simula muitas pessoas acessando simultaneamente o 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 tentariam enviar pacotes para computadores na Internet que não esperavam recebê-los. Mas o que essas empresas fazem é estudar os logs (geralmente no nível do aplicativo, e não no 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 gravar scripts / macros que o BrowserMob repete.

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

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 para lidar com o segundo servidor. Basicamente, o tráfego da web (TCP) exigirá um reconhecimento de cada pacote enviado / recebido. Portanto, se um usuário enviar um pacote para sua rede, ele será duplicado na sua rede de produtos e na sua rede de sombra. Os servidores em cada rede respondem e o pacote do servidor prod é encaminhado de volta para sua máquina, que retrocede uma confirmação e eles mantêm alegremente a conversa. No entanto, se você soltar o pacote do servidor sombra, ele não será reconhecido. Portanto, ele tentará reenviá-lo e, ao mesmo tempo, diminuirá sua velocidade de transmissão para todas as atividades da rede (isso é chamado de janelas). Ele continuará tentando enviá-lo até atingir o tempo limite, e a sessão é interrompida. Honestamente, você nem seria capaz de concluir um aperto de mão para estabelecer uma conexão em primeiro lugar.

O mais próximo que você poderia chegar disso seria encaminhar o pacote de sincronização original para o servidor shadow e, em seguida, definir o gateway padrão para essas caixas como um local inexistente. Então, sempre que um usuário tentasse configurar uma conexão, obteria um servidor real na sua rede de produtos e, no mínimo, enviaria um pacote syn para a rede de sombra. Droga, agora você está me perguntando como você poderia fazer isso funcionar também :)

Pude perguntar à @adrianco sobre isso em um encontro da Netflix.

A resposta foi que eles criaram sua própria ferramenta, que é basicamente um ServletFilter (desculpe, terminologia específica de Java) que recria a solicitação atual e faz uma chamada assíncrona de acionar e esquecer em um servidor de destino.

Os benefícios são:

• Padrões de tráfego do 'mundo real' em relação à sua infraestrutura de teste ("escura")
• Não há necessidade de gravar e reproduzir novamente

A desvantagem:

• Você precisa ter os ciclos de threads / CPU disponíveis nas suas caixas de produção
• A latência na sua infraestrutura de teste pode fazer backup e afetar suas caixas de produção