Hotstar: 25 milhões de espectadores simultâneos

01 · CONTEXTO

Um recorde de audiência ao vivo

O Hotstar é um serviço de streaming (OTT) da Disney. Segundo o relato de uma palestra do AWS re:Invent, ele chegou em 10 de julho de 2019 a 25,3 milhões de espectadores simultâneos, superando o recorde anterior do próprio serviço, de 18,6 milhões. O pico foi no jogo Índia x Nova Zelândia da Copa do Mundo de críquete de 2019.

Já em abril de 2018, o blog de engenharia da empresa descrevia a preparação para o IPL, o grande evento do ano do Hotstar. Os dois relatos, o post de 2018 e o resumo da palestra de 2019, defendem escalar antes do evento em vez de reagir a ele.

02 · O PROBLEMA

Notificação, pico e sobrecarga

O post descreve um padrão que a plataforma antiga enfrentava repetidamente: quando algo interessante acontecia no jogo, uma notificação era enviada, e o pico de tráfego resultante sobrecarregava os sistemas de back-end e, às vezes, atrapalhava a renderização do vídeo. O time diz ter aprendido a lidar com esses tsunamis do jeito difícil.

1. Algo interessante acontece no jogo e o serviço de notificações avisa os apps.

2. O pico de tráfego resultante chega ao back-end.

3. O pico sobrecarrega os sistemas de back-end.

4. Às vezes a sobrecarga chega a atrapalhar a renderização do vídeo.

Reenvios automáticos agravam o quadro. Por isso o post pede clientes que inferem quando algo está errado e adicionam jitter aos pedidos que fazem aos servidores.

03 · PRÉ-ESCALA

Por que não confiar no autoscaling

A primeira lição do post é dar folga de capacidade em vez de contar com autoscaling. Pelo tempo que o autoscaling leva para agir, ele é inútil para lidar com picos; a estratégia é estimar a concorrência de pico e subir a capacidade antes do evento.

O autoscaling não some do desenho: o post o usa para manter o número certo de servidores no pool, mas a frota já está escalada para o pico. Quando a equipe ultrapassa os limiares de folga, definidos depois dos testes de escala, ela sobe mais capacidade em antecipação.

O resumo da palestra repete a tese: o autoscaling tradicional não funciona para o Hotstar. Os slides listam como motivos os erros de capacidade insuficiente, um único tipo de instância por grupo de autoescala e o tamanho do passo do grupo. O post acrescenta que o provedor de nuvem também tem limites físicos de quanto dá para escalar automaticamente, e que é preciso trabalhar com ele e projetar a capacidade com antecedência.

Escalar antes da hora inclui, segundo as práticas listadas nos slides: pré-aquecer a infraestrutura antes do jogo, escalar por contagem de requisições ou pela concorrência da plataforma, fazer escala proativa e automatizada com base na concorrência e usar uma frota spot de EC2 com tipos de instância diversificados. Perguntado sobre qual seria a alternativa ao autoscaling tradicional, a resposta registrada foi um script Python comum.

1. Antes do jogo, a equipe estima o pico de concorrência e sobe a frota para essa capacidade.

2. Durante o jogo, a contagem de requisições e a concorrência da plataforma viram métricas.

3. Se a folga definida nos testes é ultrapassada, o script de escala sobe mais capacidade em antecipação.

4. Cache na camada de serviço e TTLs no cliente tiram tráfego da origem e dão folga à frota.

Os slides sob o título Race against time listam uma taxa de crescimento de mais de 1M por minuto, um tempo de boot da aplicação na casa de um minuto, 90 segundos de tempo de reação, notificações push e AMIs totalmente pré-montadas.

04 · PROTEGER E DEGRADAR

Origem protegida, cliente esperto

O post divide a plataforma em três pilares: o motor de assinatura, o de metadados e a infraestrutura de streaming. Cada um tem necessidades de escala próprias e foi ajustado separadamente, com modelos de tráfego pessimistas e escadas (ladders) que controlavam as frotas conforme a concorrência estimada.

O funil tem um limite externo: o Hotstar depende das taxas de processamento dos parceiros de pagamento, e por isso, às vezes durante um pico, pode adicionar jitter ao funil para os clientes avançarem a uma taxa aceitável.

No cliente, os apps foram construídos para ser resilientes e degradar com elegância. Chaves de pânico na infraestrutura indicam aos apps que aliviem os pedidos por um momento, com backoff exponencial ou, às vezes, personalizado, o que dá ao back-end tempo para se recuperar. A função primária é preservada: funções específicas podem degradar sem afetá-la.

1. O diagrama mostra o app e os serviços de vídeo, de assinatura e pagamento e de recomendações.

2. Quando a carga foge do controle, as chaves de pânico sinalizam ao app que alivie os pedidos.

3. O app reduz o ritmo com backoff, exponencial ou personalizado, e o back-end ganha tempo para se recuperar.

4. Recomendações e personalização são desligadas de propósito para proteger o que é crítico.

5. Streaming de vídeo e pagamento, os componentes críticos, seguem de pé.

05 · ENSAIAR A FALHA

Teste de carga, game days e caos

Para testar a escala, o post cita o uso de Flood.io sobre Gatling. O time também fez game days, simulações de um evento real do IPL antes de ele acontecer. Elas serviram para ajustar configurações e treinar a operação, e revelaram comportamentos em escala ligados a handshakes SSL, keep-alives e descasamentos entre AZs ou regiões.

Além da carga simulada, o time fez testes de caos (engenharia do caos), que simulavam vários cenários de indisponibilidade para ver como o sistema reagia e se recuperava. Entre os ingredientes de caos listados na palestra estão tráfego em tsunami, escala atrasada, restrições de banda, aumento de latência e falha de rede (CDN).

A palestra também apresenta o Hulk, uma ferramenta de geração de carga usada para preparar a plataforma para um pico de 50M. Nos testes de caos, o que se busca é o ponto de ruptura de cada sistema, além de gargalos e pontos de estrangulamento.

Sobre telemetria, o post conta que deu trabalho obter uma visão unificada das métricas importantes para decidir.

06 · LIÇÕES E LIMITES

O que levar para a entrevista

A palestra fecha com três lições: preparar-se para falhas, entender a jornada do usuário e aceitar degradar com elegância.

O post acrescenta o princípio de garantir que a função primária sempre funcione e de proteger os pontos de contato com o servidor. Nem toda falha é fatal, e cache com TTL adequado compra muita folga.