Home Articles techniques Comment obtenir personnel avec des millions en mettant à l’échelle la manipulation manifeste
Applications

Comment obtenir personnel avec des millions en mettant à l’échelle la manipulation manifeste

About The Author

Outline

Des expériences de visionnage personnalisées à un niveau 1:1 transforment l’expérience TV. Au lieu d’une solution unique, les téléspectateurs bénéficient de publicités ciblées et très pertinentes, de contenus personnalisés, de recommandations pour de nouveaux programmes et d’une gestion DRM/blackout précise, le tout en fonction du type d’appareil, de l’emplacement, de l’historique, des données démographiques et d’autres données de vos téléspectateurs.

Mais la mise à l’échelle de flux vidéo personnalisés pour des millions de téléspectateurs, en particulier pour les émissions en direct comme le sport, est presque aussi difficile que de frapper pour le cycle du baseball. Les volumes des visionneuses peuvent osciller de manière spectaculaire, augmentant de centaines de milliers aux moments incontournables tels que le coup d’envoi, les heures supplémentaires et les matchs rapprochés. Supposons que votre infrastructure de prise en charge de la personnalisation ne soit pas suffisamment adaptable et évolutive. Dans ce cas, votre expérience personnalisée sera finie, et toute votre entreprise pourrait être en danger dans le monde de OTT.

Le rôle central du serveur manifeste dans la personnalisation

La personnalisation OTT dépend de la performance du serveur manifeste pour générer une liste de lecture unique de contenu, de publicités et d’instructions de lecture. Le serveur manifest doit faire face aux dépendances suivantes :

  • Latence du serveur publicitaire — la communication avec les serveurs publicitaires peut ajouter une latence qui doit être prise en compte dans le flux de travail, en particulier lorsque plusieurs sauts sont impliqués.
  • Monétisation/reporting : une fois la publicité diffusée, une balise doit être renvoyée au(x) serveur(s) publicitaire(s) pour mesurer les impressions publicitaires et permettre la monétisation.
  • Aspects stateless d’Internet — pour que les manifestes personnalisés fonctionnent à grande échelle, l’état doit être maintenu sur plusieurs demandes pour chaque spectateur.
  • DRM/authentification : le serveur manifeste doit garder un œil sur la gestion des droits numériques (DRM), le cryptage au niveau de la session et l’authentification.
  • Droits et restrictions de blackout/contenu — en fonction de l’emplacement de l’utilisateur, le contenu en streaming peut être soumis à diverses règles de blackout, qui doivent toutes être gérées avec précision.
  • Recommandations de contenu — les internautes attendent de vous que vous les connaissiez et que vous personnalisiez vos recommandations pour les aider dans le processus de recherche et de découverte.
  • Localisation de contenu — pour les événements majeurs, il est essentiel de fournir aux utilisateurs des variations régionales appropriées, y compris des pistes audio, des sous-titres codés et des sous-titres.

Personnalisation des flux en temps réel

Comme indiqué dans la partie 1 de cette série de blogs, un flux en direct ou VOD est ingéré, encodé et emballé par notre application logicielle Slicer. Des limites publicitaires peuvent être insérées pour permettre aux propriétaires de contenu de personnaliser l’expérience du spectateur. Au fur et à mesure que les publicités sont ingérées, elles sont également traitées via un Slicer exécuté dans le cloud pour une expérience de lecture plus semblable à celle de la diffusion.

Lorsque le Slicer commence à ingérer le flux en direct ou VOD, il communique continuellement avec notre infrastructure dorsale, en tenant la base de données à jour sur le nombre de segments disponibles. Les serveurs Manifest utilisent ces données pour personnaliser l’expérience de chaque spectateur. Lorsqu’un joueur demande un flux, le serveur de manifeste détermine quels segments vidéo et audio doivent être listés dans le fichier manifeste, qui agit comme une liste de lecture. La possibilité de modifier ou de personnaliser dynamiquement le manifeste au niveau de chaque utilisateur permet d’adapter l’expérience de visualisation. Dans le cas de la vidéo en direct, un nouveau manifeste est demandé toutes les quelques secondes, ce qui permet aux serveurs de manifestes d’appliquer des ajustements dynamiquement à mesure que les conditions de visionnement changent.

Le rôle central du serveur manifeste dans la personnalisation des flux vidéo

Comme indiqué ci-dessus, au cœur de la personnalisation manifeste se trouve la communication. Avec la plupart des exigences commerciales OTT, cela signifie des communications avec les serveurs publicitaires pour fournir des publicités ciblées et personnalisées en temps réel. Les données individuelles, y compris l’adresse IP du spectateur, son emplacement et le type d’appareil – essentiellement toutes les informations que nous pouvons capturer tout en respectant les règles et réglementations strictes en matière de PII – sont fournies au système de décision publicitaire. La solution résultante est suffisamment robuste pour apprendre ce qui est pertinent pour un spectateur lors de la diffusion de publicités pendant des flux en direct. Le système est également suffisamment robuste pour faire face à des défis tels que la gestion des restrictions de blackout et des droits de contenu par utilisateur, tout en prenant en charge d’importantes capacités de personnalisation telles que les recommandations de contenu et d’autres localisations.

Architecture de l’infrastructure Manifest à l’échelle

Dans notre plateforme vidéo, le serveur Manifest est responsable de générer un manifeste de streaming personnalisé pour chaque spectateur. Il doit également être conscient des autres exigences mentionnées ci-dessus, telles que les restrictions de contenu et les recommandations. Dans ce modèle, nous envoyons un flux intégré, ce qui signifie qu’il n’y a pas de problèmes de « roue tampon » pendant que les clients attendent que les annonces se chargent au milieu du flux.

Pour construire un système de distribution de manifestes résilient, nous maintenons des clusters de serveurs de génération de manifestes dans le cloud qui sont répartis dans différentes régions géographiques à travers le monde. Aux États-Unis, par exemple, ces serveurs sont organisés en cinq régions à travers le pays. Lorsqu’une demande de nouveau flux provient d’un joueur basé aux États-Unis, cette demande est acheminée aléatoirement vers l’une des zones américaines.

Le défi du « troupeau tonitruant »

Cela peut sembler contre-intuitif, mais il est fait pour éviter les modes de défaillance en cascade. La majorité des téléspectateurs américains se trouvent dans les régions orientales du pays. Si nous les acheminions tous vers la zone la plus proche d’eux, et que notre fournisseur de cloud a rencontré un échec dans cette région, la majorité de nos téléspectateurs subiraient cet échec. Aggravant le problème, si tous ces téléspectateurs rafraîchissent le flux, et que nous dirigeons maintenant les téléspectateurs vers leur prochaine zone saine la plus proche, nous connaîtrions un problème de «troupeau tonitruant» où tous les téléspectateurs de la zone défaillante maintenant dogpile vers la prochaine zone la plus proche. Le pic de trafic inattendu qui en résulte pourrait potentiellement entraîner une défaillance secondaire jusqu’à ce que nos systèmes dans la nouvelle zone puissent évoluer pour répondre à la demande supplémentaire.

Au lieu de cela, la distribution aléatoire de nos téléspectateurs américains aide à atténuer l’effet de toute défaillance initiale et nous permet de répartir uniformément le trafic de basculement vers le reste des zones saines.

Dans notre plateforme de streaming, nous répartissons la charge du serveur manifeste entre les zones. Cela évite de surcharger une zone spécifique pendant les pics d’audience, en particulier si les téléspectateurs sont soudainement déplacés vers une zone adjacente pendant le basculement.

Chacune de nos zones dispose d’un magasin de données distinct dédié au stockage des données de session associées. Une fois qu’un visualiseur est acheminé vers une zone, nous créons une session pour ce visualiseur et l’enregistrons dans le cluster de sessions de la zone. La session est un ensemble de données sur le visualiseur et de paramètres fournis par le client sur la façon dont il souhaite personnaliser la session pour ce visualiseur. Pour surmonter le défi présenté par la nature stateless d’Internet, les serveurs de manifeste construisent des URL pour chaque session incluse dans le manifeste retourné au joueur. Les requêtes ultérieures du lecteur sont acheminées directement vers la zone où la session du spectateur a été créée et stockée (au lieu d’être acheminées aléatoirement vers l’une des autres zones).

Comme le montrent les trois graphiques ci-dessous, différents événements peuvent avoir de nombreuses exigences différentes selon la taille de l’auditoire et si l’auditoire est local ou géographiquement dispersé. Jetez un coup d’œil aux trois exemples illustrant les défis d’infrastructure auxquels les diffuseurs sont confrontés pour soutenir les événements en direct.

Dans le premier scénario, nous présentons un concours de nourriture (oui, nous en avons diffusé en direct l’un d’entre eux) parce qu’il illustre un public distribué mais de petite taille. Peut-être viendra-t-il un jour où les concours alimentaires deviendront courants, mais pour l’instant, ils restent un événement de niche qui attire un petit nombre de téléspectateurs à travers une vaste géographie. La charge du serveur Manifest est répartie facilement sur plusieurs zones et clusters de serveurs Manifest. C’est là que la valeur de la personnalisation devient évidente en facilitant l’insertion de publicités adaptées à chaque région et en permettant également de gérer les droits et les blackouts.

