As experiências de visualização personalizadas a um nível de 1:1 estão a transformar a experiência da TV. Em vez de um só tamanho, os visualizadores recebem publicidade direcionada e altamente relevante, conteúdo personalizado, recomendações para novos programas e gestão precisa de DRM/blackout, tudo com base no tipo de dispositivo, localização, histórico, dados demográficos e outros dados dos seus visualizadores.
Mas escalar fluxos de vídeo personalizados para milhões de espetadores, especialmente para programação ao vivo, como o desporto, é quase tão desafiador quanto atingir o ciclo do basebol. Os volumes do visualizador podem oscilar descontroladamente, surgindo em centenas de milhares em momentos a não perder, como pontapé de saída, horas extras e durante partidas próximas. Suponhamos que a sua infraestrutura de suporte à personalização não é suficientemente adaptável e escalável. Nesse caso, a sua experiência personalizada será o fim, e todo o seu negócio poderá estar em risco no mundo da OTT.
O papel central do servidor manifesto na personalização
A personalização OTT depende do desempenho do servidor manifesto para gerar uma lista de reprodução única de conteúdo, anúncios e instruções de reprodução. O servidor de manifesto tem que lidar com as seguintes dependências:
- Latência do servidor de anúncios: A comunicação com servidores de anúncios pode adicionar latência que deve ser contabilizada no fluxo de trabalho, especialmente quando vários saltos estão envolvidos.
- Monetização/relatórios: Uma vez que o anúncio é reproduzido, um beacon deve ser enviado de volta para o servidor de anúncios para medir as impressões do anúncio e permitir a monetização.
- Aspectos sem estado da internet – Para que manifestos personalizados funcionem em grande escala, o estado deve ser mantido através de múltiplas solicitações para cada espetador.
- DRM/authentication – O servidor de manifesto deve manter um controle sobre o gerenciamento de direitos digitais (DRM), criptografia em nível de sessão e autenticação.
- Direitos e restrições de conteúdo/blackout – Com base na localização de um utilizador, o conteúdo de streaming pode estar sujeito a várias regras de blackout, todas elas que devem ser geridas com precisão.
- Recomendações de conteúdo: Os espetadores online esperam que os conheçam e personalizem as suas recomendações para os ajudarem durante o processo de pesquisa e descoberta.
- Localização de conteúdo: Para grandes eventos, é fundamental fornecer aos utilizadores variações regionais apropriadas, incluindo faixas de áudio, legendas ocultas e legendas.
Personalizar fluxos em tempo real
Conforme coberto na parte 1 desta série de blogs, um feed ao vivo ou VOD é ingerido, codificado e embalado pela nossa aplicação de software Slicer. Limites de anúncios podem ser inseridos para permitir que os proprietários de conteúdo personalizem a experiência do espetador. À medida que os anúncios são ingeridos, também são processados através de um Slicer a correr na nuvem para uma experiência de reprodução mais semelhante à transmissão.
Quando o Slicer começa a ingerir o fluxo ao vivo ou VOD, comunica continuamente com a nossa infraestrutura de back-end, mantendo a base de dados atualizada sobre quantos segmentos estão disponíveis. Os servidores de manifesto usam esses dados para personalizar a experiência para cada visualizador. Quando um jogador pede um fluxo, o servidor de manifesto determina quais segmentos de vídeo e áudio devem ser listados no arquivo de manifesto, que funciona como uma lista de reprodução. A capacidade de alterar ou personalizar dinamicamente o manifesto a um nível por utilizador torna possível adaptar a experiência de visualização. No caso do vídeo ao vivo, um novo manifesto é pedido a cada poucos segundos, permitindo que os ajustes sejam aplicados dinamicamente por servidores de manifesto à medida que as condições de visualização mudam.
O papel central do servidor manifesto na personalização de fluxos de vídeo
Como mostrado acima, no centro da personalização manifesta está a comunicação. Com a maioria dos requisitos de negócios da OTT, isso significa comunicações com servidores de anúncios para fornecer anúncios personalizados e direcionados em tempo real. Os dados individuais, incluindo o endereço IP, a localização e o tipo de dispositivo de um visualizador – essencialmente todas as informações que podemos capturar enquanto ainda aderimos a regras e regulamentos IPI rigorosos – são fornecidos ao sistema de decisão de anúncios. A solução resultante é robusta o suficiente para aprender o que é relevante para um espetador ao exibir anúncios durante transmissões ao vivo. O sistema também é robusto o suficiente para lidar com desafios como a gestão de restrições e direitos de conteúdo por utilizador, ao mesmo tempo que suporta importantes capacidades de personalização, tais como recomendações de conteúdo e outras localizações.
Arquitetando uma infraestrutura manifesta para escalar
Em nossa plataforma de vídeo, o servidor MANIFEST é responsável por gerar um manifesto de streaming personalizado para cada espetador. Também precisa de estar ciente de outros requisitos acima mencionados, tais como restrições de conteúdo e recomendações. Neste modelo, enviamos um fluxo integrado, o que significa que não há problemas de roda-tampão enquanto os clientes estão à espera que os anúncios sejam carregados no meio do fluxo.
Para construir um sistema de entrega de manifesto resiliente, mantemos grupos de servidores de geração de manifesto na nuvem que estão espalhados por diferentes regiões geográficas em todo o mundo. Nos EUA, por exemplo, esses servidores estão organizados em cinco regiões em todo o país. Quando um pedido de um novo fluxo vem de um jogador baseado nos EUA, esse pedido é roteado aleatoriamente para uma das zonas dos EUA.
O desafio da ‘manada trovejante’
Isto pode parecer contraintuitivo, mas é feito para evitar modos de falha em cascata. A maioria dos telespetadores dos EUA está localizada na parte leste do país. Se os encaminhássemos para a zona mais próxima deles, e o nosso fornecedor de nuvem tivesse tido uma falha nessa região, a maioria dos nossos espetadores experimentaria essa falha. Para agravar o problema, se todos os espetadores atualizarem o fluxo, e agora estamos a direcionar os espetadores para a sua próxima zona saudável mais próxima, experimentaríamos um problema de “rebanho trovejante” em que todos os espetadores da zona falhada agora se amontoam para a próxima zona mais próxima. O pico de tráfego inesperado resultante pode potencialmente causar uma falha secundária até que os nossos sistemas na nova zona possam aumentar para satisfazer a procura adicional.
Em vez disso, distribuir aleatoriamente os nossos telespetadores nos EUA ajuda a atenuar o efeito de qualquer falha inicial e permite-nos distribuir uniformemente o tráfego de falhas para o resto das zonas saudáveis.
Em nossa plataforma de streaming, distribuímos carga de servidor manifesto pelas zonas. Isso evita sobrecarregar qualquer zona específica durante surtos de audiência, especialmente se os visualizadores forem subitamente deslocados para uma zona adjacente durante o failover.
Cada uma das nossas zonas tem um armazenamento de dados separado dedicado ao armazenamento de dados de sessão associados. Uma vez que um visualizador é encaminhado para uma zona, criamos uma sessão para esse visualizador e a guardamos no cluster de sessões da zona. A sessão é um conjunto de dados sobre o visualizador e parâmetros fornecidos pelo cliente sobre como eles gostariam de personalizar a sessão para esse visualizador. Para superar o desafio apresentado pela natureza sem estado da Internet, os servidores de manifesto constroem URLs para cada sessão incluída no manifesto retornados ao jogador. Os pedidos subsequentes do jogador são encaminhados diretamente para a zona onde a sessão do espetador foi criada e armazenada (em vez de ser roteada aleatoriamente para uma das outras zonas).
Como mostrado nos três gráficos abaixo, diferentes eventos podem ter muitos requisitos diferentes dependendo do tamanho do público e se o público é local ou geograficamente disperso. Vejam os três exemplos que ilustram os desafios da infraestrutura que os emissores enfrentam no apoio a eventos ao vivo.
No primeiro cenário, temos um concurso de alimentação de alimentos (sim, temos transmitido ao vivo um destes) porque ilustra um tamanho de público distribuído, mas pequeno. Talvez chegue o dia em que os concursos para comer alimentos se tornarão populares, mas por enquanto continuam a ser um evento de nicho que atrai pequenos números de espetadores em uma ampla geografia. A carga de servidor manifesto é espalhada facilmente por várias zonas e por clusters de servidores manifesto. É aqui que o valor da personalização se torna óbvio, facilitando a inserção de anúncios apropriados para cada região e também a gestão de direitos e apagões.
O cenário muda consideravelmente para os campeonatos estaduais de futebol do Texas, onde um grande número de espetadores está na mesma geografia. Nós lidamos com isso de duas maneiras. Como discutido acima, descobrimos que podemos atribuir visualizadores a servidores de manifesto localizados em zonas fora da geografia imediata sem afetar a experiência do espetador. Além disso, temos um sistema que monitoriza os níveis de audiência em cada zona e pode automaticamente ativar servidores de geração de manifesto, conforme necessário, por zona.
Podemos fazer uma pré-escala com base na audiência esperada para grandes eventos, como as finais da NBA. Ainda assim, tivemos vários eventos em que os nossos sistemas de auto-escala tratavam de quase um milhão de espetadores sem precisar de pré-aquecimento. Além de aumentar a escalabilidade, a capacidade de espalhar instantaneamente a carga entre servidores de manifesto de forma independente de zona melhora significativamente a confiabilidade e a redundância na rede.
Pedidos de jogadores e publicidade
Uma série de mudanças e tendências em toda a indústria estão tornando a escala da nuvem mais importante do que nunca. Um grande condutor é o intervalo de redução entre pedidos do jogador. O nosso pedido de jogador padrão de 8 segundos “What’s Next” linear está a ser conduzido para 5 segundos e pode ser tão breve quanto a cada 2 segundos para fluxos onde a baixa latência é importante. Isso impacta principalmente a utilização da CPU porque o servidor tem que responder a 4x mais solicitações (em intervalos de 2 segundos em comparação com intervalos de 8 segundos). Além disso, o apagão e as recomendações de conteúdo agora também devem ser verificadas com mais frequência do que no passado para evitar erros.
Da mesma forma, o mundo da tecnologia publicitária está a tornar-se mais complexo e exigente. Para cada anúncio inserido num fluxo, um servidor de anúncios terá pelo menos cinco sinalizadores usados para fins de relatórios. É necessária uma solução de inserção de anúncios no lado do servidor (SSAI) para garantir que envia esses beacons para que os seus clientes sejam pagos pelos seus anunciantes. Enquanto cinco balizas são o mínimo, pode haver muito mais. Na verdade, vimos casos em que um único anúncio tem entre 30 e 100 sinalizadores para relatar.
Além disso, redes complexas de servidores de anúncios estão a tornar-se mais comuns nas campanhas dos nossos clientes. Vários saltos de rede de anúncios podem começar a causar problemas de latência. Por exemplo, a rede nº 1 pode dizer, “Aqui está a lista de anúncios neste intervalo”, apenas para descobrir que o anúncio nº 2 nesse intervalo requer uma solicitação para outra rede. O anúncio nº 3 introduz mais dois saltos, e assim por diante.
No exemplo acima, as quebras de anúncios podem duplicar ou triplicar a utilização da CPU. Os pedidos de leitores de vídeo ao vivo podem compor este fator em 10 a 30%.
Looking Ahead – microsserviços e escalabilidade
Com a complexidade aumentando, uma das etapas que tomamos é separar as diferentes cargas de trabalho tratadas anteriormente pelos servidores de manifesto em microsserviços menores. O primeiro passo que fizemos é mover as comunicações do servidor de anúncios e o beaconing para o seu próprio serviço, ajudando a lidar com o desafio da latência do servidor de anúncios. Este serviço de proxy de anúncios oferece vários recursos avançados que discutiremos mais profundamente em um próximo post no blog.
No futuro, continuaremos a desenvolver outros microsserviços para remover mais trabalho dos servidores de manifesto e oferecer uma abordagem mais direcionada para a escalabilidade. Em breve, adicionaremos zonas de vários fornecedores de nuvem para nos tornarmos resilientes às falhas de qualquer um.
Ao acoplar o SSAI escalável com microsserviços, podemos otimizar os custos do servidor, a estrutura da nossa base de código e outras caraterísticas específicas do tráfego de anúncios. Além disso, podemos superar vários desafios principais, incluindo latência do servidor de anúncios, restrições de blackout e monetização. Ao mesmo tempo, ao espalhar a carga de processamento em várias zonas, o nosso serviço de transmissão de vídeo ao vivo pode ser dimensionado de forma ampla e superar desafios chave, permitindo-nos entregar de forma confiável milhões de fluxos personalizados simultâneos sem sobrecarregar a nossa rede de entrega.
