A infraestrutura de servidores Web do Sistema boo-box
Nos últimos anos uma série de padrões de arquitetura de softwares web se consolidaram e foram popularizados em frameworks que facilitam o desenvolvimento e a manutenção destes sistemas. Ao mesmo tempo, servidores tiveram o custo reduzido e o acesso facilitado. Criar um projeto web se tornou mais simples, ágil e barato, mas se ele prosperar será preciso lidar com um velho desafio: escalabilidade.
A boo-box passou por esse desafio e hoje possui uma infraestrutura em camadas, capaz de escalar horizontalmente e que hoje tem robustez pra servir milhares de requisições por minuto. Neste post iremos apresentar algumas soluções usadas atualmente pra garantir boa performance do Sistema de Publicidade Para Mídias Sociais, como Ruby, MERB, CouchDB, Thin, Nginx, Beanstalkd.
A infra boo-box
Nossa infraestrutura é uma combinação de softwares Open Source consolidados há anos, como MySQL, com outros mais recentes e pouco usados, que em geral consomem menos recursos, são mais simples ou apenas mais adequados à situação.
É importante salientar que este texto reflete a situação da infraestrutura atual (maio de 2009). A taxa de novos Publishers associados ao Sistema e crescimento de visitação dos Publishers já associados nos leva a alterar semanalmente a estrutura de servidores, adicionando novas máquinas ou modificando componentes da aplicação.
Identificação dos servidores
Nomear servidores sempre é uma decisão difícil para o time de desenvolvedores, alguns usam nomes de planetas, elementos da tabela periódica, nomes de letras gregas. Nós usamos nomes de personagens do anime Dragon Ball Z.
Static Files
Arquivos estáticos são os que não dependem de processamento do servidor, como imagens, CSSs, JavaScripts
. Na estrutura boo-box eles ficam em um subdomínio que aponta diretamente para um servidor dedicado, diminuindo a carga dos nossos load balancers.
Os arquivos estáticos são carregados previamente para a memória RAM, melhorando o tempo de resposta do Sistema. Esta máquina roda o servidor HTTP nginx.
Load Balancers
São as máquinas que recebem as requisições dos usuários e direcionam a carga para um dos servidores de apliçação. Na infra boo-box há dois load balancers, ambos associados ao DNS para boo-box.com
O load balancer precisa responder muito rapidamente, por isso ele não processa regras de negócio. Cada um dos servers roda o servidor HTTP nginx.
Cluster de aplicação
O cluster de aplicação é composto pelo conjunto de servidores que processam nossas regras de negócio. São eles que decidem que anúncio será exibido na vitrine, o que acontece quando há um clique, o que fazer com os dados de novo Publisher cadastrado no Sistema.
Cada server roda aproximadamente 100 instâncias do framework Ruby MERB com o servidor HTTP Thin (não, nós não usamos RubyOnRails :).
Cluster de banco de dados
Quando uma informação precisa ser gravada em nosso sistema, como novo Publisher cadastrado, alteração nas preferências, ou exclusão de anunciante, esses dados são guardados em nosso banco de dados.
O cluster de banco de dados contém a máquina Vegeta (Master), que recebe as informações a serem gravadas no banco, e máquinas secundárias Bulma e Ubb (Slave) de onde os servers de aplicação lêem os dados.
Como notado por um leitor do blog, o nome do personagem é Uub, mas o ninja que batizou o server precisou digitar o nome usando os pés porque nossos braços estavam estendidos pra cima energizando uma Genki Dama, digitar com os pés é difícil, ele errou a tecla e o nome server e ficou Ubb mesmo :)
Dividir escrita e leitura em diferentes servidores foi uma das mais eficientes atitudes que tomamos nos últimos meses pra melhorar performance e uptime do Sistema boo-box.
Este cluster roda um banco MySQL, dividido entre os servidores segundo escrita e leitura.
Um caso real de uma empresa contribuindo com a comunidade de Software Livre :)
Usamos o Sequel como ORM na comunicação entre aplicação e banco de dados. Quando precisamos replicar o banco, gerando a estrutura de Master e Slave, o Sequel não conseguia ler do Slave, por mais que fizéssemos tudo conforme a documentação.
Entramos em contato com os desenvolvedores do ORM no canal de IRC e, após algumas horas de testes, resolvemos o problema em conjunto.
Este é apenas o mais recente dos casos, nós já contribuimos com a comunidade de Software Livre de diferentes maneiras, fazemos isso porque temos consiência que nossa tecnologia é fruto do Open Source.
Cluster de log do Sistema
Todas as ações ocorridas em nosso Sistema são gravadas no log do Sistema. Vitrines visualizadas, cliques em anúncios, ações efetuadas em sites de parceiros, tudo fica no log.
Periodicamente processamos o log raw (cru), geramos estatísticas e fazemos um backup. Com isso liberamos o log raw para receber mais dados sem perder as informações do passado e mantendo uma boa performance no Sistema.
Usamos o Analogger como componente de log, porém, questões de performance e escalabilidade fez com que buscássemos outra solução. Atualmente o log do Sistema está sendo migrado para estrutura MySQL, e é dividido em máquinas Master (escrita) e Slave (leitura).
Cache de produtos
A maior parte dos anúncios exibidos nas vitrines boo-box são produtos ofertados por e-commmerces. Como as informações dos produtos não precisam ser mantidas ao longo do tempo fazemos um cache temporário dos dados.
O cache confere robustez ao Sistema, que continua funcionando mesmo que o e-commerce demore pra responder ou saia do ar.
Nossa estrutura de cache de produtos é formada por dois componentes principais:
Fila
Usamos Beanstalkd como serviço de fila para requisições de produtos. Cada vitrine boo-box tem tags associadas, cada nova tag ainda não cacheada é inseria nesta fila que será consumida nos próximos segundos, não atrapalhando o fluxo de funcionamento da aplicação.
Há um serviço independente que consome a fila, indo nos e-commerces procurar pelos produtos relacionados com cada tag e colocando os dados nas máquinas de cache.
Cluster de cache de produtos
Cada servidor que armazena dados de produtos roda CouchDB, um banco de dados de documentos JSON.
O principal recurso consumido por estas máquinas é espaço em HD, lotamos centenas de gigabytes em poucos dias, principalmente por conta da heterogeneidade das ofertas exibidas no Sistema boo-box, são milhões de produtos diferentes.
O resultado
Nas últimas semanas o tempo de resposta e uptime do Sistema boo-box melhorou visivelmente por conta das soluções acima apresentadas, resultado do trabalho e experiência dos ninjas.
Se você tem alguma crítica, dúvida ou sugestão, estamos sempre dispostos a ouvir, a caixa de comentários é pra você :)
Post escrito por Marco Gomes e Mauricio Maia.
