Compartilhar estas soluções é uma das maneiras de agradecer à comunidade de desenvolvedores por usarmos software livre, difundir o conhecimento criado na empresa e melhorar nossa própria ferramenta.

Bancos NoSQL, entende-se “Not only SQL”, surgiram da necessidade de escalar bancos de dados relacionais com propriedades ACID em projetos web de alta disponibilidade que operam em larga escala. Suas principais características são alta performance, escalabilidade, fácil replicação e suporte a dados estruturados.

Clique aqui e continue lendo este texto.

Quando se trabalha numa empresa como a boo-box, é preciso ter uma equipe capaz de desenvolver soluções tecnológicas extraordinárias, em um espaço de tempo extraordinário.

Nos últimos meses, a boo-box experimentou um crescimento sensacional:

Como podem ver, o aumento de exibição de publicidade deu um salto de 85% no último mês!
Para aguentarmos o ritmo, os sistemas tiveram que ser revistos e reestruturados.

Antes de uma explicação mais detalhada, vou resumir nossa abordagem: monitore ao máximo, use cache em tudo o que puder, e cuide bem do seu banco de dados :)

Explicando em detalhes

Para se destacar como um player de publicidade online, é preciso seguir alguns princípios:

1. Velocidade: ninguém vai ficar esperando para ver um anúncio carregar.
2. Escalabilidade: viralizações, crescimentos acelerados etc. Se sua aplicação não for altamente escalável, melhor mudar de atividade, ou abrir mão de dormir todos os dias :)
3. Monitoramentos: monitore tudo! E automatize os monitoramentos sempre que possível.
4. Processos: crie, e siga, processos para os diversos tipos de situações.

Com isso em mente, nossos Ninjas fizeram um refactoring no coração do sistema: na
Camada de Aplicação.

O objetivo era esgotar ao máximo a capacidade das linguagens e plataformas nginx + Ruby + Merb + MySQL, com algoritmos e topologias mais poderosos.

Portanto, mudamos a lógica, sincronicidade e cacheamento de partes-chave. Em comparação com o post anterior “A infraestrutura de servidores Web do Sistema boo-box“, alguns pontos da topologia foram alterados:

Além disso, implementamos metodologias de monitoramento que nos fizeram ter maior controle sobre a aplicação.

Nomes das máquinas e versões de releases

Conforme explicamos no post anterior sobre nossa infraestrutura, nossas máquinas são batizadas em homenagem a personagens do anime Dragon Ball Z, como Korin, Kami, Cell, Raditz, Trunks, Goku, Gohan entre outros.

Ultimamente, começamos também a identificar nossos releases, que levam nomes de filmes clássicos. Os dois primeiros releases foram:

1. Metropolis, do clássico de ficção científica de 1927 de Fritz Lang;
2. Hannibal, filme de 2001 bastante conhecido.

Cluster Application

Essa camada é composta pelo conjunto de servidores que processam nossas regras de negócio. São eles que decidem quais anúncios serão exibidos nas vitrines, o que acontece quando há um clique e o que fazer com os dados de um novo publisher cadastrado no sistema.

Essa foi a camada com maiores modificações. O refactoring priorizou quatro pontos essenciais:

1. Lógica: otimizamos o algoritmo de processamento, tornando-o muito mais eficiente para esta nova fase do sistema.
2. Memcached: aumentamos em 80% a utilização de memcached. Sempre respeitando as regras de negócio, foi possível cachear grande quantidade de informações de forma a otimizar o tempo de resposta. Essa alteração afetou diretamente a camada de banco de dados de aplicação, pois fez com que a aplicação consultasse consideravalmente menos esse banco de dados.
3. Gravação de logs: tornamos a gravação de logs assíncrona. Isso quer dizer que a camada de aplicação não fala mais diretamente com nosso MySQL de logs. Ele coloca numa fila (Beanstalkd) que, posteriormente, será consumida por um programa Ruby que, por sua vez, será responsável por armazenar no banco de dados.
4. Número de Workers: fizemos alguns benchmarks que nos indicaram o número ideal de workers. Antes, usávamos uma lógica complexa que media a capacidade total de processamento de cada máquina para chegar no número ideal que era, à época, muito alto. Porém, nossos benchmarks indicaram que esse número não deve ser muito grande. Quanto mais workers, mais os núcleos (cores) das máquinas ficarão ocupados e, portanto, mais lento será o processamento individual deles. Porém, se esse número for pequeno demais, o loadbalancer poderá não achar workers disponíveis, mesmo que eles processem rapidamente. No nosso caso, o número ideal está entre 20 e 30 workers.

