Streaming de música (Spotify)

01 · CONTEXTO

Música sob demanda com cliente e pares

Spotify é um serviço de streaming de música sob demanda. O artigo técnico que serve de base a este caso descreve um serviço que entrega a música por uma combinação de acesso cliente-servidor e um protocolo par a par (peer-to-peer). Na época, a biblioteca tinha mais de 8 milhões de faixas e o serviço estava no ar desde outubro de 2008.

A razão principal para criar o protocolo par a par foi escalar o serviço, diminuindo a carga nos servidores e o uso de banda. Havia uma condição explícita: o par a par não podia piorar a latência para começar a música nem aumentar as interrupções (stutter) durante a reprodução.

Os clientes de smartphone da época não participavam do protocolo par a par e recebiam o áudio apenas dos servidores.

02 · DO TOQUE AO SOM

O caminho de uma faixa até o ouvido

Quando a pessoa escolhe uma faixa que o cliente ainda não tem, o cliente faz um pedido inicial ao servidor por cerca de 15 segundos de música, pela conexão TCP que já estava aberta, e ao mesmo tempo procura outros clientes que possam servir a faixa. Se a faixa já está no cache local, ela não precisa ser baixada de novo.

1. Se a faixa já está no cache local, o cliente não precisa baixá-la de novo.

2. Sem a faixa em cache, o cliente faz um pedido inicial ao servidor por cerca de 15 segundos de música, pela conexão que já estava aberta.

3. Ao mesmo tempo, o cliente procura pares que tenham a faixa. O rastreador mantém um mapa de faixas para pares e responde com uma lista limitada de pares que estão online.

4. Com os pares encontrados, o cliente baixa dados deles. Enquanto o buffer está suficientemente cheio e há pares, o cliente baixa apenas da rede de pares.

5. Se o buffer fica baixo, o cliente pede dados ao servidor, cuja conexão é tida como mais confiável que a dos pares.

6. O que o cliente baixa costuma ficar no cache local. O cliente só se oferece para servir aos pares as faixas que tem completas em cache.

A decisão de onde baixar é local: cada cliente olha a quantidade de dados no próprio buffer de reprodução. Ao baixar do servidor, o cliente limita os pedidos para não passar de cerca de 15 segundos à frente do ponto de reprodução, quando há pares disponíveis para a faixa.

Com esses números, o artigo conclui que caches grandes e rede de pares juntos diminuem de forma significativa a carga dos servidores. A contagem inclui dados baixados mesmo que a faixa não chegue a tocar.

03 · LATÊNCIA E PREFETCH

Começar rápido: prefetch, buffer e cache

Duas medidas importantes em streaming sob demanda são o tempo até começar a tocar e a frequência de interrupções. Olhando a primeira: na semana medida (de 23 a 29 de março de 2010), a latência mediana foi de 265 ms, o percentil 75 foi de 515 ms e o percentil 90 foi de 1047 ms. Como mais da metade dos dados veio do cache, o artigo considera provável que a mediana meça o tempo de DRM mais o processamento local.

O artigo observa que mesmo um material totalmente em cache precisa esperar uma resposta pela rede antes de tocar, a menos que a faixa tenha sido sincronizada para uso offline. Por isso a latência quase sempre inclui pelo menos um RTT até os servidores.

Para a faixa seguinte, o cliente faz prefetch. Ele começa a procurar pares e a baixar a faixa seguinte quando restam 30 segundos ou menos da faixa atual; com 10 segundos ou menos, busca no servidor o começo da próxima, se precisar. O ajuste tem custo: prefetch tardio pode não bastar para a próxima faixa tocar de imediato, e prefetch cedo demais desperdiça banda se a pessoa escolher outra faixa.

Durante algumas semanas, um defeito desativou por acaso o prefetch da faixa seguinte em todos os clientes, o que permitiu medir o efeito do prefetch.

04 · ACHAR QUEM TEM A FAIXA

Rastreador, busca na vizinhança e dois sites

O rastreador (tracker) mantém um mapa de faixas para os pares que reportaram ter a faixa há pouco. Ele guarda só os 20 pares mais recentes de cada faixa e responde com até 10 pares que estejam online.

