Sou um desenvolvedor web de desenvolvimento com um site executando dois ec2.smalls atrás de um balanceador de carga na AWS.
Recentemente, vimos de 3 a 4 solicitações por segundo derrubarem o site de nossos clientes.
O site estava fora do ar e não voltava após várias reinicializações do servidor e verificações de log de erros em busca de scripts que pudessem estar causando o problema, mesmo que nenhuma alteração tenha sido enviada recentemente.
Depois de ativar o log do balanceador de carga, vi que milhares de solicitações para uma única página vinham de um endereço IP.
Encaminhamos a solicitação do balanceador de carga para o servidor que trata a solicitação usando X-forwarded-for e bloqueamos o IP usando uma regra .htaccess.
Durante a comunicação com a TI dos clientes, eles foram notificados de que o endereço IP responsável pela enxurrada de solicitações era na verdade uma das máquinas internas da empresa.
A máquina responsável foi reinicializada remotamente e todas as solicitações foram interrompidas. O site voltou a ficar online.
A explicação oficial para isso foi “o computador estava pirando”.
É possível que um navegador da Web ou uma máquina Windows faça de 3 a 4 solicitações por segundo para uma página da Web com carga balanceada e a desative por mais de 5 horas?
Aqui está como eram as solicitações:
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
Responder1
Claro que é possível - embora dependa de vários fatores:
1) Parece que o aplicativo do lado do servidor está tendo problemas de simultaneidade. Pode valer a pena verificar se foram os servidores de aplicativos que foram o gargalo, ou se foi o upstream, como os bancos de dados, e os servidores de aplicativos ficaram sem memória devido à configuração do Apache não liberar os threads com rapidez suficiente. Se fossem os servidores de aplicativos, talvez valesse a pena fazer alguns ajustes - gire uma máquina idêntica fora do ELB e use o JMeter para lançar alguma carga nela e descobrir os gargalos.
Se fosse o banco de dados, você poderá usar memcache/elasticache (já que parece que você está recuperando um objeto específico) para armazenar em cache as consultas reais. Dessa forma, as conexões do banco de dados respondem rapidamente, o Apache pode responder rapidamente e eliminar threads em vez de preencher o pool de memória da máquina do aplicativo.
Se você estiver realmente se sentindo vulnerável, poderá colocar o Varnish upstream para armazenar em cache as solicitações em um TTL de 1 a 5s para evitar uma grande inundação de solicitações. Mas tenha cuidado, pois o VCL é implacável e pode causar grandes problemas e dores (envenenamento/vazamento de cache).
2) Quanto à própria máquina “sujeito”. Obviamente, poderia ter sido comprometido – definitivamente deveria ser investigado. Vou deixar você decidir se o cara de TI é honesto ou não - isso está fora do domínio da falha do servidor.
Supondo que não tenha sido comprometido, pode ter sido algum código javascript incorreto - se você fizer atualizações de pesquisa e de alguma forma um parâmetro de tempo for modificado, ele poderá muito bem começar a enviar muitas solicitações por segundo. Da mesma forma, o JS pode ter se comportado bem, mas a pessoa pode ter 25 guias abertas e ter ido para casa à noite - se cada uma estiver enviando 1 solicitação a cada 5 segundos, isso significa 5req/segundo.