Facebook Live: vídeo ao vivo para milhões

01 · CONTEXTO

Por que vídeo ao vivo é um problema diferente

Figuras públicas no Facebook podem ter milhões de seguidores tentando assistir ao mesmo vídeo ao mesmo tempo. O post de engenharia chama de thundering herd o caso em que requisições demais atropelam o sistema, causando atraso, interrupções e desconexão do stream.

Segundo a anotação do High Scalability sobre a palestra de Federico Larumbe, o tráfego de vídeo ao vivo é em picos. Vídeos ao vivo aparecem no topo do feed, o que aumenta a chance de serem assistidos, e notificações vão para todos os fãs de cada página. Esse padrão causa problemas nos sistemas de cache e de balanceamento de carga.

Como ordem de grandeza, a mesma anotação cita um vídeo de melancia que chegou a um pico de mais de oitocentos mil espectadores simultâneos.

02 · O CAMINHO DO VÍDEO

Do celular do transmissor ao player

A descrição do High Scalability resume o fluxo em poucos passos: o celular envia um stream RTMP a um servidor de Live Stream, que decodifica o vídeo e o transcodifica para várias taxas de bits; para cada taxa, um conjunto de segmentos MPEG-DASH de um segundo é produzido continuamente.

1. O celular do transmissor envia o vídeo por RTMP a um servidor de Live Stream.

2. O servidor decodifica o vídeo e o transcodifica para várias taxas de bits.

3. Para cada taxa de bits, segmentos de um segundo são produzidos continuamente e guardados num cache do datacenter.

4. Do cache do datacenter, os segmentos seguem para caches localizados em pontos de presença.

5. O player do espectador busca os segmentos num cache de PoP, no ritmo de um por segundo.

A anotação aponta dois fatores de multiplicação. Um fica entre o cache do datacenter e os muitos caches de PoP: os usuários acessam os caches de PoP, não o datacenter. O outro fica dentro de cada PoP, que tem uma camada de proxies HTTP e outra de cache. Segmentos diferentes ficam em caches diferentes, o que ajuda a balancear a carga entre os hosts de cache.

03 · PROTEGENDO A ORIGEM

Caches em camadas e coalescência de pedidos

Em vez de os clientes se conectarem direto ao servidor do stream, existe uma rede de edge caches espalhada pelo mundo. Na implementação descrita no post, o vídeo é dividido em segmentos HLS de três segundos. O pedido de um segmento é tratado por um proxy HTTP num datacenter de borda, que verifica se o segmento está no edge cache; se não está no edge cache, o proxy o pede ao origin cache, outra camada com a mesma arquitetura, e só depois, se faltar, ao servidor do stream.

Segundo o post, mais de 98 por cento dos segmentos já estão num edge cache perto do usuário. Mesmo assim, cerca de 1,8 por cento dos pedidos passavam pelo edge cache, e com um milhão de espectadores isso ainda é um número grande.

1. Players pedem o mesmo segmento, ao mesmo tempo, a proxies HTTP de um datacenter de borda.

2. O edge cache devolve miss só ao primeiro pedido e segura os pedidos seguintes numa fila.

3. Se o segmento falta, o proxy o pede ao origin cache, outra camada de cache com a mesma arquitetura.

4. Se o origin cache também não tem o segmento, o pedido segue ao servidor que cuida daquele stream.

5. O servidor devolve o segmento, que é guardado em cada camada para os clientes seguintes.

6. Os pedidos que estavam na fila são respondidos a partir do edge cache, como hits.

O post chama essa técnica de coalescência de pedidos (request coalescing). Muita gente pede o mesmo segmento ao mesmo tempo, ele pode ainda não estar em cache, e então o edge cache devolve miss ao primeiro pedido e segura os seguintes numa fila. O origin cache roda o mesmo mecanismo para pedidos de vários edge caches, já que o mesmo objeto pode ser pedido por um edge cache em Chicago e por outro em Miami.

