Archive for the ‘Escalabilidade’ Tag

Otimizando a performance com diferentes estratégias de cache

De todas as maneiras existentes de se otimizar a performance de um software, acredito que a utilização de um cache intensivo é aquela que produz os melhores resultados, principalmente quando falamos de aplicações web. A utilização de uma estrutura de cache eficiente, aumenta significativamente a capacidade de processamento de requisições, uma vez que reduzimos a pressão sobre os gargalos da aplicação, sejam eles relacionados ao IO em disco, a utilização de memória ou a utilização de CPU. Para cada tipo de gargalo, e para cada tipo de aplicação, podemos utilizar uma estratégia de cache diferente, atuando diretamente nos pontos que limitam o desempenho do sistema.

Em uma aplicação web, temos três tipos básicos de cache: o cache no cliente, o cache no web server e o cache na aplicação. O cache no cliente é o método mais simples de redução de carga nos servidores web, principalmente quando falamos de sites simples, e com grande quantidade de conteúdo estático. Imagine, por exemplo, um site que possui muitas imagens e textos estáticos. Se não utilizarmos nenhuma política de cache, a cada request realizado, todos os componentes serão enviados do servidor para o cliente, mesmo que este cliente já tenha visualizado a página diversas vezes. Todas as imagens que já foram transferidas para ele, e que não sofreram alteração, serão novamente enviadas, algo que poderia ser facilmente evitado se o cliente tivesse armazenado previamente este conteúdo estático. Para que o cliente armazene este conteúdo, o servidor deve mandar, juntamente com a resposta, a informação de que aquele conteúdo deve ser cacheado, e por quanto tempo ele será válido no cache. Para isto, existem dois módulos do Apache que permitem uma excelente flexibilidade na definição de qual conteúdo será cacheado e o tempo de expiração do mesmo. São eles: mod_headers e mod_expires.

ExpiresByType text/html “access plus 2 hours”
ExpiresByType image/gif “modification plus 3 minutes”

Algumas vezes, apesar de termos conteúdo estático, a utilização de cache no cliente não faz muito sentido. Imaginem um site de download de músicas, onde temos diversos servidores web servindo conteúdo estático a partir de um repositório central de arquivos (um storage comum). Se vários usuários diferentes tentam realizar o download de um determinado arquivo, a cada requisição o web server irá ler o mesmo arquivo do storage central, gerando uma carga desnecessária no backend. O mesmo pode ser aplicado se no backend temos um servidor de aplicação, onde o conteúdo gerado se altera com pouca freqüência ou com uma periodicidade definida. Neste caso, devemos utilizar uma estratégia de cache no web server, seja no próprio servidor, seja criando uma camada de cache entre ele e o usuário.

Existem diversos modos de se implementar um cache no servidor web, seja utilizando um Squid na frente, seja utilizando um appliance dedicado. Porém, a maneira que eu acho mais eficiente é utilizando o mod_cache. O mod_cache é um módulo do Apache específico para cache no web server, capaz de armazenar conteúdo em disco ou em memória, de acordo com as necessidades da aplicação. Por estar integrado ao Apache, sua configuração é extremamente simples e não existem problemas de compatibilidade, etc. Além disso, ele é bastante confiável (quando utilizado com o Apache 2.2.x) e é Open-Source, sendo suportado por uma comunidade bastante ativa. (para quem quiser saber mais sobre o mod_cache).

Em algumas situações específicas estas duas abordagens de cache não são suficientes, sendo necessário a utilização de uma terceira: o cache da aplicação. Existem casos onde a camada de aplicação necessita de consultar serviços remotos, ou mesmo bancos de dados, para gerar uma determinada saída. Nestes casos, seria razoável que fosse armazenada a resposta de uma determinada consulta, desde que ela possa ser reaproveitada para o processamento de outras requisições. Desta forma, aumentamos a velocidade de resposta, o que bastante interessante do ponto de vista do usuário. Assim, para realizar este tipo de cache, podemos, por exemplo, utilizar o memcached, que é uma excelente ferramenta de cache de dados em memória.

