23
A (estúpida) controvérsia Twitter - Parte 2
on May 23, 2008
Novamente, o Twitter ficou um bom tempo fora do ar, deixando milhares de pessoas bastante irritadas, e com razão.
Novamente, o TechCrunch e outros pundits começaram a rolar suas máquinas de FUD: “a culpa é do Rails: Rails não escala.” nhé, nhé, nhé.
Antes de mais nada, os problemas do Twitter tem duas naturezas: ou acabou o dinheiro e, nesse caso, não há o que fazer; ou eles tem realmente problemas arquiteturais sérios que não tem a ver com Rails. Para começar eles já usam um mix de linguagens e tecnologias, PHP, Erlang, etc. Rails é apenas uma delas.
Muitos acham que Twitter = website, e website = Rails, portanto Twitter = Rails. Isso está errado. Twitter é uma plataforma de mensageria. Para os javeiros, estamos falando de coisas como JMS, e não HTTP. Exemplo, um dos componentes dessa plataforma são servidores Jabber, para broadcast para clientes de instant messaging.
Outro FUD grave: “Twitter é a maior aplicação Rails, que bela propaganda para o Rails …” Está também errado. Segundo esta compilação, baseada no Alexa, o topo da lista é o seguinte:
- Scribd (serviço de upload)
- Yellow Pages (as Páginas Amarelas!)
- Hulu (serviço de mídia da NBC)
- Penny Arcade (não tenho nem idéia do que seja :-)
- AboutUs (serviço de network de Wiki)
- Twitter (aqui está ele: 6o. lugar!!)
Fora eles, pouco abaixo estão outros sites que muita gente usa ou já viu e nem sabe que é feito em Rails, como o SlideShare, Guitar Hero, Gravatar, Feed Digest. Portanto, não, o Twitter não é o mais usado, porém os pundits adoram, pois é uma boa desculpa para colocar as palavras “Rails” e “não escala” na mesma frase sem parecer muito cara de pau.
Os problemas do Twitter são particulares do Twitter e de toda aplicação mal estruturada (seja tecnicamente e financeiramente). A lista que linkei acima tem apenas os Top 100. Na Working with Rails há uma lista muito maior, dentre elas 395 americanos e 30 brasileiros.
O objetivo da TechCrunch: imprensa marrom. O objetivo dos pundits: aliviar a dor de cotovelo. Resumindo: invejinha barata (ou “de barata”).
O blog Dare Obasanjo tem uma análise (especulativa) interessante que deve ajudar os iniciantes a entender os perigos de um conceito que parece tão simples quanto “followers” (seguidores).
Segue a tradução:
Alguns pensamentos nos problemas de disponibilidade do Twitter
Como usuário regular do Twitter, já senti as ondas de frustração sobre mim nas últimas semanas enquanto o serviço caía o tempo todo. Isso me levou a ponderar o espaço do problema e deduzi que o serviço deve ter uma séria falha de arquitetura que não tem nada a ver com a razão normalmente jogada pelos pundits não-técnicos (ou seja, a culpa é do Ruby on Rails).
Algumas das minhas suspeitas foram confirmadas por um post recente no blog de desenvolvimento do Twitter chamado Twittering about architecture, que contém o seguinte trecho:
Twitter é, fundamentalmente, um sistema de mensagens. Twitter não foi arquitetado como um sistema de mensagens, entretanto. Sendo breve, Twitter foi construído com tecnologias e práticas que são mais apropriadas para um sistema de gerenciamento de conteúdo. Há um ano e meio tentamos fazer nosso sistema se comportar como um sistema de mensagens o máximo possível, mas isso introduziu uma enorme complexidade e imprevisibilidade. Quando estamos em modo de crise, adicionar mais instrumentação para nos ajudar na rede de interdependências em nossa arquitetura atual é o primeiro recurso. Isso é, claramente, não ideal.Nossa direção para frente é substituir nosso sistema existente, componente-por-componente, com partes desenhadas desde o começo para atender os requerimentos que surgiram com o crescimento do Twitter.
Dado que o Twitter tem requerimentos únicos que colocariam à prova muitas aplicações padrão ou customizadas de mensagens, é chocante que ele não é nem mesmo arquitetado como um sistema de mensagens. Isso faz sentido se considerarmos o passado dos fundadores em ferramenta de blogs e sua intenção original do Twitter ser um “micro” serviço de blog.
Se o Twitter fosse simplesmente um serviço de micro-publicação de conteúdo com notificações push por SMS e IM então a equipe não seria culpada de desenhá-la como um CMS. Nesse caso precisariam de 3 estruturas de dados:
- um lugar para persistir os tweets de cada usuário
- um cache dos tweets em memória para melhorar performance de leitura
- uma lista persistente de endpoints [de IM ou SMS] assinados para cada tweet de usuário e um serviço assíncrono (ex. um daemon) que publica para cada usuário com assinatura a cada post.
Infelizmente, o Twitter não é somente uma ferramenta de blog que permite às pessoas assinar meus posts via SMS & IM em vez de apenas RSS. Ele também tem a noção de seguidores. É quando as coisas começam a ficar cabeludas. Isreal, da AssetBar, tem um grande post sobre isso entitulado Twitter-proxy: Algum interesse? onde ele escreveu:
Considere o seguinte problema de mensagem:
Nada é tão fácil quanto parece. Quando Robert Scoble escreve um simples “Estou saindo com …”, o Twitter tem cerca de 2 opções de como despachar essa mensagem:
- PUSH (empurrar) a mensagem à fila de cada um de seus 24.875 seguidores, ou
- Esperar pelos 24.875 seguidores fazer log in e PULL (puxar) a mensagem.
O problema da opção 2 é que pessoas como Robert Scoble também seguem 21.146 pessoas. E é inaceitável para ele fazer login e ter que esperar o sistema abrir os registros de 21.146 pessoas (através de múltiplos shards de banco de dados), então ordenar os registros por data e finalmente renderizar os dados. Os usuários estariam odiando as ALTÍSSIMAS latências.
Então, o modelo do Twitter quase certamente seria a opção 1. A mensagem do Robert é copiada (ou pré-carregada) para os 24.875 seguidores, de tal forma que quando o usuário abrir sua página/cliente, lá estará a mensagem de Scoble, esperando por ele. Os usuários adoram a velocidade, mas o Twitter está odiando as operações de escritas. Todas elas.
Quantas operações?
Um fator de multiplicação de 6.000 vezes:
Você vê algum problema com este cenário?
- Scoble escreve alguma coisa – boom – 21.146 operações de escrita são disparadas. 1 para cada seguidor.
- Michael Arrington responde – boom – outras 17.918 escritas.
- Jason Calacanis adentra – boom – mais 25.972 escritas.
Além das 65.036 escritas, há muita sobrecarga também. Você precisa atingir o banco de dados para descobrir quem são os 65.036 seguidores. Leitura, leitura, leitura. Então possivelmente atingir outro banco de dados para descobrir em qual shard eles vivem. Leitura, leitura, leitura. Então precisa fazer uma conexão e escrever nesse host de banco de dados, e em caso de sucesso, voltar e marcar as atualizações com sucesso. Dependendo dos detalhes do sistema de mensagens, toda a sobrecarga de procura e cálculo poderiam ser muito maiores do que 65.036 leituras + 65.036 escritas. Você não iria querer nem mesmo começar a pensar nos problemas de replicação (multiplique por um fator de 2 ou 3). E não se esqueça dos lockings também!
E aqui vai o principal: esse gigantesco esforço de processamento & entrega uma combinação de 130 mil IOs de disco causados por apenas 3 usuários, enviando apenas uma, pequena, mensagem de 140 caracteres. Quão inocente isso parece.
Não somente o post do Israel descreve bem o problema no modelo lógico da funcionalidade de “seguidores” do Twitter, parece que ele acertou nos detalhes da implementação, o que explicaria os problemas significativos que eles estão sofrendo com escala. O problema é que se você ingenuamente implementar um design que simplesmente reflete a descrição do problema então você cairá em um inferno de IO. Não importa se está usando Ruby on Rails, Cobol on Cogs, C++ ou Assembly escrito manualmente, a leitura & escrita irá matá-lo.
Isso me leva ao meu novo mantra que roubei de Jim Gray via Pat Helland DISCO É O NOVO TAPE.
Além disso, o fato do pessoal do Twitter ter decidido não limitar os seguidores e os que você segue pode tê-los salvo dos tipos de flames que Robert Scoble enviou ao Facebook pelo limite de 5.000 amigos mas isso também significa que eles não somente tem que lidar com o suporte de usuários com milhares de seguidores, mas também usuários que seguem milhares de outros usuários [ambos casos que seriam otimizados de maneiras muito diferentes]. Claramente muita decisão de funcionalidade foi feita no produto sem pensar em qual seria o impacto de escalabilidade do sistema.
Ja cansei de ouvir a mesma ladainha com relacao ao Twitter.A gente poderia ter alguma grande ‘case’ nacional p/ ajudar a comunidade por aqui(e definitivamente servir de ‘cala-boca’ p/ esse pessoal que fica falando $$#@## do Rails),visto que nao existe nenhum site relevantemente famoso em Rails no Brasil.Que venha o primeiro e ajude o Rails a propagar.
Abracos!
Pois é Akita, concordo com você em gênero número e grau…
Mas li também alguns dados que me impressionaram…
A equipe de rede(leia-se estrutura de mensageria) responsável pelo Digg tem muito mais integrantes do que a equipe inteira do Twitter, aqui vai uma observação minha: Eu não acredito que equipe enorme resolve problemas, colocar mais gente só iria aumentar o problema.
Voltando a minha escrita, vendo por este lado de que o twitter não tinha sito escrito(projetado) para ter essa massa (carga) de informações entregues de forma instantânea, pode até ser mesmo essa a raiz dos problemas.
Sabemos que manter um serviço da magnitude to twitter não é fácil, ainda mais com essa não limitação de seguidores, não sei você, mas pra mim irritaria estar seguindo 25.000 pessoas e ser seguido por outras 20.000 pessoas, até porque não conseguiria fazer outra coisa na minha vida do que ler os posts dos outros.
Alguém faz isso, ou isso foi apenas um exemplo, ou é caso real mesmo?
Mas enfim, pelo que vi, temos que ter paciência, o sistema está sendo re-projetado a fim de atingir o objetivo que foi alterado no meio do caminho.
Seu post com os respectivos links, me esclareceram algumas duvidas que eu tinha com relação a entrega de mensagens em tempo real e não quando houvesse uma solicitação.
Vida longa ao twitter.
Abraços Akita
Fabio Nascimento
@fabio haha :-) Pois é, parece até brincadeira. Mas vocês ainda não sabem o que é um blogueiro profissional (acho que no Brasil inexiste gente nessa categoria), até conhecer esse pessoal.
Robert Scoble literalmente vive de blogar e twittar. Ele escrever pra revista Fast Company se não me engano. Eu seguia ele, o cara twita a cada 5 segundos. E neste instante seu número de seguidores já subiu para 24.976!!
O Michael Arrington é um dos caras do TechCrunch que, quer queira quer não, é extremamente influente também.
O Jason Calacanis é o cara do Sequoia Capital e do Mahalo.com e tem relação com o Arrington no TechCrunch também.
Outros caras ainda mais seguidos, veja o Leo Laporte que é um radialista e podcaster profissional (da rede Twit.tv), ele sozinho tem 36.062 seguidores.
Outra famosa podcaster profissional, que já foi da C|Net, do Mahalo Daily e agora é da Tekzilla, a Veronica Belmont (um dos produtos da rede Revision3) tem 21.613 seguidores. O Digg é apenas um dos produtos da rede Revision3 do Kevin Rose, e ele sozinho tem mais 35.057 seguidores. A Leah Culver, que é líder do Pownce (mais um produto da Revision3) tem mais 4.452 seguidores.
E não vai muito longe, veja o Blaine Cook, que é do Twitter, tem 3.067. David Hansson, que perto deles é “pequeno”e tem 2.104 seguidores. O Geoffrey Grosenbach tem 1.489.
Comparado a eles, que são algumas das pessoas mais influentes da web, eu sou um peixe super pequeno, com apenas 361 seguidores.
Some a isso a explicação da operação que o Israel descreveu e você começa a entender os problemas de escalabilidade deles. E o problema seria generalizado independente da plataforma/tecnologia sendo usada. É um problema que nunca ninguém enfrentou antes e não existe literatura sobre o assunto.
É muito pior do que servidores de IM onde a conversa é peer-to-peer, ou 1 para 1. No máximo você tem um chat entre meia dúzia de pessoas. Mesmo num IRC o broadcast fica limitado a uma “sala”. O Twitter é um broadcast gigantesco e cresce exponencialmente. É uma dor de cabeça sem tamanho.
Me lembrou duma coisa que eu sempre digo a respeito de designs muito maneiros… Fazer é fácil… Mas ter a idéia de fazer que é difícil…
Depois que o pessoal do twitter descobrir um meio de resolver esse pepino, vão surgir jwitters (java), nwitters(.net), pwitters (pyton ou php), hahaha :D
A questão está mesmo relacionada a um problema sem antecedentes…
Depois que criarem uma arma pra matar esse dragão, vai ser só qualquer mané (com qualquer linguagem) apertar o gatilho… ;-)
Expandindo um comentário que fiz no Twitter, achei engraçado o andamento do artigo da TechCrunch: começa fazendo boas observações sobre como o problema do Twitter é pouco explorado. De repente, salta para falar como o pessoal de lá não tá preparado. A conclusão disso tudo? Que Rails é o problema, óbvio!
Resumindo, os caras do twitter estão ferrados, é o tipo de app que precisa reestruturar alguns conceitos, algo igual ao google fez com o map reduce e assim por diante agora resta saber quem vai ser o gênio para resolver este super pepino. Este problema nada tem a ver com framework ou linguagem, o buraco é bem mais embaixo, conforme eu disse no railsbr a um tempo atrás e fui altamente criticado, este é um problema bem particular e é bem provavel que tão cedo ninguem venha ter um problema semelhante. Enquanto eu não for fazer um twitter o resto que ensiste em dizer que rails não escala que se f… O twitter precisa contratar gente ou fazer com que seu engenheiros consigam pensar em um novo conceito para resolver este problema exponêncial e a imprensa técnica tem que tentar ser mais técnica e entender o problema e os inciumados tem que aprender outras linguagens e parar de defender as únicas que sabem como religião.
Uma coisa é bem claro no rails, resolver os problemas mais comuns da forma mais prática. Agora a pergunta, o problema do twitter é comum?
Bem, esse é o meu ponto de vista e acho que este artigo do Akita foi o melhor na polêmica do Twitter e ladainhas adjascentes.
Comecei a usar i Twitter há poucos dias por incentivo (indireto do Elliot) vejam mais dessa história lá no meu blog =) Claro que já tinha escutado muita gente falar sobre o Twitter, entre críticos e fanáticos… Minha opinião com relação à esse assunto é bem simples, toda aplicação precisa ser bem planejada, pensar em diversos assuntos e quando se trata de aplicações que serão utilizadas por muitas pessoas o quesito Escalabilidade é um ponto muito importante. Esse artigo foi bem esclarecedor e foi até engraçado como cheguei nele, se vocês olharem no meu último post no Twitter eu estava estudando sobre escalabilidade… =) Isso me lembra uma frase bem engraçada que aparecia com certa frequência no Orkut… Bad, bad server. No donut for you Problemas dessa grandeza não são triviais de se resolver, até porque se fosse alguém por ai estaria falando que Rails não é escalável?? Espero que o pessoal do Twitter encontre uma solução para esse problema, pois estou gostando muito de Twitar e Follow people. =)
Bá… Tinha até esquecido desses problemas do Orkut…
Vai ver ASP.NET não escala! :-D
Akita,
assunto meio fora do post, mas que é mais para reportar um problema: não há registros no feed do seu blog a partir desse post.
Não quero te aporrinhar, nem te cobrar nada. Mas sei lá, seria bom te avisar caso você não esteja sabendo.
RoR?
?!?
Alguma empresa séria leva a linguagem a sério?
?!?
Não conheço nenhuma. Enquanto Ruby não conseguir ser alçado ao nível “Enterprise” não creio que decole aqui no Brasil nem em qualquer lugar do mundo.
Putz, esse cara ta falando sério?
Não me leve a mau, mas leia antes! Pesquise!
Ruby tem problemas como qualquer outra linguagem. Certamente não é tão madura quanto C ou Java ou C#, mas muita gente leva a serio sim.
As maiores empresas da WEB estão de olho em Ruby On Rails – vide JRuby. O que falta sim é um investimento pesado por parte delas, isso ainda é pequeno.
Fui responder ao rapaz ali e acabei esquecendo do Twitter.
A comparação que o Juarez fez perfeita. O orkut também tinha diversos problemas quando os Brasileiros começaram a invadir massivamente: Bad Server pra todo lado.
Quando o google começou a levar o orkut a serio, o negocio alavancou. Nunca mais vi a tal Bad Server.
Momento especulação: Ouvi dizer que o orkut não é mais em ASP.NET, que elem mantem aqueles aspx na url para não haver incompatibilidade com urls de links e tal. Sinceramente, não sei. Olhando o HTML gerado, realmente não parece ser ASP.NET – essa tecnologia gera HTMLs facilmente reconhecíveis. Vai ver é como o davis disse: ASP.NET não escala! C# não tem aquela keyword “scale”! Hehehehe…
Opa,
continunado a conversa. Saiu mais uma notícia no Tech crunch. E parece que agora colocoram a culpa no MySQL. Vejam a discussão que aconteceu no Meiobit: http://www.techcrunch.com/2008/05/31/hey-twitter-i-have-a-few-questions-too/
E aí, o que vocês acham? A culpa será mesmo do MySQL? Será que trocar por Postgres, SQL server, oracle ou db2 resolveria o problema? E usar o filesystem, é ou não uma boa idéia?
Eu não tenho experiência com grandes bancos de dados por isso não opino. :)
Não levem o TechCrunch a sério ele é só a porcaria de um blog,mantido por metidos a "MEDIA CHIEFS" que tem por objetivo gerar notícias absurdas e sensacionalistas pra ganhar cliques no Google AdSense.
É isso aí pessoal!