A CDN de 90 dólares por mês

A conta que não fechava

Em 2014 eu era CIO da ATMO, uma empresa de mídia digital em São Paulo. A gente tinha telas em lojas e em eventos, e todo player baixa os vídeos de algum lugar. Vídeo é pesado, os players pedem o tempo todo, e uma CDN comercial cobra por gigabyte. Para uma empresa do nosso tamanho, a conta não fechava.

Na mesma época a DigitalOcean vendia o droplet mais simples por US$5 por mês, e esse droplet vinha com 1 TB de tráfego incluído. A maioria das pessoas via ali um servidor barato. O que me chamou a atenção foi o terabyte, porque tráfego era justamente o que a gente pagava caro.

Então a primeira versão nasceu na ATMO, em 2014 e 2015. Alguns droplets baratos servindo arquivo com nginx, a banda já paga no preço da máquina, scripts de sincronização meus e uma tabela no banco dizendo qual arquivo está onde. Era pequena. Mas a ideia inteira já estava lá.

Versão dois, dezoito droplets

No fim de 2015 fundei a helloo com meus sócios, uma empresa de mídia, e construí a tecnologia dela do zero. O mesmo problema voltou, bem maior: players em elevadores e shoppings, numa rede que não parou de crescer (hoje tem cerca de 15 mil telas). Não aproveitei o código antigo. Escrevi a CDN de novo do zero, com a mesma ideia de base, e essa versão foi muito além da primeira.

Agora o problema era o disco: um droplet de US$5 tinha um SSD pequeno, e não dava para colocar a biblioteca inteira em cada nó.

Por isso dividi a biblioteca por conteúdo. A montagem de que eu mais me lembro tinha 18 droplets em 6 grupos de 3. Cada grupo guardava uma fatia da biblioteca, e dentro do grupo os três nós tinham os mesmos arquivos. Cai um nó, sobram dois servindo. Um arquivo mora num grupo só, então um grupo novo acrescenta disco, e um nó novo num grupo acrescenta banda e redundância para aquela fatia.

A parte da história de que as pessoas gostam é a conta: 18 × US$5 = US$90 por mês, com 18 TB de tráfego incluídos, e essa era a camada de distribuição inteira dos players da helloo.

A parte que dá trabalho

Ninguém vende a sincronização, e era aí que estava o trabalho. Escrevi scripts que empurram um arquivo novo para os três nós do grupo dele, conferem se chegou e gravam isso numa tabela no banco. O player só recebe a URL de um arquivo depois que as cópias estão confirmadas, então ele nunca pede a um nó uma coisa que ainda não está lá.

Não tenho mais esses scripts. Se eu escrevesse a tabela de controle hoje, ela seria assim:

tabela de controle, versão de hoje

CREATE TABLE cdn_copy (
    content_id  INT UNSIGNED NOT NULL,
    node        VARCHAR(32)  NOT NULL,   -- ex.: g4-b
    synced_at   DATETIME     NULL,       -- NULL = ainda copiando
    PRIMARY KEY (content_id, node)
);

-- um conteúdo só é publicado quando o grupo inteiro tem a cópia
SELECT content_id
FROM cdn_copy
GROUP BY content_id
HAVING COUNT(*) = 3 AND COUNT(synced_at) = 3;

Depois vêm os trabalhos chatos: checar se um nó ainda responde e ainda tem disco livre, mudar um grupo de lugar quando uma fatia cresce demais e limpar os arquivos que nenhuma campanha usa mais. Esse último eu subestimei por um tempo; disco enche em silêncio e você descobre no pior dia.

Quando eu faria de novo

Minha opinião é a mesma daquela época: para projeto com orçamento curto, esse tipo de coisa ainda vale a pena. Só dá trabalho. Você vira o fornecedor da CDN, o plantão e a pessoa que lembra por que o grupo 4 tem um disco esquisito, e esse custo é real mesmo sem aparecer na fatura.

Com dinheiro em caixa e um time ocupado com o produto, eu pagaria uma CDN comercial sem pensar duas vezes. Com orçamento apertado, uma biblioteca previsível e alguém que gosta de operar, dezoito máquinas pequenas deram conta por anos.

Se for levar uma coisa sóLeia o que vem incluído no preço. Aqui o servidor era a parte barata, e o 1 TB de tráfego era o produto.

Arquivado pelo problema que resolve