Testamos também a utilização do método run_later do MERB. Porém, chegamos à conclusão que teríamos maior poder de gerenciamento usando o Beanstalkd. Além disso, o Beanstalkd possui uma funcionalidade de persistência.

Cluster Log e BI

Todas as requisições feitas a boo-box são gravadas em nosso Cluster de Log. Vitrines visualizadas, cliques em anúncios, ações efetuadas em sites de parceiros, tudo é registrado.

Como disse no começo do post: tome cuidado com seu banco de dados! Ele poderá tirar suas noites de sono :)

Nessa camada, foi importante unir tunning com processamento assíncrono:

1. Tunning: fique atento às configurações de key_buffer, max_connections, table_cache, thread_concurrency, innodb_buffer_pool_size e, claro, à sua estrutura de índices nas tabelas.
   Além disso, implementamos um sistema de particionamento nativo do MySQL que otimiza a estrutura de armazenamento no HD (MySQL Reference Manual – Chapter 18. Partitioning).
2. Processamento assíncrono: como explicado no Cluster Application, a aplicação não fala mais diretamente com os banco de dados de logs, mas sim com uma fila. Dessa forma, um não dependerá mais do outro, melhorando, e muito, o tempo de resposta de nossas vitrines.

Essas otimizações também afetaram nosso BI, responsável por processar todos os dados recebidos para serem utilizados posteriormente (relatórios, métricas, projeções etc).

Cluster data source

Essa camada é responsável por armazenar informações específicas do sistema.

Com todas as otimizações feitas nas outras camadas (principalmente o aumento de utilização de Memcached), não foi necessário realizar grandes modificações aqui. Pelo contrário: reduzimos a quantidade de máquinas dessa camada, diminuindo o número de servidores.

Cluster products cache

Grande parte dos anúncios exibidos nas vitrines boo-box são produtos ofertados por e-commmerces parceiros. Como as informações dos produtos não precisam ser mantidas ao longo do tempo, fazemos um cache temporário dos dados.

Com as alterações no Cluster Application, foi possível diminuir consideravelmente a quantidade de máquinas dessa camada.

Lembre-se: sempre que utilizar CouchDB ou MySQL, é importante ter máquinas de armazenamento rápido, para uma melhor performance de I/O. Portanto, Cloud Computing pode não ser uma boa opção para essa camada.

Load balancer e Static Files

São as máquinas que recebem as requisições dos usuários e direcionam a carga para um dos servidores de aplicação.

No webserver nginx, usávamos o algoritmo round-robin. Com o aumento de escala, essa lógica se mostrou não ser a melhor pra nós, pois quando algum de nossos servidores (workers) demorava a responder, comprometia todas as requisições que ali entravam. Dessa forma, aplicamos o módulo Fair, que permite ao nginx enviar requisições para as máquinas de aplicação que estiverem com menor processamento no momento.

Monitor

Para garantir a saúde dos sistemas, é importante monitorar ao máximo as diversas camadas e aplicativos envolvidos. Porém, isso não requer apenas ferramentas. É importante implantar processos manuais e automáticos.

Atualmente, utilizamos ferramentas como Munin, Monit, Webalizer, Pingdom além de ferramentas próprias que fazem esse papel.

Realizamos checks horários, diários, semanais e mensais, que nos geram dados para tomadas de decisão de mudanças ou manutenção da nossa estrutura.

É importante observar que a automatização de processos é a meta ideal, porém não deve ser impeditivo. Muitos técnicos e gestores de infraestrutura negligenciam as práticas de monitoramento por “não terem automatizado o processo”, gerando muito mais problemas do que soluções. Se necessário, implemente processos manuais constantes. A disciplina é sua maior aliada.

Conclusão

Construir um sistema de alta disponibilidade não requer apenas soluções tecnológicas.

Práticas de gestão serão um diferencial necessário na solução final. Sem se perder no excesso de burocracia, a criação de processos e práticas de trabalho bem definidas farão com que a equipe possa unir soluções de longo prazo (implementação lenta), com soluções de curto prazo (implementação veloz), sabendo, portanto, lidar com todos os tipos de problemas que um sistema dessa complexidade irá criar.

