Apr
Provavelmente este texto não ira servir para você, isso até parece um insulto, mas não, é que dificilmente você ira precisar ser tão radical, quanto eu fui.
Algumas pessoas pensam que escalar software é ele conseguir no mesmo hardware suportar 1 a 1 milhão de transações, bem esse é o jeito errado de se pensar, softwares são complexos por natureza, você conseguirá escalar 1 milhão de transações no mesmo hardware, mas provavelmente ele não despenha algum papel importante na sua infra-estrutura / operação.
Escalonamento pode ocorrer a nÃvel software, a nÃvel hardware, a nÃvel dados, eles podem ser horizontalmente ou verticalmente, como um condomÃnio de casas. Você pode crescer em cima de um software para ele fazer mais por menos, mas também pode fazer ele fazer mais por mais hardware, e uma hora simplesmente isso vai acontecer. Em construção de software, como em um prédio, se você quer mais conforto, você precisa de mais espaço, não existe segredo, é o que acontece com escalonamento.
Não tem como colocar 1 milhão de transações no mesmo servidor, você precisa distribuir as cargas, é ai que os problemas do desenvolvedor começam, se ele não sabe o que está fazendo.
Toda boa empresa provavelmente tem um departamento de TI, como um gerente de InfraEstrutura, bem ele provavelmente vai fazer o que todo gerente sensato faria, irá colocar mais servidores e distribuir a carga, executando a profecia que coloquei anteriormente, o condomÃnio cresceu e precisou de mais espaço.
Bem, mas porque o sistema continua lento ? Porque quando acessamos uma página ela ainda tem problemas de performance, temos processamento sobrando, o nó 2, dificilmente está com carga, acima de 0.50, e o nó 1 está a mais de dias operando a 3.00 e o nó 3 misteriosamente tem picos de 20.0
Bem a culpa dessa história provavelmente é muito mais embaixo, antes de falar o que acontece, vamos revisar um pouco sobre Dados e WEB
Uma página WEB, se comporta tendo normalmente os seguintes recursos:
- Conteúdo Estático
- Conteúdo Estático dependente de sessão para ser exibido
- Conteúdo Dinâmico
- Conteúdo Dinâmico dependente de sessão para ser exibido
Bem até aqui não temos nenhuma novidade, mas agora entraremos em assunto mais delicado, como falei anteriormente, além de processar a página, precisamos operar os dados, e bem eles precisam ser escalados, um dos maiores problemas de uma linguagem que se tornou famosa nos últimos 2 anos sofre exatamente na comunicação com Banco de Dados.
Após a invenção dos Bancos Relacionais, todo mundo opera assim acreditando ser a maior maravilha do séc.
Sim eles são, mas trouxeram, consigo um problema, são lentos para pesquisas com concorrência de alguns milhares, e porque isso ? Bem é simples, todo algoritmo tem um custo, e o custo de se colocar dados relacionais é esse. Pense assim: Se você otimiza demais para pesquisa, onde fica caro ? Na inserção, logo, se você otimiza demais para inserção, onde agora estará o problema ? Na procura, e bem, e quando queremos escalar, o que temos de fazer ?
O Famoso, DIVIDIR PARA CONQUISTAR. Isto é o que o pessoal de mainframe fazem há anos, vamos há um caso de logging em STI (Single Table Intherance),.
Você executa o log das operações assim que elas são feitas ? Se o faz, já está criando um gargalo para o seu banco. Sim, um gargalo, ele tem de ficar inserindo na tabelas e varrendo todo o sistema relacional que ela representa, ou seja, além de inserir, tem de checar se o usuário realmente existe no sistema, o mesmo ocorra se existe um relacionamento com o tipo da operação.
Junto a toda essa operação ele tem de servir as pesquisas e inserção dos dados mais nobres, como o seus usuários, e dados de negócio.
Não que o log não seja importante, mas ele é menos nobre, foi isso que eu quis dizer quando falei em escalonamento a nÃvel dados.
A importância para aplicação em detrimento de seus dados, o que é mais importante, manter alguns milhares de usuários, ou manter o log das operações deles em tempo real ?
Acredito que o 1 seja mais importante, então ao invés de gravar tudo diretamente no banco, que tal: gravar em arquivo, ou simplesmente no log em texto dos seus servidores, o código do usuário juntamente com a URL da operação e depois processar em linguagem que tenham Regular Expression , rápidas, e processar a cada 40 min. ? Sim, Dividir para Conquistar, assim ao invés de sobrecarregar o banco de dados, você pode escolher o momento que ele estiver mais tranqüilo para executar a tarefa. Outra opção, seria ter um outro banco de dados, sabidamente que sincroniza de tempos em tempos com o banco de dados principal.
Bem a idéia é simples: PRIORIZE SOMENTE AS REGRAS DE NEGÓCIOS e quebre todo o sistema para executar assÃncrono, quando você estiver feito isto, você estará apto a escalar, mas ainda falta medir o quanto cada processo lhe custa dentro de sua infra-estrutura, você já entendeu, que execução massivas são ruins, ou seja, que executar tudo toda hora, não é vantajoso, mas ainda tem de saber quanto pode executar os processos, isso você adquire somente estudando seus processos, não existe uma formula mágica que lhe fará escalar, existe muito sabedoria sobre o sistema e processos envolvidos, e como eles funcionam por si só.
Uma boa medida, é o uso de caches, existem empresas que fazem cacheamento reverso: Akamai, BigIP, Amazon Cloud, é o tal CDN, Content Delivery Network, outra medida é prover cacheamento interno, counters, muito usado, podem ficar espalhados pelas tabelas, e triggers os atualizam, se ainda assim é intenso o uso do Banco de Dados, uma boa solução é partir para memcached, ou então cache em arquivos com tempo de expiração, imagine que se você cachear, sua Home por 1 minuto e ela tem 400 mil acesso, será apenas 1 Acesso ao banco de dados ocorrendo para servir os 400 mil, e o resto será o conteúdo estático sendo jogado, apesar dele ser dinâmico.
É assim que funciona uma página do tipo UOL, IG, Globo, a página é dinâmica, mas é gerada para ficar estática, com isso o uso de servidores mais leves, que o Apache, como LightdHttp e Ngnix, Não que o Apache seja lento, mas para super concorrência, ele carece de ser pesado, pois cada conexão representa um consumo de memória, e processamento.
Enfim técnicas, um fato que atento, quando você usa cache, e precisa atualizar, você tem de ter uma boa ferramenta de controle, para não perder o controle sobre o sistema e a sincronização dos objetos/collections/hash na memória.
Outro boa técnica é usar motores de pesquisa de indexação para intermédio aos banco de dados, um ótimo é o Lucene, implementado por exemplo dentro do Hibernate, e por conseqüência dentros dos EJB do Java EE.