网易云音乐音视频算法的 Serverless 探索之路
作者:廖祥俐
策划:望宸
审核&校对:潇航
编辑&排版:雯燕
网易云音乐最初的音视频技术大多都应用在曲库的数据处理上,基于音视频算法服务化的经验,云音乐曲库团队与音视频算法团队一起协作,一起共建了网易云音乐音视频算法处理平台,为整个云音乐提供统一的音视频算法处理平台。本文将分享我们如何通过 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 服务使用经验,最终助力云音乐实时音视频技术的发展。
作者:廖祥俐,2015年加入网易云音乐,云音乐曲库研发负责人。
了解更多相关信息,请扫描下方二维码或搜索微信号(AlibabaCloud888)添加云原生小助手!获取更多相关资讯!