Quem faz isso acontecer

Desde março, quando fizemos o lançamento do nosso Sistema de Publicidade Para Mídias Sociais, temos tido uma grande demanda de anunciantes e de novos programas de afiliados (e-commerce), principalmente graças à nossa presença constante nos meios de comunicação voltados para as agências.

Vitrine Publicitária

Meio & Mensagem

Propaganda e Marketing

Para darmos vazão a essa demanda temos mantido um esforço contínuo de expansão da rede de sites, o que consequentemente exige mais da nossa infra-estrutura, do nosso suporte e atendimento e da nossa área comercial e administrativa, resumindo, exige mais dos ninjas da boo-box. O que fez com que aumentássemos nossa equipe, se ao final do ano passado estávamos em 5, agora somos 12!

Para tantos ninjas assim, precisávamos de um novo “dojo”, que abrigasse a todos. Façam  reverência antes de entrar e sejam bem-vindos à nova boo-land ;)

Tche Ruggi – Jerry Batista – mad_ruggi@hotmail.com – 11-8210-9567

Tche Ruggi – Jerry Batista – mad_ruggi@hotmail.com – 11-8210-9567

Tche Ruggi – Jerry Batista – mad_ruggi@hotmail.com – 11-8210-9567

Nos últimos anos uma série de padrões de arquitetura de softwares web se consolidaram e foram popularizados em frameworksque 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 Livrede 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.

boo!

Essa semana disponibilizamos uma atualização do plugin boo-boxfy para WordPress.

Nesse update nós colocamos o botão monetize de volta (ele havia sido retirado nas últimas versões), corrigimos alguns bugs e otimizamos o carregamento de grande parte dos arquivos para os servidores da boo-box.

A vantagem disso é a diminuição do consumo de tráfego no servidor de nossos usuários e uma manutenção mais acessível aos ninjas boo-box, sem a necessidade de updates constantes em seu painel.

Pro usuário a maior alteração dessa versão é a volta do botão monetizar no modo de edição HTML do WordPress. Tomamos essa decisão após um feedback de nosso usuário Borbs (judao.com.br), que estava adaptado a esse modo de edição de posts em código HTML e sentiu falta de uma maneira pra inserir vitrines em seu conteúdo

A boo-box escuta seus usúarios :D . Mande seu feedback para nós via Twitter digitando #boobox em seu post ou via formulário de contato do nosso site.

1. 
   borbs @marcogomes #Boo-Box Mimimi, o botão “monetize” não tá mais aparecendo pra mim! =/ 17 Apr 2009 from web
2. 
   marcogomes @borbs agora o botão “monetize” virou um botão “boo-box” na barra do WordPress, veja http://migre.me/wNn #boobox Atualize seu boo-boxfy ;) 17 Apr 2009 from TweetDeck in reply to borbs
3. 
   borbs @marcogomes Bom, então temos um problema, pq eu não uso o editor visual… E aí não aparece. =/ #Boo-Box 17 Apr 2009 from web
4. 
   borbs #BooBox ainda não mostra o botão de “Monetize!” pra mim, que NÃO uso o editor visual do WordPress… Plugin FAIL. =/ 22 Apr 2009 from web
5. 
   borbs #BooBox liberou nova versão do Boo-Boxfy, com botãozinho “Monetize” pra quem não usa o editor visual… \o/ 23 Apr 2009 from web

— this quote was brought to you by quoteurl

O boo-boxfy é compatível com a versão 2.6 ou superior do WordPress. Baixe já!

Nos últimos dias vários Publishers nos perguntaram sobre instabilidades no sistema boo-box. Sempre respondemos individualmente, mas devido ao grande número de contatos resolvemos publicar este anúncio pra compartilhar o momento com nossos usuários.

Graças a todos vocês a boo-box vem crescendo continuamente desde o lançamento. Após um ano e meio atingimos um volume de tráfego impressionante e chegou a hora de mudarmos a maneira de carregar ofertas dos e-commerces. É por conta destes ajustes que o sistema boo-box tem tido períodos de instabilidade.

Já estamos finalizando as melhorias, nos próximos dias o sistema terá mais robustez e nossa capacidade de continuar inovando será ainda maior .o/