17 April 2008 ~ 28 Comments

Booting up sapo.cv


update: Apparently this post had some unexpected echo all over the blogs. Thanks all for your feedback, we’re proud. My friend Pedro was crazy and kind enough to translate the post to english.

Ontem lançámos o SAPO Cabo Verde. A sensação de ter um SAPO fora de Portugal é no mínimo estranha, é um misto de orgulho e de medo, em que a segunda das sensações advém certamente do facto de nunca termos pensado muito nisto, na hipótese de actuarmos fora do rectângulo. É o tal síndroma que nos persegue, aos Portugueses em geral, para aí desde o tempo em que deixámos de pensar que somos grandes.

O projecto já cozinhava há uns largos meses. Não vou aqui discutir nem as razões nem os objectivos, alguém o fará por mim, vou só falar de tecnologia. Tecnologicamente falando, instanciar o SAPO fora de Picoas foi um desafio muito interessante. Uma coisa é escalarmos dentro do mesmo Datacenter mas outra coisa é sair do útero, distribuir conteúdos em pontos do globo distintos e distantes e reutilizar a mesma tecnologia mas em contextos diferentes e com características diferentes da nossa realidade mantendo ao mesmo tempo uma arquitectura global.

Ainda é cedo para falar. Posso estar a mandar foguetes antes do tempo e sair-me o tiro pela culatra, mas de qualquer forma achei relevante fazer este post e partilhar convosco a nossa experiência:

SOA


Nos últimos 2-3 anos andámos a queimar pestanas e a limpar a casa para conseguir montar uma arquitectura de sistemas baseada em serviços, vulgo SOA. E conseguimos. O nosso BUS de serviços está de pé e com uma vasta oferta de conteúdos que usamos e reutilizamos quer internamente quer com parceiros ou público em geral. Mas o BUS é mais do que um HUB de APIs, faz mais do que isso. Faz transformações de um formato para outro de qualquer método (ie: RSS para JSON), logging, controle de acessos, proxying, caching, gera documentação e código para todas as linguagens com base nos contratos dos serviços, é um mundo. E é só por causa deste valor todo que suportamos o fundamentalismo do seu incansável e convicto mentor em relação às guerras de SOAP vs REST. Em 2008 vamos colocar o nosso BUS em Opensource, está decidido.

E foi quando deixámos de apregoar SOA para efectivamente o praticar que conseguimos realizar projectos como o SAPO Mobile, que não é mais do que um “cliente” rico do portfolio do BUS (ok, é mais do que isso, mas é para perceberem). O services.sapo.pt é hoje uma peça fulcral na forma como concebemos e montamos os nossos projectos e permitiu-nos não só baixar drasticamente a complexidade dos desenvolvimentos bem somo os tempos de produção dos mesmos. Cabo Verde não existiria nos moldes actuais se não fosse estes esforço silencioso e quase inglório (porque durante muito tempo não representou output para a empresa) que a tecnologia do SAPO teve durante os últimos anos.

Broker

Broker é outro dos “building-blocks” do SAPO. Foi escrito e re-escrito de raíz por nós (embora a primeira versão tenha sido baseada no Mantaray) e é um dos nossos projectos Opensource. Basicamente e sem entrar em muitos detalhes é uma nuvem gigante de agentes que está presente no Backend de todos os servidores do SAPO, distribuida, e que permite a qualquer aplicação a troca de mensagens e eventos, de forma completamente assíncrona (fire and forget) e em tempo real. Cada evento viaja dentro de um tópico (ou namespace). Os “clients” podem ser produtores ou consumidores de eventos (think pubsub, think uma rádio a emitir numa determinada frequência e um sem número de ouvintes que a sintonizam).

A Homepage do SAPO é completamente dependente do Broker. Cada um dos frontends da Homepage tem um agente que o gestor de conteúdos notifica (através do Broker) cada vez uma zona da Homepage precisa de ser queimada. A Homepage também produz eventos de Broker no browser, com chamadas da AJAX (ie: cada click que se faz numa notícia).

