Steve Huffman, co-fundador do Reddit, compartilhou as principais lições aprendidas escalando o Reddit de uma aplicação web pequena para um grande website social.
O Reddit foi fundado por Steve Huffman e Alexis Ohanian em 2005 e consistia em rodar a aplicação web, o servidor de aplicação e o banco de dados em uma só máquina. Ao passar do tempo, o Reddit cresceu para cerca de 7.5 milhões de usuários por mês e 270 milhões de page views no mesmo período. Huffman contou em uma apresentação o que ele aprendeu ao longo desse caminho e falou sobre vários erros cometidos e como tratar eles.
1. Quedas constantes
Eles tiveram várias quedas da applicação no começo. Huffman dormia com seu laptop ao lado, acordando toda hora para verificar se o website estava no ar e rodando. A solução encontrada foi o Supervise, uma deamon que restarta aplicações que sofreram "crash". O que leva a uma aproximação entre a aplicação rodando e o seu design: se a aplicação possui leaks de memória ou consome muita memória, eles simplesmente matam a aplicação e restartam ela do começo. Essa não é era uma solução definitiva, mais sim temporária até que a aplicação fosse consertada de acordo com o que aparecia no arquivo de log.
2. Separação de Serviços
Huffman sugere agrupar processos similares na mesma máquina ou grupos de máquinas, tudo isso para evitar a frequente mudança de contexto, que consome recursos. Ele também considera como boa prática utilizar uma máquina de banco de dados para tipos de dados similaresvisando não mudar os índices toda hora, e mover os outros tipos para outras máquinas.
Huffman sugere evitar threads que, em Python são consideradas "o beijo da morte, uma fórmula para a lentidão ". Se várias tarefas estão atríbuidas a processos separados ao invés de threads, fica mais fácil mover esses processos para uma outra máquina quando a demanda crescer e mais recurso for necessário. O único problema com isso é a comunição entre os processos, mas em contra partida é melhor por conta que a arquitetura pode crescer mais suavemente.
3. Open Schema
Toda nova funcionalidade requiria um update no schema o que era cada vez mais doloroso de acordo com o crescimento do banco. Adicionar uma nova coluna a uma tabela com 10 milhões de linhas pode ser bastante demorado , principalmente se você tem uma cópia de backup e uma replicação da base. Existiram dias em que eles não fizeram o backup pois precisavam criar a réplica nesse tempo.
A solução foi utilizar um open schema ou um valor entidade-atributo, um banco chave-valor. Agora existem duas tabelas para cada tipo de dados:
Things podem ser Users, Links, Comments, etc. todos compartilhando o mesmo schema. A tabela Data é composta por um grande número de dados mas apenas 3 colunas: um ID, uma Key (chave) e um Value (valor). O resultado desse novo schema foi que, adicionar uma nova funcionalidade não era necessário mudar o schema ou criar tabelas. Além disso, não existiam mais joins no BD, fazendo com que o BD fosse facilmente distribuído.
4. Seja Stateless
Um objetivo de qualquer aplicação web é que o servidor de aplicação consiga manipular qualquer requisição. O que é muito fácil fazer quando você possui apenas uma máquina (óbvio), mais isso pode ser complicado utilizando múltiplos servidores e estado da aplicação cacheado. Cada servidor adicionado aumenta a redundância do cache e dificuldta o acesso ao dado cacheado.
A solução nesse caso foi trocar para o memcache e parar de utilizar estado em todos os servidores de aplicação que nós tinhamos. Um dos benefícios imediatos foi o fato de que um quando um servidor de aplicação caia ele não afetava outros servidores. Além disso, escalar foi fácil, ficou mais fácil adicionar novos servidores.
É importante separar o servidor de cache dos outros servidores para evitar uma contenção de recursos.
5. Memcache para Tudo
O Reddit começou a utilizar memcache para tudo: dados do banco de dados, dados de sessão, páginas renderizadas, memorização de funções internas, páginas pré-processadas, lock global. Eles também utilizaram o memcachedb para a pesistência de dados.
6. Guardar dados redundantes
Uma fórmula para a lentidão é "manter dados normalizados até que você precise deles". Quando o usuário precisa de um dado apresentado em um formato específico, pegue os dados completo e os processe, isso pode fazer com que a reposta demore e o usuário tenha que ficar esperando. A solução para isso foi deixar na memório e no disco todos os formatos utilizados para mostrar os dados. Enquanto essa abordagem possui impacto na memória e no disco, ela possui as vantagem de uma resposta rápida para a requisição do usuário.
Para o Reddit, a chave para a velocidade é "pré-processar tudo e colocar no memcache".
7. Trabalhar Offline
Quando um usuário faz uma requisição, o sistema precisa fazer tudo o que for necessário para retornar uma resposta apropriada, e todo o resto é colocado em uma fila de jobs que faz as coisas offline. Exemplos de jobs feitos offline incluem: pré-processar anúncios, buscar thumbnails, detectar faudes, remover spam, processar prêmios, e atualizar os índices de busca. Quando um usuário vota em um link, ele não precisa esperar até que os índices sejam reindexados e os anúncios atualizados, essas tarefas podem ser feitas depois que uma resposta foi dada para o usuários.
As flechas azuis na figura abaixo representam atividades realizadas na requisição do usuário, as flechas rosas são atividades feitas offline:
