Home Artigos técnicos Como obter pessoal com milhões ao escalar a manipulação de manifesto
Applications

Como obter pessoal com milhões ao escalar a manipulação de manifesto

About The Author

Outline

As experiências de visualização personalizadas a um nível de 1:1 estão a transformar a experiência de televisão. Em vez de um tamanho único, os espetadores recebem publicidade direcionada e altamente relevante, conteúdo personalizado, recomendações para novos programas e gerenciamento preciso de DRM/blackout, tudo com base no tipo de dispositivo, localização, histórico, dados demográficos e outros dados de seus espetadores.

Mas escalar fluxos de vídeo personalizados para milhões de espetadores, especialmente para programação ao vivo, como esportes, é quase tão desafiador quanto bater para o ciclo no beisebol. Os volumes do visualizador podem oscilar descontroladamente, surgindo em centenas de milhares em momentos imperdíveis, como pontapé inicial, horas extras e durante partidas próximas. Suponha que sua infraestrutura para suporte à personalização não seja adaptável e escalável o suficiente. Nesse caso, sua experiência personalizada será o game over, e todo o seu negócio pode estar em risco no mundo da OTT.

A função central do servidor manifesto na personalização

A personalização OTT depende do desempenho do servidor manifesto para gerar uma lista de reprodução exclusiva 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(s) servidor(es) 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 escala, o estado deve ser mantido em várias solicitações para cada visualizador.
  • DRM/authentication (DRM/authentication ) – O servidor de manifesto deve manter um controle sobre o gerenciamento de direitos digitais (DRM), criptografia no nível da sessão e autenticação.
  • Direitos e restrições de conteúdo/blackout – Com base na localização de um usuário, o conteúdo de streaming pode estar sujeito a várias regras de blackout, todas as quais devem ser gerenciadas com precisão.
  • Recomendações de conteúdo: Os espetadores on-line esperam que você os conheça e personalize suas recomendações para ajudá-los no processo de pesquisa e descoberta.
  • Localização de conteúdo – Para grandes eventos, é fundamental fornecer aos usuários variações regionais apropriadas, incluindo faixas de áudio, legendas e legendas.

Personalizando fluxos em tempo real

Conforme coberto na parte 1 desta série de blogs, um feed ao vivo ou VOD é ingerido, codificado e embalado por nosso aplicativo de software Slicer. Limites de anúncios podem ser inseridos para permitir que os proprietários de conteúdo personalizem a experiência do visualizador. À medida que os anúncios são ingeridos, eles também são processados através de um Slicer em execução na nuvem para uma experiência de reprodução mais semelhante a broadcast.

Quando o Slicer começa a ingerir o fluxo ao vivo ou VOD, ele se comunica continuamente com nossa infraestrutura de back-end, mantendo o banco de dados atualizado sobre quantos segmentos estão disponíveis. Servidores de manifesto usam esses dados para personalizar a experiência para cada visualizador. Quando um player solicita um stream, o servidor de manifesto determina quais segmentos de vídeo e áudio devem ser listados no arquivo de manifesto, que atua como uma lista de reprodução. A capacidade de alterar ou personalizar dinamicamente o manifesto em um nível por usuário torna possível personalizar a experiência de visualização. No caso de vídeo ao vivo, um novo manifesto é solicitado a cada poucos segundos, permitindo que os ajustes sejam aplicados dinamicamente pelos servidores de manifesto à medida que as condições de visualização mudam.

A função central do servidor manifesto na personalização de fluxos de vídeo

Como mostrado acima, no centro da personalização de manifesto está a comunicação. Com a maioria dos requisitos comerciais 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 visualizador ao fornecer anúncios durante transmissões ao vivo. O sistema também é robusto o suficiente para lidar com desafios como o gerenciamento de restrições de blecaute e direitos de conteúdo por usuário, ao mesmo tempo em que suporta recursos de personalização importantes, como recomendações de conteúdo e outras localizações.

Arquitetando a infra-estrutura de manifesto para escalar

Em nossa plataforma de vídeo, o servidor MANIFEST é responsável por gerar um manifesto de streaming personalizado para cada visualizador. Ele também precisa estar ciente de outros requisitos mencionados acima, 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 de buffer” enquanto os clientes estão esperando que os anúncios sejam carregados no meio do fluxo.

Para criar um sistema de entrega de manifesto resiliente, mantemos clusters 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 são organizados em cinco regiões em todo o país. Quando uma solicitação de um novo stream vem de um jogador baseado nos EUA, essa solicitação é roteada aleatoriamente para uma das zonas dos EUA.

O desafio do “rebanho trovejante”