A anotação do High Scalability descreve um segundo risco dentro do PoP: se todos os espectadores fossem enviados a um único host de cache para esperar o segmento, esse host poderia sobrecarregar. A solução descrita é uma camada de cache no próprio proxy, de modo que só o primeiro pedido ao proxy chegue ao cache e os seguintes sejam servidos direto por ele.

04 · BALANCEAMENTO GLOBAL

Impedindo que um pico derrube um PoP

Com o datacenter protegido do thundering herd, os PoPs ainda estão em risco. Segundo a anotação, os picos do Live são tão grandes que um PoP pode ficar sobrecarregado antes de a medida de carga chegar ao balanceador global.

Um sistema chamado Cartographer mapeia sub-redes da Internet a PoPs e mede o atraso entre cada sub-rede e cada PoP. A carga de cada PoP vem de contadores nos proxies, agregados por PoP, e cada usuário é enviado ao PoP mais próximo que tenha capacidade suficiente. Isso é um problema de otimização com restrições de capacidade que minimiza a latência.

1. Usuários de muitas sub-redes precisam ser levados a algum PoP; quem decide é o Cartographer.

2. O Cartographer mede o atraso entre cada sub-rede e cada PoP.

3. Contadores nos proxies de cada PoP medem a carga recebida, e eles são agregados para se conhecer a carga de cada PoP.

4. Um estimador de capacidade extrapola a carga anterior e a atual de cada PoP para a carga futura.

5. Cada usuário é enviado ao PoP mais próximo que tenha capacidade suficiente.

Em sistemas de controle há atraso para medir e atraso para reagir. A janela de medição de carga foi reduzida de um minuto e meio para três segundos, mas essa janela continua existindo. A solução descrita é prever a carga antes de ela acontecer: um estimador de capacidade extrapola a carga anterior e a atual de cada PoP para a carga futura.

Para a interpolação, a anotação cita splines cúbicas, que preveem padrões de tráfego mais complexos que a interpolação linear. Tomam-se a primeira e a segunda derivada: velocidade positiva indica carga subindo, e aceleração negativa indica velocidade diminuindo até chegar a zero, quando a carga começa a cair. A interpolação reduz o erro e as oscilações. No momento da palestra, a previsão usava os últimos três intervalos de trinta segundos.

05 · LATÊNCIA

RTMP: empurrar em vez de puxar

Construir o Live para pessoas comuns foi um exercício de reduzir latência. Para chegar a dois a três segundos de transmissão, o Facebook decidiu usar RTMP, um protocolo que mantém uma conexão TCP persistente entre player e servidor durante toda a transmissão.

Segundo o post, o modelo push mais os chunks pequenos reduzem o atraso entre transmissor e espectador em cinco vezes. A maioria dos produtos de live usa HLS por ser baseado em HTTP e fácil de integrar às CDNs existentes; o Facebook implementou RTMP modificando o módulo nginx-rtmp e desenvolvendo um proxy RTMP. A anotação do High Scalability resume o custo: o RTMP exige uma arquitetura nova por não ser baseado em HTTP.

O upload também é um desafio. A anotação toma como exemplo uma banda disponível entre 100 e 300 Kbps, quando o áudio exige 64 Kbps e o vídeo em definição padrão exige 500 Kbps. A taxa de bits do vídeo é ajustada conforme a banda de rede disponível; a decisão é feita no celular, medindo bytes enviados na conexão RTMP e fazendo uma média ponderada dos últimos intervalos.

06 · TESTE E PRÓXIMOS PASSOS

Como validar e para onde evoluir

Para testar, foi construído um serviço de teste de carga distribuído pelos PoPs, que simula tráfego ao vivo e consegue simular dez vezes a carga de produção. Segundo a anotação, ele ajudou a achar problemas no estimador de capacidade, a ajustar parâmetros e a verificar que a camada de cache resolve o thundering herd.

Como direção futura, a anotação cita investigar um mecanismo de push, usando HTTP/2, para empurrar segmentos aos PoPs antes de eles serem pedidos.