Le scénario change considérablement pour les championnats de football de l’État du Texas, où un grand nombre de téléspectateurs se trouvent dans la même zone géographique. Nous gérons cela de deux façons. Comme indiqué ci-dessus, nous avons constaté que nous pouvons affecter des téléspectateurs à des serveurs de manifestes situés dans des zones en dehors de la géographie immédiate sans affecter l’expérience du téléspectateur. En plus de cela, nous avons un système qui surveille les niveaux de consultation dans chaque zone et peut automatiquement lancer des serveurs de génération de manifestes selon les besoins sur une base par zone.

Nous pouvons pré-dimensionner en fonction de l’audience prévue pour les grands événements tels que les finales de la NBA. Pourtant, nous avons eu de nombreux événements où nos systèmes de mise à l’échelle automatique ont géré près d’un million de téléspectateurs sans nécessiter de préchauffage. En plus d’augmenter l’évolutivité, la possibilité de répartir instantanément la charge sur les serveurs Manifest de manière indépendante des zones améliore considérablement la fiabilité et la redondance sur l’ensemble du réseau.

Demandes des joueurs et balisage publicitaire

Un certain nombre de changements et de tendances dans l’industrie rendent l’évolutivité du cloud plus importante que jamais. L’un des principaux facteurs est la réduction de l’intervalle entre les demandes du lecteur. Notre requête standard de lecteur linéaire en direct de 8 secondes « whatt’s Next » est portée à 5 secondes et peut être aussi brève que toutes les 2 secondes pour les flux où une faible latence est importante. Cela a un impact majeur sur l’utilisation du processeur car le serveur doit répondre à 4 fois plus de requêtes (à intervalles de 2 secondes par rapport à des intervalles de 8 secondes). De plus, les recommandations de blackout et de contenu doivent désormais être vérifiées plus fréquemment que par le passé pour éviter les erreurs.

De même, le monde de la ad-tech devient plus complexe et exigeant. Pour chaque annonce insérée dans un flux, un serveur publicitaire aura au moins cinq balises utilisées à des fins de reporting. Une solution d’insertion publicitaire côté serveur (SSAI) est nécessaire pour s’assurer qu’elle envoie ces balises afin que ses clients soient payés par leurs annonceurs. Alors que cinq balises sont le minimum, il peut y en avoir beaucoup plus. En fait, nous avons vu des cas où une seule annonce a de 30 à 100 balises à signaler.

De plus, les réseaux complexes de serveurs publicitaires deviennent de plus en plus courants dans les campagnes de nos clients. Plusieurs sauts de réseau publicitaire peuvent commencer à causer des problèmes de latence. Par exemple, le réseau #1 peut dire, « Voici la liste des annonces dans cette pause », seulement pour découvrir que l’annonce #2 dans cette pause nécessite une requête à un autre réseau. L’annonce #3 introduit deux autres sauts, et ainsi de suite.

Dans l’exemple ci-dessus, les pauses publicitaires peuvent doubler ou tripler l’utilisation du processeur. Les demandes de lecteurs vidéo en direct peuvent aggraver ce facteur de 10 à 30 %.

‍Looking Ahead — microservices et évolutivité

Avec l’augmentation de la complexité, l’une des étapes que nous avons prises est de séparer les différentes charges de travail précédemment traitées par les serveurs Manifest en microservices plus petits. La première étape que nous avons faite est de déplacer les communications et le balisage des serveurs publicitaires vers son propre service, ce qui nous aide à relever le défi de la latence des serveurs publicitaires. Ce service de proxy publicitaire offre plusieurs fonctionnalités avancées que nous aborderons plus en détail dans un prochain article de blog.

À l’avenir, nous continuerons à développer d’autres microservices afin de supprimer plus de travail des serveurs Manifest et d’offrir une approche plus ciblée de l’évolutivité. Bientôt, nous ajouterons des zones de plusieurs fournisseurs de cloud pour devenir résilients face aux défaillances d’un seul fournisseur.

En couplant SSAI évolutif avec des microservices, nous pouvons optimiser les coûts des serveurs, la structure de notre base de code et d’autres caractéristiques spécifiques au trafic publicitaire. En outre, nous pouvons surmonter plusieurs défis clés, notamment la latence des serveurs publicitaires, les restrictions de blackout et la monétisation. Parallèlement, en répartissant la charge de traitement sur plusieurs zones, notre service de streaming vidéo en direct peut évoluer à grande échelle et surmonter les principaux défis, ce qui nous permet de fournir de manière fiable des millions de flux personnalisés simultanés sans mettre à rude épreuve notre réseau de diffusion.