衡量直播系统的可靠性
来源：Video@Scale 2021 主讲人：Petar Zuljevic(Facebook) 内容整理：彭峰 提供具有高可靠性的实时视频具有挑战性，不仅是在分布式系统上部署改进的角度来看，还是从定义合适衡量指标以捕获可靠性变化的方面来说。Facebook 的 Live 平台涵盖从创作者上传其流的摄取端点，到负责转码和生成多个视频再现的服务，在出口堆栈上执行交付的服务，最后是为数百万观众提供广播的 CDN 端点。所有这些管道都必须在实时保证的情况下进行编排工作，从而即使是单个故障对用户来说也可能是严重的。在本次演讲中，Facebook 的工作组将展示一些对可靠性指标的思考。
目录
- 介绍
- 直播系统架构
- 可靠性指标
- 应用
介绍
关于直播的挑战时不仅与系统的技术复杂性有关，还与必须支持的各种产品用例和功能有关。从普遍角度来看，每个直播可以看作一种广播的形式，其面临的主要问题有以下几个方面，首先是平台直播数量众多，每天的观看时长高达数百万小时；其次，同时观看的人数变化范围很大，可能在较短的时间内从几个用户增长到数百万，例如体育赛事；再者，平台除了需要支持自己的客户端，还需要给予一些第三方应用的支持；最后，终端用户的设备和网络情况都是各不相同的。
直播的可靠性通常指的是系统（包括硬件和软件）成功执行工作任务的概率。为了保证系统的可靠性，确实需要深入思考可扩展的可靠性指标——从某种意义上说，我们如何进行测量以及在不同的条件如何反映在用户体验。直播系统中的用户可以分为三类，即广播者、观众以及合作者，广播者指的是内容创作者，负责生成内容；观众指的是观看或者消费内容的群体，是收入的来源之一；合作者指提供支持的群体。整个直播系统设施的可用性意味着所有的用户都认为系统是可用的，因此需要有衡量系统运行的可靠性指标。
直播系统架构
直播基础设施
以上图为例来理解直播系统，假如身处纽约的你拿起流媒体设备，通过直播平台的客户端或者第三方客户端来进行直播，并希望你悉尼的朋友能够观看到该直播，那当你按下“上线”按钮之后会发生些什么呢？
首先，你的连接和数据包将会达到距离较近的服务器，例如纽约东海岸，这可以减少你的“上线”过程的完成时间。然后服务器会将你的内容数据转发给其他数据中心，完成图示中的 Ingest 步骤；进一步，你的视频会被数据中心处理，例如，你可能在较好的网络环境下生成了高质量的视频内容，但是你的朋友可能处于较差的网络环境，所以需要生成一个低质量版本的内容视频，使得你的朋友无需缓冲也可以观看，这就是图示中 Processing 部分的作用。对于你的朋友即观众而言，他首先会与距离他较近的服务器建立连接，然后从该服务器获得一个合适的 CDN 服务器地址，再与该服务器建立连接，然后即可观看直播，观众的客户端可能会保存这些视频的部分数据以便下次就可以更快地访问它，如果另一个观众加入，比如来自印度的观众，他们将通过类似的方式，选取其他的服务器建立连接然后选取其他的 CDN 服务器。
上述的框图中有不同的组件，每一个组件都有可能成为系统的不可靠因素，其可能发生的情况如下图所示。例如，在选择服务器的过程中，选取的依据是 DNS 服务器认为最好的一个，如果该选择过程并没有选到最优的服务器，那么会造成用户体验的极大下降。
系统的不可靠因素
在这种情况下，系统实现可靠性是困难的，例如一个一秒的片段传输成功的概率是99.99%，那么一个小时中，不会产生故障的概率为 99.99\% \times 3600 = 70\% ，从而一百小时的观看时长中，就可能有3个小时会让用户体验大幅下降。所以选取可靠性测量指标是至关重要的，同时也是困难的。
不可靠性概率示例
可靠性指标
设计一个可靠性指标的过程可以分为三个步骤，即明确用户需求、定义指标和收集数据。明确用户需求是简单的，例如在世界杯期间，用户不希望在将要进球的前一刻直播出问题，所以希望获得稳定的直播观看体验。当明确需求之后，需要去定义衡量指标，定义的方式有两种——基于端到端的合成流量和基于单独组件。其中，基于端到端的合成流量来定义衡量指标是困难的，因为庞大数量的用户所处的情况是不同的，例如不同设备、不同的网络条件等。对基于系统组件定义的方式而言，需要明确每个组件的责任是什么，将其视为特定组件的局部点度量。
基于端到端的合成流量定义指标示意图
基于单独组件定义指标示意图
基于上述的原因， GBR 指标的概念被提出，GBR 代表良好的广播率，其被用来从广播公司的角度衡量整个直播系统的可靠性。
GBR
GBR 的计算过程如下图所示，其涉及到了除了第三方之外的所有系统组件，不仅可以判别广播系统是否正常工作，还可以当故障发生时追踪故障来源于哪一个组件。然而，这种衡量指标并不是完美的，主要存在的问题有两种。第一种是当用户分布不均，即某些直播观看人数很多，但是大部分直播观看人数相当少，使用 GBR 作为衡量指标可能会忽视那些观看人数少的直播中出现的故障；第二种是用户拥有不同的类别，例如使用 PC 和移动设备的用户是两类用户，使用 GBR 衡量过程中，可能使用 PC 设备的用户体验良好，但是使用移动设备用户缺体验糟糕，GBR 无法检测此情况。
GBR计算方式
对应于上述的两种问题，提出的解决方案对不同的组件在计算 GBR 过程中使用不同的权重，从而在 GBR 指标出现问题时可以快速追踪到故障来源。其次，对于不同种类用户的问题，可以进行大致的分类，调整每一类的不同组件在 GBR 计算过程中的权重，然后单独监测。
应用
在直播系统运行中，可以将 GBR 部署到实际系统中作为服务级别目标（Service-level objective，SLO）（注：SLO 是指服务提供者向客户作出的服务保证的量化指标），一定时间粒度地对系统的 SLO 进行监测，如果低于预期值，则调查相应的原因，并记录报告。当遇到 SLO 突然下降时表明系统出现了问题，需要快速检查，按照不同组件的不同权重，分析故障来源。
GBR 作为 SLO 应用
最后附上演讲视频：