“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
- 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)
- Encare seu planejamento de escalabilidade como um plano de negócio. Reuna um time de experts para ajudar você
- 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
- 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”
- 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
- 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
- Otimize o banco de dados: indexe tudo, faça um tunnig das queries, desnormalize
- 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
- Muitos problemas de performance não vem da linguagem, mas de como a aplicação foi projetada
- 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
- 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
- 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
- Planejamento contra problemas operacionais. O que acontece quando os servidores são reinicializados e o sistema retorna com o cache vazio?
- 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.
Quem afirmou isto foi Bob Sutor, um dos principais executivos da “big blue” na área de Linux e Open-Source.