A beleza do Broker é aquilo que eu chamo de “decoupling”. Imaginem mashups de eventos em vez de feeds. Imaginem que alguém no SAPO quer montar um serviço que incrementa um contador por cada vez que alguém pesquisa por “Cabo Verde” na Pesquisa do SAPO e que cada vez que um JID do SAPO Messenger, que é colaborador da empresa, faz login dispara-lhe uma mensagem de IM com o número de pesquisa feita por esse termos até à data. O exemplo é estúpido, é da hora, mas o ponto é: Qualquer pessoa no SAPO pode fazer este serviço, não depende de ninguém, não depende da malta da Pesquisa, nem do SAPO Messenger. Basta-lhe consumir os tópicos apropriados que já estão na nuvem e que estão documentados e cujos eventos está a ser gerados, em tempo real, pelas plataformas do SAPO.

Neste momento já temos mais de 100 tópicos a gerarem notificações e com um tráfego agregado na nuvem de mais de 1000 eventos por segundo. A regra de ouro é, qualquer serviço novo que realize uma acção relevante (ie: Alguém faz o upload de um vídeo no SAPO Vídeos, alguém faz login no SAPO Mail) deve produzir uma mensagem e publicar num tópico no Broker.

O Broker é crucial para a nossa escalabilidade e fiabilidade (o decoupling permite-nos na prática reduzir o número de dependências das aplicações e as característica de assincronismo e fire-and-forget reduzem o risco de falta de recursos e performance).

Este é daqueles produtos que temos de advogar mais. O tempo é escasso e é-nos difícil passar a mensagem para fora mas não hajam dúvidas: se procuram um framework de messaging entre aplicações, espreitem isto.

Cabo Verde tem uma nuvem própria de eventos a correr “lá” e partilha uma série de tópicos com Portugal (ie: O gestor de conteúdos reside cá).

CDNs

Durante anos tive a Akamai à perna a tentar vender-me soluções de CDN. Mas por muito que se goste da Akamai (e gosto) a solução nunca fez grande sentido. Na realidade não há muitos problemas de descentralização da entrega de conteúdos quando as maiores redes de acesso ADSL, Cabo e Móvel são da mesma empresa.

Mas entretanto a realidade alterou-se. Não só a rede de acesso cresceu muito e tornou-se complexa sendo necessário encontrar formas de estarmos mais próximos da last-mile, como o Cabo se separou, como entretanto o SAPO se internacionalizou e passou a ter mais do que um Datacenter em mais do que um País. O próprio perfil de conteúdo alterou-se drasticamente. Há 5 anos atrás não havia vídeo na Internet, só para dar um exemplo.

O SAPO Vídeos é o nosso serviço mais exigente no que diz respeito a entrega de conteúdos. Neste momento está a gerar quase 2Gbit/s de largura de banda em média durante todo o dia. Quando construímos a plataforma pensámos muito sobre a melhor forma de resolver o problema dos altos débitos e do futuro crescimento do serviço. E acabámos por construir uma solução de CDN caseira baseada em arquitectura de rede, NAS, DNS e Squids invertidos.

Esta mesma solução permitiu-nos levar o SAPO Vídeos para Cabo Verde, optimizando a entrega local dos vídeos (através da nossa CDN) mas mantendo o “core” do serviço (gestão, master dos vídeos, webUI) em Portugal, Picoas. Isto quer dizer que, com alguma magia de DNS (ver mais abaixo) em Cabo Verde os mesmos vídeos de http://videos.sapo.pt/ são servidos a partir do Datacenter da CV Multimédia por forma a não abusar de um muito limitado link internacional que o País tem.

Bricolage, gestão de conteúdos

Bricolage é um gestor de conteúdos (enterprise-class for all you suits) Opensource e nesta tecnologia estão assentes alguns dos nossos Websites mais importantes, incluindo as Homepages de Portugal e Cabo Verde, o DN e o JN, entre outros. Workflow, autorizações, versioning e XML é com o Bric. Poucos sites precisarão de um canhão destes, a curva de aprendizagem não é pequena. É impróprio para cardíacos.

