Movendo o YellowPages.com para Rails: Um caso de sucesso
Diante de tanta polêmica sobre o possível problema de escalabilidade do Rails, que seria a causa da instabilidade do Twitter, na RailsConf 2008 aconteceram várias apresentações tentando desmistificar o fato, mostrando maneiras de projetar aplicações que suportem milhares ou até milhões de requisições por dia.
Nada melhor que demonstrar isso e mais uma série de vantagens do Rails com um caso de uso real. Foi o que fez John Straw, arquiteto de software chefe da YellowPages.com, com a apresentação “Sobrevivendo a uma grande reescrita - Movendo YellowPages.com para Rails“. A minha intenção com este post é fazer uma tradução livre e resumida de seus tópicos.
Para quem não conhece, a YellowPages.com é o site das “páginas amarelas” dos Estados Unidos. O equivalente a Telelistas.net só que, acredito eu, com números mais expressivos: 23 milhões de visitantes por mês, 2 milhões de buscas por dia, mais de 48 milhões de requisições por dia, sendo mais de 1500 por segundo.
A chamada “Grande reescrita” começou no final de 2006. O sistema existente era escrito em Java, com 125.000 linhas de código, e mantido por consultores externos. Em apenas três meses de desenvolvimento, uma equipe de 20 pessoas (sendo apenas 5 desenvolvedores) portou o sistema para Rails, resultando em apenas 20.000 linhas código. O que impressiona é que a equipe havia estimado o prazo de 1 ano para a tarefa.
Mas por que decidiram reescrever o sistema?
O sistema do YellowPages já estava sem mudanças de design desde 2003 e, de acordo com testes de usabilidade, a experiência que o usuário tinha ao navegar não era satisfatória.
Além do design, a plataforma era difícil de manter, de aplicar técnicas de SEO e a implementação de sessões tornava o sistema difícil de escalar horizontalmente. O código estava cheio de remendos e não havia testes, fazendo da tarefa de adicionar novas funcionalidades algo muito trabalhoso.
Para resolver esses problemas e ainda criar uma arquitetura orientada a serviços, decidiram pelo RubyOnRails, usado em 90% da nova estrutura.
O que os levou a escolher Rails?
Um dos requisitos principais para a nova aplicação era proporcionar controle sobre a estrutura de URLs, principalmente para uso de SEO. Avaliando frameworks Java, nenhum apresentou um controle satisfatório. Logo, a escolha ficou entre Rails e Django.
Rails acabou levando a melhor sobre Django por que:
- Possuía uma melhor integração com testes automatizados;
- Era uma plataforma mais madura;
- Existia um caminho claro para C, caso necessitassem de mais performance;
- Os desenvolvedores se sentiam mais confortáveis e experientes.
Como ficou a arquitetura da aplicação?
Arquitetura da aplicação (clique para ampliar)
A figura acima mostra como ficou o design da aplicação, dividida em três camadas: web, serviço e busca, cada uma delas separada por um hardware de balanceamento de carga F5. O Apache também foi usado no gerenciamento dos processos mongrel, espalhados pela camada web e camada de serviço. Vejamos outras características da arquitetura:
- Comunicação HTTP em todos os níveis sem salvamento de estado (Stateless)
- A camada de serviço responde a REST e no formato JSON
- Memcached foi usado extensivamente na camada de serviço
- Ambiente de produção: 25 servidores para a aplicação + 2 servidores para banco de dados Oracle em cada data center.
Conseguiram a performance desejada?
Algumas metas de performance foram estabelecidas: A média de carregamento da página inicial deveria estar abaixo de 1 segundo, para páginas de busca a resposta deveria estar em menos de 4 segundos e suportar todo o tráfego sem quedas. Para isso, foram necessárias otimizações:
- Consideraram o uso de balanceamento de carga por hardware: F5 vs. HAProxy vs. Swiftiply vs. Localhost;
- Utilizaram mongrel_handlers para direcionar requisições da camada web para a de serviços sem passar pelo Rails;
- Desenvolveram uma biblioteca em C para organizar as respostas do cluster de buscas;
- Utilizaram Erubis para acelerar a renderização das views da camada web;
- Minimizaram o tamanho do JavaScript e mudaram de Prototype para jQuery.
A reescrita foi considerada um sucesso!
Depois de todo o trabalho, o novo sistema apresentou melhor desempenho que o sistema antigo em Java, com a vantagem de ser feito em Rails e dirigido por testes, o que o torna fácil de manter e de estender.
Para concluir a apresentação, John Straw destacou alguns itens considerados chaves para o sucesso do projeto:
- Equipe de desenvolvimento pequena e talentosa;
- Avaliação cuidadosa da tecnologia e escolha da plataforma compatível com a aplicação;
- Fácil comunicação entre os membros da equipe com diversos pontos de vista permitiu uma captura de requisitos sem formalismo;
- A regra “Não altere coisas que não são simples de decidir” preveniu a tomada de decisões que paralisavam o projeto;
- A criação de um site “beta” constantemente atualizado possibilitou uma visualização clara de progresso e direcionamento.
Veja mais detalhes sobre todo o processo de reescrita no PFD da apresentação de John Straw, disponível em http://en.oreilly.com/rails2008/public/asset/attachment/2765.
Fontes: RailsOnWave e BuildingWebApps.
Comments(3)


s caricaturas e tutoriais. Ele é ilustrador da revista 
com o tipo do projeto.Há pouco mais de um ano eu escrevia uma monografia para o curso de pós-graduação com o que era de mais avançado em termos de arquitetura distribuída através de webservices. Seu título? “
Faz alguns anos que ouvi falar de 




