Arquitetura do Twitter e Google Talk: Lições Aprendidas

The only real mistake is the one from which we learn nothing

– John Powell, The Secret of Staying in Love (1990), p. 85

Se você se interessa por arquitetura de software, mais precisamente, sobre questões de escalabilidade de sistemas e soluções (software), o blog Highscalability.com é leitura obrigatória.

Algum tempo atrás eu li no blog acima um post muito interessante sobre a arquitetura de software do Twitter. O título é “Scaling Twitter: Making Twitter 10000 Percent Faster” e além da discussão de como foi a solução de arquitetura que permitiu que o Twitter ficasse 1,000% mais rápido (o post é de 27/06/2009), descreve detalhes de linguagem, tecnologias, problemas e soluções, enfim, uma aula de como funciona o “coração” de software do Twitter (lá quase tudo é open-source).

Não vou reproduzir em detalhes aqui, a leitura é interessante e valem os 10 minutos. O que me chamou a atenção na época foram as lições aprendidas em cada um dos projetos, que o autor apresenta no final do texto.

Estas informações são valiosas, priceless! Como afirmou John Powell (citado acima): “O único erro de fato é aquele do qual nada aprendemos“.

Você tem uma reunião de “lessons learned” no seu projeto? Não? Você e sua equipe estão perdendo uma excelente oportunidade de evoluir, de aprender com os erros e acertos e, principalmente, de não repetir os mesmos erros. Um conselho de amigo: invista alguns minutos com o grupo ao final de cada etapa do projeto e documente todas as abordagem que deram certos e aquelas que não devem ser repetidas (erros).

Vamos ao que interessa. Abaixo, bem resumido, reproduzo algumas “lessons learned” de dois projetos famosos: Twitter e Google Talk.

Twitter: Lições Aprendidas

  1. Compartilhe idéias com outros (comunidade). Não se esconda e tente resolver o problema sozinho. Muitas pessoas brilhantes estão dispostas ajudar (você precisa pedir)
  2. Encare seu planejamento de escalabilidade como um plano de negócio. Reuna um time de experts para ajudar você
  3. Construa o que você precisa. O Twitter investiu muito tempo tentando soluções de terceiros que pareciam funcionar, mas não eram adequadas. Quando você mesmo desenvolve pelo menos você tem o controle e pode adicionar as funcionalidades que precisar
  4. Pense em mecanismos de detecção de usuários com intenção de “derrubar” o sistema. Coloque limites de utilização de forma que nenhum deles, isoladamente, coloque seu sistema “no chão”
  5. Não utilize o banco de dados como única alternativa de armazenamento. Nem tudo necessita de um “SQL join” gigante. Cache é a palavra mágica. Pense em formas alternativas de chegar no mesmo resultado, disponibilize dados em memória. Veja detalhes de como o Twitter fez isto neste link
  6. Faça com que sua aplicação seja “modularizada” ou “particionável” desde o início. Você vai entender porque quando precisar escalar a mesma
  7. Otimize o banco de dados: indexe tudo, faça um tunnig das queries, desnormalize
  8. Teste tudo. Twitter tem agora uma suite de testes completa de forma que se ocorrer um problema de cache eles detectam o problema antes da nova versão ser liberada
  9. Muitos problemas de performance não vem da linguagem, mas de como a aplicação foi projetada
  10. Transforme o serviço do seu website em uma API aberta. Grande parte do sucesso do Twitter é graças à sua API. Isto permite que a comunidade crie inúmeros serviços e aplicativos com os quais será difícil para os concorrentes copiarem. Amazon e Google também fazem isto. Você nunca poderá fazer todo o trabalho sozinho, a criatividade do seu time tem limites.

Google Talk: Lições Aprendidas

  1. Identifique corretamente o que deve ser mensurado. No caso do Google Talk, a questão principal não é saber quantos Instant Menssages (IMs) o sistema entrega ou quantos usuário ativos o sistema suporta. Por exemplo, uma parte complicada de um IM é como exibir o status de todos os usuários conectados. A conta não é linear: UsuáriosOnLine x ListaDeAmigos x MudançaDeStatusOnline. Uma grande lista de amigos (“buddy list”) é um problema a ser endereçado, a quantidade de IMs não é o problema
  2. Simulação em “ambiente real”. Testes em ambiente controlado são bons mas não dizem muita coisa. Simule mudança de status por semanas e meses
  3. Planejamento contra problemas operacionais. O que acontece quando os servidores são reinicializados e o sistema retorna com o cache vazio?
  4. Um sistema “escalável” é um sistema distribuído. O que o Google fez foi adicionar tolerância a falhas em todo componente do sistema. Tudo pode falhar.

One comment on “Arquitetura do Twitter e Google Talk: Lições Aprendidas

  1. [...] relativamente estável? Qual arquitetura que eles utilizam? Veja estes detalhes no post “Arquitetura do Twitter e Google Talk: Lições Aprendidas“. Categories: monitoring, web2.0 Tags: twitters Comments (0) Trackbacks (0) Leave a [...]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>