Dias atrás fomos desafiados por um evento intermitente e até então desconhecido. O time de desenvolvedores em questão, alegava que utilizando um sistema web via navegador, ao realizar um refresh (F5) a requisição para uma API que possuía o webserver Apache como frontend pendurava e não mais respondia. Entretanto se apontavam a API para um managedserver* do WebLogic respondia corretamente. Isso impactava diretamente no sistema, degradando a imagem que o usuário tem deste sistema.
Com integração entre os times, conhecimento específico e experiência dos envolvidos a causa foi identificada, nosso vilão ‘KeepAlive’ desativado, e mais um problema resolvido.
Inúmeros eventos nos levaram a estressar e aplicarmos testes com a finalidade de isolarmos o que era causa e o que era sintoma.
"Mas claro o KeepAlive...", devem estar pensando, até que pudéssemos chegar ao vilão, dezenas de análises, isolamentos e mudanças foram testadas, tais como atualizar versão do Apache, recompilar outros módulos do MPM (worker, prefork e event), e até outro módulo como ModProxy, por fim outro WebServer Nginx.
Este é o tipo de problema que adoramos ter todos os dias, desafios com alto grau de complexidade, para que possamos aprimorar e executar métodos de gestão de incidentes.
Uma pausa para refletir…
A carreira do profissional de middleware, vale a pena? Ainda existe demanda?
Enquanto a tendência dos entusiastas da tecnologia da informação é explorar e falar cada vez mais de soluções e métodos intangíveis, focando-se em discursos elegantes com palavras atuais como cloud*, Big Data*, machine learning*, entre outras tecnologias e métodos que em muitos casos ainda não são uma realidade dentro de sua organização, de nada adiantará saber escalar, balancear recursos, ou trabalhar com soluções inovadoras em cliques do mouse, ou classes requisitando SDKs se o ambiente que sustentas e atua não está pronto para este tipo de uso, é instável e preso a um presente regulado por ausência de investimento em inovação.
Quando atuamos em um cenário deste, o generalista, profissional desejado por diversas organizações, não fará diferença. Pois serão erros, alertas e incidentes de tecnologias específicas, para estes casos somente o especialista será valioso e poderá dar uma resposta imediata.
Nos preocupa quando nos deparamos com profissionais focados em inovação, por exemplo, que sequer tem uma boa base de rede e sistema operacional.
E o profissional de middleware? Bem, este com uma base boa, conforme mencionado acima, sempre terá lugar quando todos fogem, quando escalar não resolve o problema, é quando resolve utiliza-se a um alto custo por aplicações e configurações má dimensionadas, sejam em uma infraestrutura pública ou privada.
O mercado exigirá do profissional de middleware uma boa adaptação às novas tecnologias e linguagens emergentes, mas assim como o administrador de banco de dados, não será nestes 10 ou 20 anos que ele verá o seu fim. Pois onde houver um servidor de aplicação como backend, um webserver como frontend, um cache ou balanceador de carga, existirá a necessidade de um profissional de middleware.
Entenda que ser um especialista em middleware, não faz de vocês ignorantes em outras áreas, mas especialistas atentos às inovações e que tem ciência das novas funcionalidades disponíveis no mercado.
Vamos então ao detalhamento técnico do problema com o KeepAlive?
Unindo os relatos dos usuários e desenvolvedores que mencionaram que após clicar duas vezes no mesmo item do sistema o mesmo pendurava, avaliamos quais logs poderiam nos apoiar no Apache e não identificamos informações relevantes, ainda que tenhamos passado a severidade do log dos módulos e core do Apache para debug.
O sintoma observado neste momento eram as conexões presas gerando WAIT nos servers do Apache, até o momento na versão 2.2 utilizando como MPM o Worker.
Após nós analisamos os logs dos containers Java, que processavam as requisições vindas do webserver tanto pelo sistema quanto para a API, começamos a evoluir, pois os managedservers* nos davam mais informações:
<20 17h57min17s="" brt=""> <[ServletContext@448764570[app:app module:app path:null spec-version:3.0]] Root cause of ServletException.
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "http://192.168.1.245:85/api/rest/publico/usuarioCliente/findUsuarioById":Response had end of stream after 0 bytes; nested exception is java.io.EOFException: Response had end of stream after 0 bytes
Diante do cenário presente, buscamos após a análise o isolamento de componentes afetados, iniciando o isolamento por arquitetura, após soluções tecnológicas e por fim seus módulos.
Iniciamos os trabalhos em um ambiente controlado e sem concorrência onde a simulação foi viável, com backups realizados para que pudéssemos voltar ao marco 0.
Primeiramente eliminamos possíveis causas como rede, ajustes de sistema operacional e parametrização de Sysctl e Limits. Outro item isolado foi a criação de novos VirtualHosts, com novas portas, porque os atuais estavam usando outro modulo que gostariamos de isolar do problema que era o rewrite_module*. Após atualizamos a versão do Apache 2.2 para 2.4, sem sucesso na operação alternamos entre módulos MPM disponíveis, atualização do módulo de integração com o Weblogic, por fim substituição pelo ModProxy. Como tentativa de eliminação substituímos o Apache por Nginx.
Nenhuma alteração surtiu efeito a ponto de eliminar os sintomas.
Trabalhar em equipe não é apenas trabalhar em conjunto é preciso compartilhamento. Os resultados nunca são alcançados apenas por uma pessoa, é preciso compartilhar com o outro para chegar ao objetivo final.
Quando um colega não consegue avançar, o mesmo pede apoio a outro não por ter menos conhecimento, mas para que ganhe com isso uma nova percepção de atuação sobre o evento.
Então realizamos uma comparação de ambientes e análise de boas práticas. Com isso e em função do comportamento do ambiente analisado que culminou com este diagnóstico, desativamos o KeepAlive do ambiente isolado, testamos e juntamente com o time de desenvolvimento e analista de testes estressamos o sistema para garantir que não fosse um falso-positivo.
O KeepAlive do Apache permite o reuso das conexões com o webserver, aumenta a performance e reduz o consumo de recursos. Entretanto o sistema não trabalha com um conteúdo estático volumoso, logo, por serem conexões dinâmicas o seu efeito era prejudicial e gerava por vezes erros HTTP 408 e CLOSE_WAIT na camada TCP do sistema operacional do webserver.
Logo, tenha em mente que o KeepAlive é uma configuração do Apache que torna reutilizáveis as requisições, entretanto existem relatos de que quando ativado pode prejudicar requisições com o método POST, que se aplica ao nosso caso.
Legendas:
* managedserver : Instância do Weblogic gerenciadas por um Domain
* cloud : Cloud computing ou computação em nuvem é a entrega da computação como um serviço ao invés de um produto
* Big Data : Big data é o termo que descreve o imenso volume de dados – estruturados e não estruturados.
* machine leaning : A aprendizagem automática ou aprendizado de máquina (em inglês: "machine learning") é um sub-campo da ciência da computação que evoluiu do estudo de reconhecimento de padrões e da teoria da aprendizagem computacional em inteligência artificial.
* rewrite_module : Módulo do Apache que utiliza um mecanismo baseado em regras de reescrita (baseadas em um parser de expressões regulares).
Basicamente o módulo permite a reescrita de URL's _on the fly.
Referências:
Apresentação dos autores:
*Gabriel Prestes, formado em Gestão da Tecnologia da Informação, arquiteto de middleware da ilegra com experiência de mais de 8 anos em suítes de middleware Oracle e RedHat. É um entusiasta de carros antigos.
*Junior Amaral, formado em Tecnologia da Informação, Database Administrator (Oracle) e middleware da ilegra com experiência de mais de 15 anos em banco Oracle e 5 anos em suítes de middleware Oracle e RedHat. É um apaixonado por aviação.
