Evan Weaver, Engenheiro Líder do Time de Serviços no Twitter, que está trabalhando essencialmente na otimização de performance e escalabilidade, palestrou no QCon London 2009 sobre a arquitetura do Twitter e especialmente as otimizações realizadas nos últimos anos para melhorar o web site.
Muitas das ferramentas usadas pelo Twitter são open source. A lista de ferramentas são compostas por Rails na apresentação (front-end), C, Scala e Java para a camada de negócio, e MySQL para armazenamento de dados. Tudo é mantido em RAM e o banco de dados é apenas um backup. A camanda de apresentação em Rails gerencia a renderização, composição de cache, buscas no Banco de Dados e inserts assíncronos. Essa camada de apresentação se junta com vários serviços clientes, muitos escritos em C: cliente MySQL, cliente Memcached, cliente JSon, e outros.
O middleware usa Memcached, Varnish para cache de página, Kestrel, um MQ escrito em Scala, e um servidor Comet está no trabalho, também escrito em Scala e usado para clientes que querem seguir um grande número de tweets.
O Twitter começou como uma “plataforma de gerenciamento de conteúdo e não uma plataforma de mensageria” então muitas otimizações foram necessárias para mudar o modelo inicial baseado em leituras agregadas para o modelo corrente de mensageria onde todos usuários precisam estar atualizados com os últimos tweets. A mudança foi feita em três áreas: cache, MQ e cliente Memcached.
Cache
Cada tweet é seguido em média por 126 usuários, então existe claramente a necessidade de cache. Na configuração original, só a API tinha um cache de página que era invalidado cada hora que um tweet chegava de um usuário, o resto da aplicação não tinha cache:
A primeira mudança arquitetural foi criar um Vector Cache (cache de escrita) contendo um array de IDs de tweet que são serializados em integers de 64 bit. Esse cache teve uma taxa de acerto de 99%.
A segunda mudança foi adicionar Row Cache também de escrita, contendo registros de de banco de dados para: usuários e tweets. Esse teve uma taxa de acerto de 95% usando o plugin Rails do Nick Kallen chamado Cache Money. Nick é um Arquiteto de Sistemas do Twitter.
A terceira mudança foi introduzindo o Fragment Cache (cache de leitura) contendo versões serializadas dos tweets acessados através de API cliente que pode ser empacotada em JSON, XML ou Atom, com a mesma taxa de acerto de 95%. O cache de Fragmento “consome os vetores diretamente, e se um fragmento serializado está cacheado atualmente ele não carrega a linha atual para o tweet que você está tentando ver, então ele faz pequenos acessos ao banco de dados a maior parte das vezes”, diz Evan.
Ainda outra mudança foi criar um pool de cache para o cache de página. De acordo com Evan, o pool de cache de página usa um esquema de chave geracional ao invés de invalidação direta pois clientes podem
enviar HTTPs se-modificados-desde e colocar qualquer hora que queiram no caminho da requisição (request path) e nós precisamos cortar o array e apresenta-los apenas com os tweets que eles querem ver, mas não queremos mostrar todas as chaves possíveis que os sistemas clientes tem usado. Houve um grande problema com esse esquema geracional porque ele não deletou todas as chaves inválidas. Cada página que foi adicionada que corresponde ao número de tweets que pessoas estavam recebendo iria tirar dados válidos do cache e isso revelou que nosso cache tinha uma vida útil de somente 5 horas efetivas por causa de todas essas páginas de cache fluindo.
Quando o cache de página foi movido para dentro de seu próprio pool, o cache caiu cerca de 50%.
Esse é o cache atual empregado pelo Twitter:
Desde que 80% do tráfego do Twitter vem através da API, existem 2 níveis adicionais de cache, cada um servindo 95% dos requests vindos da camada anterior. As mudanças no cache global, no total entre 20 e 30 otimizações, trouxe uma
capacidade de melhora de 10x, e teria sido ainda mais, mas bateu outro gargalo nesse ponto … Nossa estratégia foi adicionar o "cache first" de leitura, para certificar que ele invalida corretamente, e depois mover para um cache de escrita e consertar online ao invés de destruí-lo toda vez que um novo tweet ID chegar.
Fila de Mensagem
Desde que, em média, cada usuário tem 126 seguidores, significa que existem 126 mensagens colocadas na fila para cada tweet. Além de que, há ocasiões de pico de tráfego, como foi durante a inauguração de Obama quando chegou a várias centenas de tweets/segundo ou dezenas de milhares de mensagens na fila, 3 vezes o tráfico normal naquele tempo. O MQ teve pico e precisou dispersar a fila durante o tempo, assim eles não teriam que adicionar muitos hardware extras. O MQ do Twitter é simples: baseado no protocolo Memcached, não ordenando os trabalhos, sem compartilhar estados entre os servidores, tudo é mantido em RAM e é transacional.
A primeira implementação do MQ foi usando Starling, escrito em Ruby, e não escalou bem especialmente porque GC do Ruby não é geracional. Isso conduz o MQ a falhar porque em algum ponto o processamento da fila inteira parou para o GC terminar seu trabalho. Uma decisão foi portar o MQ para Scala que está usando o JVM GC que é mais maduro. O MQ atual tem somente 1200 linhas e roda em 3 servidores.
Cliente Memcached
A otimização do Cliente Memcached foi intencionada em otimizar a leitura do cluster. O cliente atual usado é libmemcached, com o Twitter sendo o usuário mais importante e contribuinte do código base. Baseado nisso, a otimização do Cache de Fragmento durante um ano teve o aumento de 50x em requisições de página servidas por segundo.
Devido a requisições pobres de localidade, a maneira mais rápida de lidar com as requisições é precomputar dados e armazenar em rede RAM, em vez de recomputar em cada servidor quando necessário. Essa abordagem é usada pela maioria dos sites Web 2.0 executando quase completamente direto da memória. O próximo passo é “ escalar escritas, depois escalar leituras por um ano. Depois vem a questão multi-localização” de acordo com Evan.
Os slides da apresentação Qcon forami publicado no site de Evan.