Os clientes entram no rastreador quando tocam uma faixa, sem reportar periodicamente o conteúdo do cache. Além do rastreador, o cliente envia a busca aos vizinhos, que a repassam aos vizinhos deles; assim, todos os pares até a distância dois do cliente veem o pedido. Esse repasse limitado é o único roteamento da rede de pares.

O Spotify não usou uma tabela hash distribuída (DHT) para achar pares. O artigo aponta que baixar faixas novas é uma operação frequente e o tempo de busca vira um problema grande; entre os outros motivos estão manter o protocolo simples e o custo baixo.

O serviço rodava de dois centros de dados, um em Londres e outro em Estocolmo. O cliente sorteia de forma uniforme a qual deles se conectar, e a carga fica distribuída por igual.

1. Ao conectar, o cliente escolhe ao acaso, de forma uniforme, um dos dois centros de dados.

2. Cada centro de dados tem uma rede de pares independente.

3. A separação não é completa: ao reconectar ao outro site, o cliente mantém os pares antigos, mas não consegue fazer novas conexões com pares ligados ao site antigo.

05 · OS LIMITES DO DESENHO

Popularidade, NAT e o que os pares não cobrem

O acesso às faixas é concentrado: na semana medida, 88% dos acessos ficaram nos 12% mais populares da biblioteca. Ainda assim, cerca de 60% do conteúdo disponível foi acessado ao menos uma vez na semana. Os pedidos que chegam aos servidores são menos concentrados: 79% dos acessos nos 21% mais populares, em um gráfico que usa dados de fevereiro de 2010, fora do período de medição.

A rede de pares tem limites práticos. Os clientes não fazem travessia de NAT, e a fração de conexões bem-sucedidas foi de 35% na semana medida. Para ajudar, o pedido de conexão também passa pelo servidor, que pede ao outro lado que tente conectar de volta, e os clientes usam UPnP para pedir uma porta ao roteador doméstico.

06 · A ENTRADA DO CONTEÚDO

Do upload ao catálogo: um incidente de podcasts em vídeo

Até aqui o caso tratou da entrega do áudio; a entrada do conteúdo é outro caminho do sistema. Segundo um relatório público de incidente do Spotify, quando uma pessoa criadora de podcast publica um episódio, o áudio e o vídeo passam por uma série de etapas de processamento antes de ficarem disponíveis aos usuários, entre elas a transcodificação (converter a mídia nos formatos que os aplicativos precisam) e a análise de conteúdo.

O relatório trata de um atraso de publicação em 24 de junho. A infraestrutura de transcodificação de vídeo chegou à capacidade máxima e um backlog atrasou a publicação de episódios em vídeo por várias horas. O texto menciona duas filas: a de prioridade média, usada para episódios novos, e a de baixa prioridade, usada para atualizações de episódios antigos.

1. A pessoa criadora publica um episódio novo, que entra na fila de prioridade média, usada para episódios novos.

2. Em períodos típicos, a transcodificação conseguia escalar para atender tanto a transcodificação de baixa prioridade quanto a publicação de conteúdo novo.

3. Uma tarefa em lote de rotina, que reprocessa episódios existentes, consumia capacidade adicional ao lado do processamento regular dos episódios novos, e a transcodificação rodava sem folga suficiente para grandes picos.

4. A infraestrutura chegou à capacidade máxima e as filas acumularam: episódios que normalmente saem em minutos atrasaram por horas.

5. Alguns criadores reenviaram episódios que não apareciam, o que aumentou a carga. O relatório reconhece que o sistema deveria ter confirmado que o upload foi recebido e enfileirado.

6. O relatório conta cerca de quatro horas entre os primeiros alertas e a resposta formal ao incidente.

Entre os passos já tomados, o relatório lista aumentar a capacidade de transcodificação em cerca de 67%, corrigir o bug de agendamento e melhorar o monitoramento para alertar mais cedo quando a capacidade se aproxima do limite.

O programa de confiabilidade em curso inclui planejar a capacidade para picos e recuperação de incidentes, e não só para o tráfego estável; priorizar o conteúdo em tempo real dos criadores à frente de operações de fundo; e estender limitação de taxa e backpressure ao longo do pipeline.