Mas depois de feito o deployment e de uma boa formação das equipas editoriais, esta besta é poderosa e de confiança.

A Homepage do SAPO em Cabo Verde é editorialmente gerida a partir do Backoffice alojado em Picoas, numa infra-estrutura partilhada com a Homepage de .pt. Os frontends em Cabo Verde são notificados (via broker) quando há conteúdo novo e isso despoleta um processo de actualização e re-processamento das páginas.

Imagens, CSS e conteúdo estático

As nossas farms de Imagens e de conteúdo estático (ie: http://h.s.sapo.pt/ http://js.sapo.pt/) possuem réplicas exactas e locais em Cabo Verde (http://h.sapo.cv  http://js.sapo.cv). A replicação é feita com rsync. As farms estáticas são processos de lighttpd (dois por máquina para aproveitar os Xeon) em Linux e com epoll e cabeçalhos de Expires gigantes. Em testes conseguimos esgotar as interfaces de Gigabit de um destes servidores. A carga? 2. Uptime do nosso static1 (de 3):


root@static1:/servers/lighthttpd/etc# uptime
 01:08:13 up 553 days, 11:36,  1 user,  load average: 0.01, 0.01, 0.00
root@static1:/servers/lighthttpd/etc# ps ax |grep lightt
 2019 ?  S 429:53 /sbin/lighttpd -D -f /servers/lighthttpd/etc/httpd1.conf
 2039 ?  S 370:24 /sbin/lighttpd -D -f /servers/lighthttpd/etc/httpd2.conf


Rsync

rsync é um dos nossos canivetes suíços dentro do SAPO. É usado para replicar árvores inteiras de conteúdos, para fazer a passagem de projectos para produção que estejam distribuídos por vários servidores, para gerir repositórios de pacotes Debian, para replicar a nossa farm de Web thumbnails, etc, etc. É muito eficiente porque faz cópias incrementais e comparativas e porque prima pela simplicidade e pela performance. Comporta-se muito bem também em cenários de conectividade remota. Só para terem uma ideia, há pessoas corajosas o suficiente para fazerem backups de servidores e dos seus computadores pessoais com rsync. 

Cabo Verde depende muito dos nossos processos integrados de passagem para produção e replicação de conteúdos, que passam necessariamente pelo rsync.

Monitorização e Métricas, Nagios e Cacti

Desde sempre que usamos o Nagios para monitorização e alarmes e o Cacti para métricas de sistemas, mais dois produtos Opensource de qualidade. Em Cabo Verde usámos a mesma aproximação e estamos activamente a tentar ligar as duas instâncias (quatro) para termos uma visão integrada de tudo, do SAPO como um todo. Em teoria é bem possível, não só porque o software é Opensource mas porque é baseado em sondas, scripts e SNMP.

DNS patch

Os nossos DNS primário e secundário correm em cima de djbdns. Adicionámos-lhe um patch (com contribuições poderosas do nosso Über Sysadmin japc) que basicamente nos permitem dar respostas diferentes para ponto geográficos diferentes. Como base de dados de georeferenciação usa a GeoIP. Very nice.

Já estão a adivinhar não? Se alguém em Cabo Verde pedir um ficheiro de .js a http://js.sapo.pt/ o DNS encarrega-se de lhe resolver o nome para um IP dos nossos servidores em .cv (que também respondem a js.sapo.pt) e o conteúdo é servido localmente. Se alguém fizer o mesmo noutra parte qualquer do mundo, o DNS resolve para o IP de Picoas. Este conceito é aplicado em inúmeros cenários do projecto.

Instanciação e Templating

Outra mudança de mindset para nós foi a de passarmos a pensar nas plataformas dos projectos como sendo sistemas capazes de correr em contextos diferentes com comportamento diferentes mas sempre com uma base comum, um chapéu. E capazes também de se instanciarem, total ou parcialmente, fora do seu habitat natural, neste caso Picoas.

Isto na prática exigiu de nós um cumprimento mais rigoroso de um conjunto de boa práticas que nem sempre foram a regra: Usar sempre templating (ie: smarty, mason, template-toolkit) e CSS, prepararmos-nos para o multilingue, configurações dinâmicas dos serviços (por contexto, ie: bases de dados, memcacheds, etc), modularização e reutilização de componentes web (ie: mashups), repensar os procedimentos de passagem de desenvolvimento a produção (a contar os cenário de multi-hosting, multi-site).

libsapojs & Widgets

Outro projecto que fizemos em 2007 e que nos ajudou em Cabo Verde foi a nossa library de Javascript. No fundo estamos a falar do mesmo, reutilização de componentes e distribuição. Os Widgets que desenvolvemos em Portugal ficam, através dos procedimentos de passagem a produção e replicação, automagicamente disponíveis em todo o universo SAPO, tal como um mapa do Google num blog se auto-actualiza sob o comando do seu dono.

Em suma:

Estes são só alguns exemplos do tipo de preocupações que tivemos quando começámos a pensar no Internacional. Conselhos? Sim, alguns:

1. Uma boa arquitectura de sistemas é crucial para a evolução de qualquer projecto de TI. Nós, por questões históricas e heranças (legacy de mergers and stuff), aprendemos isto a bater com a cabeça na parede. Custou-nos mais. Não facilitem. Facilitem em tudo mas uma má arquitectura num projecto que quer crescer é um tiro no pé no médio-longo prazo.

2. Especifiquem por excesso, raciocinem top-down. Pensem à frente do tempo. É preferível perder 2 dias a colocar gettext nos templates, mesmo que não se use ainda, do que depois perder 1 mês a fazer refactoring de tudo para acomodar os novos requisitos. Definam um conjunto de boas práticas e cumpram-nas religiosamente. As áreas de negócio vão ficar irritadas por causa do famigerado time-to-market mas arranjem uma firewall e percam tempo no início, não durante. Eu sei que isto é uma lapalissada mas tem que ser dito. 

3. APIs são ouro, são a cola da Internet. Estruturem e façam interfaces para tudo, e anunciem-nos, mesmo que não usem. Seja RSS, XML, JSON, SOAP, Microformatos, o que for. Desde que seja um formato estruturado, até sou capaz de suportar WSDL. HTML scrapping ou logins para aceder a uma schema mutante de Mysql é que não, por favor. Produzam matéria prima, mesmo que seja inútil, e publiquem-na, de preferência de forma assíncrona para o caso dos eventos. Alguém algures, dentro ou fora da organização pode reutilizar esse material para construir um novo serviço, “decoupled” dos plataformas e dos autores das fontes, como deve ser.

5. Simplifiquem, não compliquem. O ser humano é complicado por natureza, temos uma tendência natural para nos metermos em alhadas e depois racionalizar tudo com explicações estapafúrdias. Para quê usar um SQL se o schema não é relacional? O filesystem é das bases de dados mais robusta e testadas do planeta, funciona impecável para queries do tipo chave/valor. Para quê um “full blown Apache Webserver” quando na realidade o que nos interessa é performance HTTP? Talvez um lighty seja mais adequado. Balanceamento Layer4, não será um simples perlbal mais eficaz e robusto do que um dispendioso e obscuro equipamento de rede? Etc.

Para fechar, fica aqui o testemunho de que é possível construir uma arquitectura de um Portal Web completamente distribuída, modular, reutilizável  e flexível com produtos Opensource e prata da casa. Não se assustem nem se deixem levar à primeira pelos discursos dramáticos dos consultores e dos fabricantes (so called carrier-grade). A nós deu-nos muito gozo montar isto, agora é deixar amadurecer, aprender um pouco mais, e lançarmos-nos a maiores vôos.
  • http://nunodantas.com/blog Nuno Dantas

    Artigo brutal! Excelente!
    Continuem assim e não se deixem enganar pelos homens de fato e gravata ;)
    Já agora, internacionalização a sério era montar um polo do sapo a norte.

  • http://ptnik.blogspot.com Carlos

    Muito interessante. É sempre bom saber como funcionam as coisas “por trás” de uma pagina web aparentemente simples. :)

  • Jorge Alves

    Lighthttpd. squid invertidos, djbdns….
    Bons tempos de IPGlobal e Clix.

    Caro, keep up the good work!

    ;-)

  • http://jpereira.eu joão

    é muito bom saber que se faz tecnologia à séria cá em Portugal :)
    e este artigo de facto vem ajudar a perceber que o Open Source ainda tem muito para dar às empresas, apesar de os nosso “empresários” ainda não terem aprendido que OpenSouce não é só Linux e aplicações desktop. Existe um potencial inimaginável no Open Source, principalmente quando se fala em integração e disponibilização de serviços de IT. Não é só o facto de se reduzir/eliminar os custos com licenças, mas principalmente o facto de existir um grande acréscimo de valor para as empresas que tomam a decisão acertada de utilizar OSS.

    Mas o OSS por si só não faz milagres. E esta malta sabe disso :)

    Great work! Great SAPO! :)

  • http://mat.su Pedro Pinheiro

    Excelente visita guiada aos bastidores, é bom saber que alguém está a lutar activamente contra o “em cima do joelho” que é tão Português. Uma versão em Inglês deste artigo seria óptima para partilhar como um “case study”.

  • phoenux

    Parabéns pelo(s) projecto(s) e obrigado por partilharem. É muito bom saber que se fazem coisas deste tipo em Portugal… Qualquer dia a Sapo vem ser é comprada pela Google… Continuem assim.

  • http://jpereira.eu joao

    phoenux: Pessoalmente, iria ficar triste se o Sapo fosse comprada pela Google, ou qualquer outra empresa. A identidade da sapo é muito valiosa, tanto financeiramente como culturalmente. o Sapo é nosso. (Disclaimer: eu n trabalho nem nunca trabalhei para o sapo :) , algum do meu afecto pelo Sapo é por termos ambos nascido em Aveiro :) )

  • http://mariz.org Nuno Mariz

    Esta entrada é excelente, obrigado.
    Só fiquei com uma dúvida, usam o lighttpd para ficheiros estáticos e para aplicações?

  • http://Marco.Tondela.org Marco Rodrigues

    Adorei lêr este artigo.. espero que venham mais, talvez mais fazeados, ao invés de ser tudo de uma vês :-)

    A internacionalização do SAPO agora é possível, talvez fosse interessante, começar primeiro pelo países que falam língua Portuguesa, qual será o próximo.. Moçambique, África do Sul, …

    Boa continuação do trabalho!

  • http://www.simplicidade.org Pedro Melo

    Cool stuff, mas conhecendo a equipa, nada de menos se pode esperar.

    Um ponto: o patch do mitico japc para o djbdns não é necessário desde a versão 1.0.4 do software.

    Ele inclui essa funcionalidade builtin. Ver http://cr.yp.to/djbdns/tinydns-data.html (procurar por client location).

    Inté,

  • http://www.marionogueira.com Mário Nogueira

    Excelente artigo, muito informativo. Obrigado pela partilha…

  • http://k.blog.com/ Sérgio Carvalho

    Muitos parabéns pelo artigo. Gostei imenso da espreitadela nos bastidores, pela vertente tecnológica e mais ainda pela visão da cultura interna do Sapo.

    A única sugestão/crítica que vos deixo é a de trabalharem com seriedade a publicação em open-source deste género de coisas — i.e. não ficar pela intenção de lançar mas dedicar mesmo tempo a isso. Faz *muito* pela imagem da empresa e muito pela imagem do país aparecerem produtos informáticos de alta qualidade made-in-portugal. Na atribuição de custos ponham debaixo de “relações públicas” :-)

  • Celso

    Sim. Mas não misturamos.

    Lighty para conteúdo dinâmico funciona muito bem com FastCGI.

    Ver aqui um setup clássico desses:

    http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI

  • http://conversasdobruno.webtuga.net Bruno Miguel

    Seria interessante ver algumas das coisas descritas serem aplicadas no Sapo Blogs. Por exemplo, possibilitar a criação de “plugins” para o serviço por parte dos utilizadores, dentro da plataforma do Sapo.

  • Celso

    Sim mas é bem a mesma coisa e não faz o que queremos. Com este patch usamos a base de dados da GeoIP e portanto é maintnance free, só tens que te referenciar ao País ou à Cidade e não tens que te preocupar com gamas de IP e actualização das mesmas.

  • http://webcracy.org Alexandre Solleiro

    Excelente post, raro e precioso. Muito obrigado.

    Parabéns e sucesso!

  • http://blog.delaranja.com Andre Ribeirinho

    Excelente artigo Celso! Esta é a parte não técnica do SAPO que “justifica” a razão de ser capaz de competir com Googles e Yahoos. Muito bom.

    Tu dizes: “Poucos sites precisarão de um canhão destes, a curva de aprendizagem não é pequena. É impróprio para cardíacos.”
    Eu digo: AMEN. :)

  • http://www.whodesign.com João Ramos

    que grande artigo, este post e depois do que vi no codebits, o sapo ta de parabens.
    Um sapo Department aqui no Norte era sem dúvida a cereja no topo do bolo :)

  • http://blog.invisivel.net Filipe Correia

    Gostei de ler. Boa sorte para os tais maiores vôos :)

  • http://www.liz-online.pt Marcos Pinto

    Antes de mais, queria felicitar-te pelo excelente artigo que nos deste.

    Deliciei-me a ler, e conheci novas coisas no SAPO que até agora desconhecia.

    É bom saber que existe pessoas em terra TUGA a pensar grande e melhor ainda, a fazer grande.
    De vagar se vai ao longe e sem dúvida que os 3 anos de envolvimento intenso neste projecto estão a começar a dar imensos frutos. Muito bem organizado e estruturado.

    O que necessitarem, estamos cá.

    Abraço.

  • http://aindaapensar.blogspot.com Carlos Afonso

    Só uma breve nota. Essa estória de os portugueses só pensarem no rectângulo está algo distorcida. Ou as idas de navegadores no séc. XV e seguintes não contam?

    O nosso problema parece ser que depois não sabemos usar essas idas e passamos a meros estivadores para nações que o souberam fazer.

    Quanto ao conteúdo técnico excelente.

  • http://www.mulder3.net João Serra

    Antes de mais, parabéns pelo exelente artigo!

    Celso, qundo é que vou poder fazer umas brincadeiras com as strings de pesquisa “cuspidas” pelo broker do sapo?

    PErguntei-te isto na Semana Informática do IST, e disseste que estava para breve…

  • http://BUGabundo.net BUGabundo

    Mt bom. la vai mais uma feed.
    gostei mt de ficar a saber q usam o TRAC. akilo e’ excelente.

    ah, eu sou um dos corajosos q usa rsync pra backups.

  • http://dx7lab.com Rafael Dx7

    excelente post! ótimas dicas!

  • http://BUGabundo.net BUGabundo

    mais um pro acordo ortografico.

  • David Mendes

    Este artigo toca mesmo. É uma lufada impressionante de ar fresco e perfumado.
    Nem imaginam como é extraordinário para alguém que, como eu, luta há anos contra os moinhos de vento das corporações engravatadas poder perceber que sempre tivemos razão.
    Os meus agradecimentos, parabéns e votos de muitos sucessos.

  • Tiago Costa

    Grande artigo Celso! E força SAPO!!!

    Nós somos desses corajosos que usam rsync remoto para backups de servers do data center para o nosso escritório – até agora não nos demos mal… e garantimos uma cópia integral off-site.

  • http://www.hotshare.net Guilherme Bufoni

    Olá Celso, muito bom o artigo, já utilizo algumas tecnologias descritas (é bom saber que grandes portais também utilizam :) ) e pretendo testar algumas outras citadas. Foi realmente muito útil.

    Um site muito interessante que fala sobre o assunto:

    http://highscalability.com/

    (Por coincidência um amigo me indicou este link enquanto eu lia este artigo)

    Lá fala sobre a arquitectura do Google, Youtube, Flickr, Amazon e etc…