Há alguns anos atrás, participei de um projeto de um sistema que tinha uma previsão de alto número de usuários simultaneos pela rede. Sugeri ao líder do projeto que fizesse um grupo de servidores de aplicação, fazendo balanceamento de carga entre eles, ou seja, montar um conjunto de dois ou mais computadores rodando a mesma aplicação, que dividissem o trabalho de atender àqueles usuários do serviço.
O líder do projeto não adotou a sugestão, argumentando que "tínhamos um servidor parrudo", com muita memória e vários processadores, capaz de suportar tamanha demanda. Contra-argumentei que, apesar de toda a indubitável capacidade do servidor, ele era um só. E se falhasse, o sistema ficaria fora do ar.
Mas, infelizmente, o líder do projeto não tinha visão orientada à otimização. E disse que o que deveríamos fazer era preparar um servidor de contingência. A visão dele era assim: "Temos um servidor que aguenta o tranco. Mas, no caso de não aguentar, colocamos outro, igual, para assumir a questão".
O resultado da história foi que o sistema foi posto no ar dessa forma. E o tal servidor "parrudo", à medida que o número de usuários aumentava, foi ficando lento, lento.... Até que chegou uma hora que o sistema caiu. E foi aquela correria! Inicialmente reinicializou-se o servidor várias vezes, mas os usuários retornavam (obviamente) e o sistema caía de novo.
Ligou-se a contingência. Ficou assim: O primeiro servidor entrava no ar. Os usuários acessavam o sistema, até que ele caía. Aí os próximos usuários eram direcionados ao segundo servidor, que também entupia e caía.
O tal líder do projeto culpou a tudo e a todos. Disse que o sistema operacional não prestava, reclamou do software do servidor de aplicação, da linguagem em que foi desenvolvido o sistema, maldisse o fabricante dos processadores do servidor, enfim, criou uma porção de desculpas para a coisa não ter funcionado. Mas em nenhum momento cogitou a hipótese de estar errado.
Sua vontade era reescrever o sistema em outra linguagem, funcionando sob outro sistema operacional, mas permanecendo o ambiente de um único servidor com outro de contingência.
Ele tinha o apoio da empresa, que confiava na sua competência técnica. E realmente ele tinha muita competência técnica, inegavelmente. Mas lhe faltava algo de igual importância: Maturidade.
Bem, o sistema ia pro ar uma vez por ano. Durante dois anos permaneceu assim. Funcionava mal, os usuários tinham uma péssima experiência e havia um alto nível de estresse.
Finalmente, o líder do projeto decidiu começar a buscar otimizar o sistema e isso promoveu uma certa melhora. Mas ele ainda não havia sido convencido da necessidade de dois ou mais servidores.
Em um belo dia de sol, mudaram o líder do projeto. Eu permaneci no grupo de desenvolvedores do sistema. Após uma longa conversa com a nova líder do projeto, consegui convencê-la da importância de ter um modelo com dois ou mais servidores de aplicação, ao invés do modelo de servidor+contingência.
Infelizmente a empresa foi contra. Então, junto com um colega de equipe, montamos um cluster de servidores de aplicação, utilizando máquinas velhas do nosso setor, abandonadas, cacarecos mesmo, mas fazendo balanceamento de carga. Fizemos testes então, com softwares que simulam acessos simultâneos de usuários, sobre nosso cluster de cacarecos. E... adivinhe? A estabilidade era maior do que em uma situação de um único "servidor parrudo".
Os dados eram incontestáveis e foi o argumento que convenceu a empresa a adotar tal procedimento. Hoje em dia todo sistema da empresa que precise de alto desempenho e disponibilidade utiliza mais de um servidor, em cluster (usamos várias máquinas virtuais, fazendo balanceamento).
Eis um caso em que quantidade é melhor do que qualidade.
No próximo post aprofundarei este tema, mostrando os tipos de balanceamento de carga possíveis de implementar. Não perca!
Nenhum comentário:
Postar um comentário