1:1级别的个性化观看体验正在改变电视体验。 观众可以获得针对性和高度相关性的广告，量身定制的内容，针对新节目的建议以及精确的DRM/中断管理,所有这些都基于观众的设备类型，位置，历史记录，人口统计数据和其他数据。
但是，将个性化视频流扩展到数百万观众，尤其是体育等直播节目，几乎与棒球循环一样具有挑战性。 Viewer音量可以大幅波动，在必须观看的时刻(如开球，加班和近距离比赛)激增数十万人。 假设您用于支持个性化的基础设施不够适应性和可扩展性。 在这种情况下，您的个性化体验将会结束，您的整个业务可能会在OTT世界面临风险。
清单服务器在个性化中的核心作用
OTT个性化取决于清单服务器的性能，以生成内容，广告和播放指令的唯一播放列表。 清单服务器必须与以下依赖项进行竞争：
- AD服务器延迟—与AD服务器的通信可能会增加工作流中必须考虑的延迟，尤其是涉及多个跃点时。
- 货币化/报告—广告播放后，必须将信标发回广告服务器，以衡量广告曝光量并实现货币化。
- 互联网的无状态方面—要使个性化清单大规模工作，必须在每个查看器的多个请求中保持状态。
- DRM/身份验证—清单服务器必须保存有关数字权限管理(DRM)，会话级加密和身份验证的选项卡。
- 中断/内容权限和限制—根据用户的位置，流媒体内容可能会受到各种中断规则的约束，所有这些规则都必须得到精确管理。
- 内容建议—在线查看者希望您了解这些建议并个性化您的建议，以帮助他们完成搜索和发现过程。
- 内容本地化—对于重大事件，为用户提供适当的区域变体至关重要，包括音轨，隐藏式字幕和字幕。
实时个性化流媒体
正如本博客系列的第1部分所述，我们的切片器软件应用程序会摄取，编码和打包直播或VOD源。 可以插入广告边界，使内容所有者能够自定义观众的体验。 当广告被摄取时,它们也会通过在云中运行的切片器进行处理,以获得更像广播一样的播放体验。
当切片器开始摄取直播或VOD流时，它会持续与我们的后端基础设施通信，从而保持数据库中有多少段可用。 清单服务器使用该数据来个性化每个查看器的体验。 当播放器请求串流时,清单服务器决定哪些视频和音频段应列在清单文件中,该文件充当播放列表。 在每用户级别动态更改或自定义清单的能力使得定制查看体验成为可能。 在实时视频的情况下,每隔几秒钟就会请求一个新的清单,允许清单服务器在观看条件发生变化时动态应用调整。
清单服务器在个性化视频流中的核心作用
如上所示，Manifest个性化的核心是沟通。 对于大多数OTT业务需求，这意味着与AD服务器进行通信，以实时提供有针对性的个性化广告。 单个数据，包括查看者的IP地址，位置和设备类型—基本上是我们可以采集的所有信息，同时仍遵守严格的PII规则和法规—都将提供给广告决策系统。 由此产生的解决方案足够强大，足以了解在直播流媒体中投放广告时与观众相关的内容。 该系统还足够强大，能够应对各种挑战，例如管理中断限制和按用户分配的内容权限，同时支持重要的个性化功能，如内容推荐和其他本地化。
构建可扩展的清单基础架构
在我们的视频平台中,清单服务器负责为每个观众生成自定义流式清单。 它还需要了解上文提到的其他要求，如内容限制和建议。 在此模型中，我们发送一个集成流，这意味着当客户等待广告在流的中间加载时，不会出现”缓冲轮”问题。
为了构建弹性的清单交付系统,我们在云中维护分布在全球不同地理区域的清单生成服务器群集。 例如，在美国，这些服务器分为全国五个地区。 当来自美国玩家的新流媒体请求时,该请求会随机发送到美国的某个区域。
“雷鸣般的牛群”挑战
这可能看起来违背直觉，但这样做是为了防止级联故障模式。 大多数美国观众都位于美国东部地区。 如果我们将它们全部路由到最靠近它们的区域，而我们的云提供商在该区域遇到了故障，我们的大多数观众都会遇到这种故障。 更糟糕的是，如果所有这些观众都刷新流媒体，并且我们现在将观众引导到下一个最接近的健康区域，我们将会遇到一个“雷群”问题，即来自故障区域的所有观众现在都在抓住下一个最接近的区域。 由此产生的意外流量高峰可能导致二次故障，直到我们位于新区域的系统能够扩展以满足额外需求。
相反，随机分布我们的美国查看器有助于减轻任何初始故障的影响，并使我们能够将故障转移流量均匀地分布到其余健康区域。
在我们的流平台中，我们在各个区域之间分配清单服务器负载。 这可防止在观众激增期间使任何特定区域过载，尤其是在故障转移期间，查看者突然转移到相邻区域时。
我们的每个区域都有一个单独的数据存储区，专用于存储关联的会话数据。 将查看器路由到区域后，我们会为该查看器创建一个会话，并将其保存在区域的会话群集中。 会话是一组有关查看器的数据以及客户提供的有关如何为该查看器自定义会话的参数。 为了克服因特网的无状态性质带来的挑战,清单服务器为返回给播放器的清单中包含的每个会话构建URL。 播放器的后续请求将直接路由到创建和存储查看器会话的区域(而不是随机路由到其他区域之一)。
如下图所示，不同的活动可能有许多不同的要求，具体取决于受众的规模以及受众是本地还是地理位置分散。 查看三个示例，这些示例说明广播公司在支持直播活动时面临的基础设施挑战。
在第一个场景中，我们会举办一场饮食竞赛(是的，我们已经直播了其中一场比赛)，因为它展示了分布式但观众规模较小的情况。 或许有一天,饮食竞赛将成为主流,但现在,它们仍然是一个利基活动,吸引了来自广阔地理区域的少量观众。 清单服务器负载可轻松地分布在多个区域和清单服务器群集中。 在这里,个性化的价值变得显而易见,因为它可以轻松地插入适合每个地区的广告,并能够管理权利和中断。
德克萨斯州足球锦标赛的场景发生了很大的变化，在该赛事中，大量观众位于同一地理位置。 我们通过几种方式处理此问题。 如上所述，我们发现我们可以将查看者分配到位于直接地理区域以外区域的清单服务器，而不会影响查看者的体验。 最重要的是,我们有一个监控每个区域的收视率的系统,并且可以根据需要在每个区域自动启动清单生成服务器。
我们可能会根据NBA总决赛等大型赛事的预期收视率进行预先调整。 尽管如此，我们仍有多个活动，我们的自动缩放系统在不需要预热的情况下处理了近100万名观众。 除了提高可伸缩性外，以不受区域影响的方式在清单服务器之间即时分散负载的能力还显著提高了整个网络的可靠性和冗余性。
播放器请求和广告信标
整个行业的许多变化和趋势使云扩展比以往任何时候都更加重要。 一个主要驱动因素是播放器发出请求之间的间隔缩短。 我们的标准直播线性8秒”下一个是什么”播放器请求将被驱动到5秒，对于低延迟非常重要的流媒体，它的请求可以像每2秒一样简短。 这主要影响CPU利用率，因为服务器必须响应4倍的请求(间隔为2秒，而间隔为8秒)。 此外，现在还必须比过去更频繁地检查中断和内容建议，以避免错误。
同样，广告技术世界也变得越来越复杂和苛刻。 对于插入到流中的每个广告，AD服务器将至少有五个信标用于报告目的。 需要服务器端广告插入(SSAI)解决方案来确保它发送这些信标,以便其客户通过广告商获得报酬。 虽然最少有五个信标，但可以有更多信标。 事实上，我们已经看到过这样的案例：单个广告有30到100个信标可供报道。
此外，复杂的AD服务器网络在我们的客户营销活动中越来越常见。 多个AD网络跃点可能会开始导致延迟问题。 例如，网络#1可能会说，”此处是此次休息的广告列表”，只是为了发现该休息中的广告#2需要向另一个网络发出请求。 广告#3还引入了两个跃点，依此类推。
在上面的示例中，广告中断可以使CPU利用率增加一倍或三倍。 直播视频播放器请求可能会使该因素复合10–30%。
Looking领先—微服务和可扩展性
随着复杂性的增加,我们采取的步骤之一是将先前由清单服务器处理的不同工作负载分离到较小的微服务中。 我们所做的第一步是将AD服务器通信和信标迁移到其自己的服务，帮助解决AD服务器延迟的难题。 此广告代理服务提供了多种高级功能，我们将在即将发布的博客文章中深入讨论这些功能。
今后，我们将继续开发其他微服务，以删除清单服务器的更多工作，并提供更有针对性的可扩展性方法。 不久，我们将添加来自多个云提供商的区域，以应对任何一个云提供商的故障。
通过将可扩展的SSAI与微服务相结合，我们可以优化服务器成本，代码库结构以及广告流量的其他特定特征。 此外，我们还可以克服几个关键挑战，包括广告服务器延迟，中断限制和盈利。 同时，通过将处理负担分散到多个区域，我们的直播视频流服务可以广泛扩展并克服关键挑战，使我们能够可靠地同时交付数百万个个性化流，而不会给我们的交付网络带来压力。
