Produção

Bem, ontem ocorreu o primeiro tech talk 2.0, digo isso pois a Web 2.0 está em onda no mercado de TI com todo o seu discurso colaborativo. Pois bem, ontem o tema do tech talk foi o famigerado memcache, e a palestra foi apresentada de forma colaborativa. Entre os palestrantes estavam:

Guilherme - Equipe WebMedia
Arthur Gasnner - Equipe Aplicativos
Marco Bicudo - Equipe Webmedia
Gustavo Soares (o que vos escreve :D) - Equipe Produção

Achei legal ter 3 áreas diferentes falando sobre um mesmo tema, pois cada um pôde falar a sua experiência com o memcache, o que na minha opinião agregou mais valor e tornou este tech talk em especial mais abrangente.

Uma “idéia”, que vou comentá-la logo logo, já havia me ocorrido um tempo atrás, e hoje vindo para o trabalho e com o tech talk de ontem na cabeça pensei novamente nela… O lance é o seguinte… a equipe de Produção já tentou algumas vezes implantar um cluster nos diversos
applications servers que usamos em producao (weblogic, jboss, tomcat) para replicar sessão
http e com isso termos o balanceamento setado para least conn, ao invés de hash. Vale ressaltar, que nossas experiências com cluster não foram muito boas, especificamente para aplicações com um fluxo intenso de informações, ou seja, bastante acessadas.

Resumidamente… o balanceamento least conn faz com que o request enviado por um usuário cada hora caia em um servidor diferente, distribuindo melhor a carga entre os diversos servidores membros de um grupo. Já o balanceamento em hash, faz com que o request de um usuário sempre caia no mesmo servidor que ele caiu inicialmente, ou seja, se tivermos 3 servidores: A, B e C e o meu primeiro request cair no servidor A, ele irá sempre cair no servidor A, salvo claro, algum indisponibilidade neste servidor. O balanceamento em hash nao é muito bom, pois em algumas situações podemos ter um servidor com um número muito grande de sessões enquanto que o(s) outro(s) servidor(es) está(ão) com um número baixo de sessões http.

Após a explicação do que é least conn e o que é hash, vamos a minha idéia (que ainda nao sei se é viável, ou se trará algum ganho…. é apenas uma idéia). Poderíamos instalar instâncias de memcache nos servidores de backend, e a aplicação poderia salvar a sessão http do usuário no memcache, fazendo uma distribuição das diversas sessões entres os memcache. Só para lembrar, e conforme foi explicado ontem, com o memcache nao há replicação dos dados, as informações ficam distribuídas entre as diversas instâncias do memcache. Desta forma, a persistência de sessão seria garantida pelo memcache, ao invés do cluster habilitado no app server, seja ele jboss ou weblogic, e poderìamos ter o balanceamento configurado para least conn.

Quanto a esta “solução”, restam algumas dúvidas:

- Como o memcache iria se comportar nestas condições?
- É viável?
- E a performance, como seria?
- Seria fácil ligar/desligar o cluster, caso precisássemos?
- Qual o tamanho típico de uma sessão http?
- Haveria realmente uma melhor distribuição da carga entre os servidores?

Well… é isto.. ainda nao tive tempo de testá-la, e pelo andar da carruagem nao terei tempo tão cedo… mas fica aqui o registro da minha proposta… e quem sabe arrumo um tempo para testar.. ou alguma boa alma para me ajudar???

Comentários serão benvindos…