每日一博 | 网易云音乐音视频算法的 Serverless 探索之路
作者 | 廖祥俐 2015年加入网易云音乐，云音乐曲库研发负责人。
策划 | 望宸
网易云音乐最初的音视频技术大多都应用在曲库的数据处理上，基于音视频算法服务化的经验，云音乐曲库团队与音视频算法团队一起协作，一起共建了网易云音乐音视频算法处理平台，为整个云音乐提供统一的音视频算法处理平台。本文将分享我们如何通过 Serverless 技术去优化我们整个音视频处理平台。
本文将从三个部分向大家介绍：
- 现状：音视频技术在网易云音乐的应用情况，引入 Serverless 技术之前遇到的问题；
- 选型：调研 Serverless 方案时的考虑点；
- 落地和展望：我们进行了哪些改造，最终的落地效果和未来规划。
现状
作为一家以音乐为主体的公司，音视频技术被广泛应用于网易云音乐的众多业务场景里，为了更形象的让大家感受到，这里列举了 5 个常见的场景：
- 默认情况下，用户听到的是我们采用音频转码算法预先转好的标准化码率的音质，但由于流量有限或自身对于音质更高的要求，想要切换到差一些或更好的音质。
- 用户可以使用云音乐 APP 里面的听歌识曲功能去识别环境中的音乐，这背后使用到了音频指纹提取及识别技术。
- 在平台上的一些 VIP 歌曲，为了能给用户更好的试听体验，我们会做副歌检测，让试听直接定位到高潮片段，这里用到了副歌检测算法。
- 在云音乐的 K 歌场景里，我们需要对音频的音高进行展示并辅助打分，这里我们用到了音高生成算法去完善 K 歌的基础数据。
- 为了更好的满足云音乐平台上，小语种用户的听歌体验，我们为日语、粤语等提供了音译歌词，这里用到了自动罗马音的算法。
从上面的场景可以看到，音视频技术被广泛应用于云音乐的不同场景里面，发挥了重要的作用。
从我们的音视频技术做一个简单划分，可以分为三大类：分析理解、加工处理、创作生产，这些一部分是以端上 SDK 的方式，在端上进行处理；而更多的部分，是通过算法工程化的方式，采用后端集群部署管理，以服务的形式提供通用的音视频能力，而这部分是我们今天分享的重点。
音视频算法的服务化部署工作中，需要了解很多相关音视频算法的特点，如部署环境、执行时间、能否支持并发处理等，随着我们落地算法的增加，我们总结了以下规律：
- 算法的执行时间长：执行时间往往与原始音频的时长成正比，云音乐很多场景下音频、视频的时长 Range 范围是很大的，基于这个特点，我们在执行单元的设计上，往往都采用异步化的模式。
- 音视频算法具有多语言特性：云音乐的算法包括了 C++、Python 等语言，对接环境上下文会带来极大的困扰，为了解决这个问题，我们采用标准化约定及镜像交付的方式，解耦各类环境准备的工作，所以后续对于能否支持镜像部署，会成为我们技术选型的一个重点考察。
- 弹性的诉求正在变大：云音乐平台的歌曲，从我入职时候的 500w，到现在在线超过 6000w，增量 vs 存量的 gap 越来越大，当我们快速实施一个算法时，不仅要考虑增量的接入，更要考虑存量的快速处理，所以在系统设计中，会单独把执行单元的最小粒度剥离出来，便于快速的扩容。
基于我们对工程化的理解，及音视频算法处理的特点，云音乐的音视频处理平台的整体架构如下：
对于不同音视频算法处理的共同部分，我们做了统一的设计，包括算法处理的可视化、监控、快速试用和处理数据统计等，对于资源的分配也设计了统一可配置的管理模式，让整个系统的公共部分可以尽可能抽象并复用。
整个音视频算法处理平台最关键的，也是今天的分享重点，是执行单元的交互与设计。云音乐通过统一的对接标准、采用镜像交付的方式，解决了很多对接和部署上的效率问题。针对资源的使用，由于我们不断有新算法、存量/增量服务的存在，在上云之前，用的是内部私有云云主机申请/回收、内容容器化的方式。
为了更好的描述云音乐执行单元的运行流程，我们将它更细化下，如下图所示：
通过消息队列去解耦了执行单元与其他系统的交互，在执行单元内部，我们通过控制消息队列的并发度去适配不同并发性能的算法，尽量控制执行单元的主要工作仅用于算法的计算，这样最终在系统扩容的时候，我们能够做到最小粒度的扩容。
在这个模式下，我们落地了 60 多种音视频算法，尤其是在近一年来，服务化的算法占到了一半，这些算法向云音乐 100+ 的业务场景提供了服务能力。但更复杂的算法、更多的业务场景，对我们的服务化效率、运维部署和弹性能力都提出了更高的要求，在我们上云之前，在内部已经用到了 1000 台以上不同规格的云主机及物理机。
选型
随着业务场景和算法复杂度的增加，虽然通过了很多方式去简化了内部业务场景、算法等的对接，但越来越多夹杂存量、增量处理的算法，不同流量的业务场景规模，以及不同业务场景可能会复用同一类算法的，让我们在处理机器资源的时间，远比我们在开发的时间更多。
这个也促使我们开始去考虑更多的方式方法，去解决我们遇到的问题，最直接的有三个痛点。
第一个是存量和增量的差异变大，和新算法落地的增多，我们花在处理存量和增量的资源协调时间越来越多；其次是随着算法复杂度的增高，我们在申请/采购机器的时候，需要关注机器的整体规格、利用率等；最后是，我们希望存量的处理能够加快，在处理存量的时候有足够大的资源，在海量音视频数据处理时候，能够压缩存量与增量不一致的时间。总的来讲，我们希望能够有足够大规模的弹性资源，让音视频算法服务不用再多去关注机器管理。
然而，实际改造不仅仅是关注最终服务能力，还需要综合考虑投入的 ROI。具体来看：
- 成本：包含两方面，改造的实施成本和计算资源的成本。前者可以结合具体方案进行评估，得到所需投入的人日，此外，改造后在未来的灵活拓展性，也是我们需要考虑的点。后者可以通过云厂商官方给出的费用计算模型，结合我们的执行数据，估算出来。我们在成本方面的选型关键是，在改造成本能够接受的情况下，未来的 IT 成本不会大额的增加。
- 运行环境的支持：前面提到过，云音乐的运行环境比较多样化，是以镜像交付的方式进行部署的；团队内部都有相对完善的 CICD 支持，这个要求未来的升级、部署事务，例如规格配置上，是否能够简化开发人员对于机器等的关注。我们希望在改造后，不需要在此类事项上花费过多的时间和精力，更多的关注算法执行本身。
- 弹性能力：除了云厂商提供的计算资源池的规模，我们还会关注弹性算力的启动速度，是否能够对固定场景进行实例预留，以及是否提供更符合业务诉求的灵活弹性能力，以更好的支持业务的发展。
这些其实都符合 Serverless 的定义，构建和运行应用程序都不需要对服务器进行管理、弹性能力出众等。综合以上的考量，我们选择了公有云函数计算的方式，**它能直观的映射我们目前的计算执行过程，同时也能满足后续想尝试通过 Schema 进行算法的编排。**下面我会重点分享下引入函数计算 FC 的过程。
落地
我们在一周内快速试用了函数计算 FC，然而一个完整的、高可靠的架构，需要考虑更多的因素。因此我们的改造重点是只把算力任务通过函数计算 FC 弹出去，系统在整体的对外输入输出上仍保持不变，并且系统拥有流量控制能力，能够在遇到特殊情况时，降级到私有云进行处理，保障系统的高可靠性，具体的架构改造如下图所示：
云音乐的开发环境与函数计算的适配是改造的重点，**我们重点针对部署、监控和混合云支持进行了改造。**部署上，我们充分应用了函数计算在 CICD 上的支持及镜像部署的支持，实现了镜像的自动化拉取；在监控设计上，一方面利用云上的监控报警功能，另一方面把它转化为我们内部已有监控系统的参数，让整体的开发运维处理能够维持一致性，最后是从代码设计上，考虑能够兼容混合云部署的实现，最终完成了我们音视频处理平台的 Serverless 改造。
从函数计算的计费策略上，我们可以看到，有三大因素在影响最终费用，内存的规格、触发计算的次数，以及公网出流量的费用。直接从技术架构上看，大家可能更关注前两者，实际上流量费用也是一笔不小的费用，这个对于我们来讲，也是关注的一个重点。
我们根据函数计算的费用特性，在存储体系仍然使用网易私有云的情况下，在第一阶段，首先选取的是公网出流量比较少的音视频算法。关于公网出流量比较少，我举个例子，对音频进行特征提取，如一个音频进去，提取一个 256 维的数组，获取的结果就只是一个 256 维数组，它是远远小于音频自身的流量，因此出公网的流量费用会比较少。
在引入函数计算的第一阶段，特征提取类的算法得到了 10 倍速的提升；稀疏类的算法，可以理解为日常使用率很低的算法，在成本上得到了极大的节约。除此之外，通过函数计算的镜像缓存加速能力，优化了我们节点的启动速度，让所有的服务拉起可以在秒级完成。这些工作，降低了算法运维处理中大量的运维成本，让我们能够更聚焦关注在算法及业务自身。
上方右边这幅图是云音乐其中一个算法的运行示例，可以看到，我们在弹性上的变化范围是非常大的，而函数计算很好的满足了这个诉求。
未来，我们希望能够更进一步通过 Serverless 技术去解放我们在运维上的人力投入，并将从存储上进行尝试，进而解决公网出流量的问题，让更多场景的音视频算法可以自然的实现；其次，随着算法复杂度的进一步提升，使得计算资源上使用的更加复杂，希望通过 GPU 实例来优化计算过程；最后，在云音乐的业务场景中，实时音视频处理的场景也越来越多，同样的，它也有明显的高峰、低谷的波动特点，我们希望沉淀更多的 Serverless 服务使用经验，最终助力云音乐实时音视频技术的发展。
