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