Isso pode parecer contra-intuitivo, mas é feito para evitar modos de falha em cascata. A maioria dos telespetadores dos EUA está localizada nas partes leste do país. Se nós os encaminhássemos para a zona mais próxima deles, e nosso provedor de nuvem experimentasse uma falha nessa região, a maioria de nossos espetadores experimentaria essa falha. Para agravar o problema, se todos esses espetadores atualizarem o fluxo, e agora estamos direcionando os espetadores para a próxima zona saudável mais próxima, experimentaríamos um problema de “rebanho trovejante”, onde todos os espetadores da zona falhada agora se enredam para a próxima zona mais próxima. O pico de tráfego inesperado resultante pode potencialmente causar uma falha secundária até que nossos sistemas na nova zona possam escalar para atender a demanda adicional.

Em vez disso, distribuir aleatoriamente nossos telespetadores nos EUA ajuda a mitigar o efeito de qualquer falha inicial e nos permite distribuir uniformemente o tráfego de failover para o resto das zonas saudáveis.

Em nossa plataforma de streaming, distribuímos carga de servidor manifesto entre zonas. Isso evita sobrecarregar qualquer zona específica durante picos de público, especialmente se os espetadores forem subitamente transferidos para uma zona adjacente durante o failover.

Cada uma de nossas zonas tem um armazenamento de dados separado dedicado ao armazenamento de dados de sessão associados. Uma vez que um visualizador é roteado para uma zona, criamos uma sessão para esse visualizador e a guardamos no cluster de sessão da zona. A sessão é um monte 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 criam URLs para cada sessão incluída no manifesto retornou ao player. As solicitações subsequentes do jogador são encaminhadas diretamente para a zona onde a sessão do espetador foi criada e armazenada (em vez de 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. Dê uma olhada nos três exemplos que ilustram os desafios de infraestrutura enfrentados pelas emissoras no apoio a eventos ao vivo.

No primeiro cenário, temos um concurso de alimentação de alimentos (sim, temos transmitido ao vivo um deles) porque ilustra um tamanho de público distribuído, mas pequeno. Talvez chegue o dia em que os concursos de alimentação de alimentos se tornarão mainstream, mas por enquanto, eles continuam sendo 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 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 sendo capaz de gerenciar 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 algumas 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 monitora os níveis de audiência em cada zona e pode automaticamente girar servidores de geração de manifesto conforme necessário em uma base por zona.

Podemos pré-escalar com base na audiência esperada para grandes eventos, como as finais da NBA. Ainda assim, tivemos vários eventos em que nossos sistemas de autoescala lidaram com quase um milhão de espetadores sem exigir nenhum 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 em toda a rede.

Pedidos do jogador e anúncio beaconing

Uma série de mudanças e tendências em todo o setor estão tornando a escalabilidade da nuvem mais importante do que nunca. Um grande condutor é o intervalo de redução entre as solicitações do jogador. Nosso pedido padrão de jogador “What’s next” linear de 8 segundos está sendo conduzido para 5 segundos e pode ser tão breve quanto a cada 2 segundos para fluxos onde a baixa latência é importante. Isso afeta majoritariamente 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, as recomendações de conteúdo e blecaute 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á se tornando mais complexo e exigente. Para cada anúncio inserido em um stream, um servidor de anúncios terá pelo menos cinco beacons usados para fins de relatório. Uma solução de inserção de anúncios no lado do servidor (SSAI) é necessária para garantir que ele envie esses beacons para que seus clientes sejam pagos por seus anunciantes. Enquanto cinco beacons são o mínimo, pode haver muito mais. Na verdade, vimos casos em que um único anúncio tem entre 30 e 100 beacons para relatar.

Além disso, redes complexas de servidores de anúncios estão se tornando mais comuns nas campanhas de 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. Solicitações de player de vídeo ao vivo podem compor esse fator em 10 a 30%.

‍Looking Ahead – microsserviços e escalabilidade

Com o aumento da complexidade, 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 enfrentar 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 em mais profundidade 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 à escalabilidade. Em breve, adicionaremos zonas de vários provedores de nuvem para se tornar resilientes às falhas de qualquer um.

Ao acoplar o SSAI escalável com microsserviços, podemos otimizar os custos do servidor, a estrutura de nossa base de código e outras caraterísticas específicas para o 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 blecaute e monetização. Ao mesmo tempo, ao espalhar a carga de processamento em várias zonas, nosso serviço de streaming de vídeo ao vivo pode escalar amplamente e superar os principais desafios, permitindo-nos entregar de forma confiável milhões de fluxos personalizados simultâneos sem sobrecarregar nossa rede de entrega.