Em suma, temos diferentes tipos de cache para diferentes tipo de problemas, sendo que a utilização de uma política de cache correta garante um ganho substancial de desempenho (podemos ter ganhos de até 70%). Quanto mais intensiva e bem estruturada for a utilização de cache, melhor será a utilização dos recursos para o que realmente importa e menor será o tempo de resposta para o usuário.

Advertisements

Scaling Down

Quando falamos de arquiteturas escaláveis, a primeira coisa que nos vem a mente é ter um projeto de hardware/software que permita o aumento da capacidade de processamento de acordo com o aumento da demanda. Isto significa que o esforço para atender uma demanda crescente deve ser o mínimo possível, limitando-se, na maioria das vezes, apenas em investimento em infra-estrutura de hardware. Entretanto, o conceito de escalabilidade é muito mais amplo que isto, e não deve ser limitado às condições de crescimento da demanda, mas também deve considerar uma redução significativa desta. O problema é que a grande maioria das pessoas que projetam arquiteturas estão preocupadas apenas com o scaling up e se esquecem totalmente do scaling down, e isto pode ser bastante arriscado também. Theo Schlossnagle, no seu livro Scalable Internet Architectures, nos dá inúmeros exemplos de empresas que, por não possuirem uma arquitetura totalmente escalável, simplesmente faliram durante o estouro da bolha da Internet por não serem capazes de cortar seus custos operacionais.

O problema de scaling down geralmente é mais comum em empresas de médio e grande porte, uma vez que a demanda inicial já é bastante grande, o que exige uma arquitetura inicial mais robusta e complexa. Porém, todo software tem um ciclo de vida, e existe uma probabilidade grande de que após alguns anos a demanda torne-se cada vez menor. Neste ponto, quando a demanda atual passa a ser menor que a inicial, muitas vezes a estrutura torna-se super dimensionada, e os custos de operação não são mais justificáveis. Além disso, nem sempre é interessante, do ponto de vista de posicionamento de negócios, tirar o software do ar. É aí que a necessidade de reduzir a estrutura vira uma questão de sobrevivência (sendo um pouco radical).

Você pode estar se perguntando agora: Se eu tenho uma arquitetura que é facilmente “escalável para cima”, porque ela não seria “escalável para baixo”? Quais são as características necessárias para um scaling down? Na verdade, em qualquer arquitetura existe um limite de quão simples e barata ela pode ser. O princípio geral da escalabilidade nos diz que quanto melhor for o isolamento entre as diferentes camadas do software, mais fácil é expandir a capacidade dos gargalos existentes nele. Para um scale down eficiente, também é fundamental que os componentes que foram isolados sejam construídos de forma uniforme, e rodem em plataformas compatíveis, de modo que todos os componentes possam coexistir em um único ambiente, que, no caso mais extremo, seria uma máquina Google Like. Esta é a visão ideal de escalabilidade: ter um software (inclusive com suas dependências), que seja capaz de rodar em uma máquina de supermercado, e que também possa funcionar perfeitamente em 50 servidores Dual Quad Core em cluster, e que a quantidade de informação processada varie linearmente de acordo com o aumento da capacidade.

Para que isto seja viável, é fundamental considerar os requisitos mínimos de cada componente, avaliando a compatibilidade destes requisitos com os demais componentes. Por exemplo, se um determinado componente só roda em Solaris, e o outro só em Windows, a coexistência dos dois em um único hardware fica comprometida. Atualmente, ainda temos a saída da virtualização, mas pode ser que nem todos os componentes rodem sem problemas em ambientes virtualizados. Além disso, requisitos mínimos de memória, disco e processamento irão delimitar o quão simples poderá ser a estrutura.

Resumindo, temos todos que nos preocupar não somente com o que fazer quando as coisas estão se expandindo, mas também é muito importante ter um plano claro de o que pode ser feito para enxugar a estrutura, direcionando os recursos para pontos mais prioritários. Quando você estiver projetando uma arquitetura, lembre-se de que em algum momento o scaling down pode ser a única alternativa para manter um produto no ar.