边缘计算社区

爱奇艺边缘计算探索与实践

摘要

随着云原生技术的发展和 5G 商用的到来,边缘计算随“风”而起。本文将从提升视频播放体验和降低带宽成本的两个目标,介绍爱奇艺在边缘计算服务平台和边缘缓存应用场景两方面的实践经验。

01 边缘计算简介

边缘计算正获得越来越多的关注,Gartner 连续三年将边缘计算列入十大技术趋势之一。欧洲标准电信协会ESTI制定的边缘计算标准架构MEC,也从 “Mobile Edge Computing” 转变为 “Multi-Access Edge Computing”,意味着边缘计算并非限定在运营商层面的移动网络,而是包括更广泛的多接入网络。关于边缘的界定也逐渐清晰,按照离终端用户的距离从近到远,可以分为物边缘、移动边缘和云边缘,目前国内运营商和云厂商主要分别在后两部分布局。

值得注意的是,以容器为代表的云原生技术和5G的商用,为进一步推动边缘计算发展提供了技术支持和基础设施。此外,边缘计算和云计算的关系并不是替代,而是相互补充发挥云边协同作用。边缘计算可以将云的能力延伸下沉到边缘做,比如存储、AI、大数据等,边缘计算进行Off Loading处理,降低终端的响应时延和云端压力等;也可以将端设备不宜胜任的AI、计算和大量数据存储提升到边缘来做。

爱奇艺HCDN 团队在边缘计算的实践主要集中在物边缘这一层面,较少部分在云边缘。下面将从边缘计算平台 IPES、应用场景和未来工作三部分进行介绍。

02 边缘计算平台IPES

在2019年初,爱奇艺HCDN团队开始设计实现边缘计算平台—— IPES(Intelligent Platform for Edge Service),通过对海量设备资源进行统一管理和分配,提供更靠近用户现场的 PaaS 能力。

设计之初,IPES 考虑了至少应该支持海量异构设备、支持云边协同两个原则,包括有效利用不支持容器环境的设备资源隔离运行Native程序。具体来说有如下功能:

A. 节点管理

  • 设备接入
  • 节点信息/状态投递
  • 应用信息/状态投递

B. 应用管理(支持按需灰度、版本依赖、资源限制、自动扩展)

  • Docker应用部署
  • Native应用部署
  • 函数应用部署
  • 在线同步云端期望状态
  • 离线自治

C. 任务调度

  • 函数任务实时调度下发
  • 函数任务定时触发
  • 任务回调接口
  • 任务回传文件接口
  • 任务投递状态接口

D. 公共服务

  • 日志采集
  • 服务健康检查
  • 消息路由
  • 分布式存储

IPES 抽象架构如下图所示,通过 UI 或命令行(完善中)对资源和应用进行操作。

云端架构如图:

IPES云端部分借鉴了K8S API Server的架构,由以下核心组件组成:

  1. API Server是资源、应用和任务下发的统一入口,提供认证、授权和访问控制等机制,方便应用方或设备方的使用
  2. Controller负责维护应用实例的状态,比如应用状态的匹配,实例数的匹配,按资源使用自动扩展等
  3. Scheduler负责对符合要求的资源进行筛选过滤,根据期望状态将应用或任务调度到对应的设备资源上
  4. Data Manager消费边缘端投递上来的所有数据,并加工生产成不同模块需要的数据
  5. MQTT Broker是基于 MQTT协议的云端集群,负责和所有边缘端的MQTT agent保持通信,是云边协同中重要的一环
  6. Store部分可以看作应用商店,其中 Docker Repo 支持 Docker 镜像管理,采用公司内部的云服务;IPFS 代理支持分布式的上传和拉取数据,减少云端请求和带宽压力
  7. Observe部分包括应用的健康检查和日志采集服务等,基于公司内部云服务比如 Prometheus 和 EFK 框架等搭建,应用部署时可以选择开启上述功能。

边缘端架构如图:

运行边缘节点的设备在硬件和软件环境等方面往往差别很大,为统一部署和资源管理提出了挑战,包括:

  1. 大部分边缘设备采用低功耗的 Arm 架构或 Mipsle 架构,需要进行架构适配
  2. 操作系统往往采用不同的 Linux 发行版本,或者是自定义裁剪过的 Linux 内核
  3. 网络条件不如传统数据中心,可能没有外网 IP 或端口
  4. 人为或无法预知的断电断网情况往往不可避免,缺少健壮性

因此,IPES 边缘端不仅要适配各种异构设备和操作系统,而且要做到离线自治,即使和云端断开了连接,也不影响已有服务的正常运行。另外数据安全也是要考虑的一方面,采用证书和加密机制来保证数据的安全。在部分不支持 Docker 的设备上,采用 Native+CGroup 的方式对应用进行资源限制。边缘端由以下核心组件组成:

  1. Master是边缘端主进程,提供本地 API 接口,并负责所有模块和应用的生命周期,基于 Native 和 Docker 两个应用 Engine,支持 Native 和 Docker 应用的混合部署
  2. Agent是边缘端和云端保持长连接的组件,主要作用是加密的双向通信,云边协同的重要一环;
  3. Lambda是函数计算的Runtime 组件,支持Python 和 JS 的函数代码运行,也支持函数任务的队列管理、定时触发、状态投递、任务回调等功能(可选组件)
  4. MQTT-Hub是边缘端的 MQTT 代理,支持各个应用之间的消息订阅发布的通信,包括第三方应用和 Lambda 组件(可选组件)
  5. IPFS是基于内容寻址的开源分布式组件,基于边缘端构建的 IPFS 分布式网络,可以提供应用数据的下载上传功能,降低云端的请求和带宽压力(可选组件)
  6. Filebeat是轻量级基于文件内容的开源日志采集模块,支持日志的实时过滤处理和回传云端(可选组件)

从应用方的角度来看,IPES 边缘节点分层架构如下图:

基于 IPES 边缘计算服务平台,可以方便的接入设备和部署各类应用。目前 IPES 已经接入百万台设备,覆盖了 X86、ARM和 Mipsle 等各类 CPU 架构设备,支持 Linux、Windows 和 Openwrt 等操作系统。主要承载着点播的缓存应用,也运行了部分包括直播缓存应用、视频会议应用、广告违规物料检测等十多个应用。

03 边缘应用场景

随着用户对长短视频、4K/8K 超高清视频、以及直播、AR/VR 等内容的需求越来越多,用户观看视频的介质也从网页、PC、OTT 到各类移动设备越来越丰富,视频的带宽成本也变得越来越高。同时考虑到内容版权的保护、服务质量 QoS 和业务形态发展等因素,HCDN 团队从 2014 年开始,着手设计实现混合P2P和CDN技术的HCDN架构,构建超大规模的分布式存储网络。并陆续将存储上传节点程序进行升级改造,使之能够更充分的利用各类异构的设备资源,并作为独立的边缘缓存应用,通过 IPES 平台进行部署和管理。为用户提供丰富、高清、流畅的视频体验。

上图中的 HCDN Inside APPs 就是部署在 IPES 边缘节点的边缘缓存应用。边缘缓存应用的整体逻辑可以简单的从供给和需求两个角度来描述。右半部分是供给侧,或者说资源分发流向,资源按照一定的策略,被主动的或根据需求自适应调整而分发在边缘存储设备中。左半部分是需求侧,或者说资源消费流向,资源被手机、PC、OTT等不同终端消费用于播放视频内容。

无疑,数亿视频用户所在的需求侧对资源的需求是多样而巨大的,而供给侧的边缘存储节点虽然经过多年发展已有不小规模,但相对而言也是有限的,因此如何使得端可以有效的访问到需要的边缘缓存节点上的资源,并且尽量确保该资源离自己比较近,就需要依赖HCDN的云端HDS存储分发调度策略。

供给侧和需求侧与边缘缓存节点一起构成一张巨大的分布式存储分发网络,需求侧(Peers)对获取的边缘节点和资源进行读取并反馈给网络中的大脑 Trackers,Trackers 按照边缘节点的分布、资源的稀缺,再结合需求侧的反馈等信息,对分发的资源和节点进行调整。供给侧(HDS Push)根据 Trackers 的决策结果,往存储网络中写数据。

分发调度的策略算法有很多的研究空间,就不具体展开介绍。重要的是可以看到,基于海量的下沉边缘存储设备,发挥云边端协同作用,对资源进行统一管理、智能调度并汇聚成共享带宽为各个端上应用提供稳定的适配服务,达到提高视频观看体验,同时降低带宽成本的效果。

除了以上面向点播场景下的边缘缓存应用介绍之外,IPES平台上还承载部署着其他业务场景的边缘应用,包括:

(1)直播镜像

直播场景下的存储分发特点有别于点播场景,在于直播往往发生在有限的时间内,且直播压力具有突发性。因此如果单纯的依靠传统CDN资源且预留的直播资源不能满足突增的直播请求时,容易出现直播卡顿比增加,且反过来影响点播视频播放质量等问题。

而边缘计算节点的覆盖广、更靠近用户、云边协同的灵活弹性调度等优势,正好可以解决这个问题。通过在IPES上部署直播镜像分担直播流量,降低CDN压力和延时,同时节省带宽成本。

(2)SFU/RTCDN

2019年底以来的新冠疫情给全世界造成很大的影响,体现到工作方式上就是视频会议的需求急剧上升。同时今年以来直播再次成为新风口,达人直播名人带货的现象屡见不鲜。爱奇艺基于WebRTC协议构建的低延时互动直播和会议RTCDN服务,主要采用SFU级联模式。SFU可以提高实时性,同时级联框架可以覆盖推流端(主播或视频会议演讲者)到拉流端(观看者)的不同网络状况,满足不同业务场景的需要。

通过IPES对SFU进行调度部署,使得SFU离推流端和拉流端更近,解决第一公里和最后一公里的问题。当然,边缘节点的健壮性对RTC流有一定的影响,IPES提供服务健康检查和稳定性预测等手段来尽量降低对服务质量的影响。

上述几类应用往往采用容器部署,是云端(存储、转流)能力往边缘下沉的场景体现。

(3)广告违规物料检测

还有一类场景是将终端不宜胜任的工作往边缘转移。一个案例是广告主在爱奇艺平台发布的广告物料,作为平台方需要对物料进行上线前审核和上线后巡查,避免出现违规的情况。广告物料在不同的地域可能会有些自适应调整,也可能遇到HTTP恶意劫持导致页面内容显示异常。显然上线后巡查如果放在云端做不太合适,且需要采购成本,而广告页面的下载渲染过程,尤其对于复杂页面而言,资源消耗不低,因此也不适合在端上进行。

IPES平台的函数计算组件,支持部署运行Python和JS函数代码。并且在云端提供任务下发接口和函数回调接口,满足不同函数任务下发需求和便于追踪函数执行结果。在这个案例上,将广告物料巡查脚本部署到边缘节点上,既提高违规物料检测的成功率又节省了采购成本。

将终端不宜胜任的工作往边缘转移的应用场景还有不少,包括AI处理的工作等,目前IPES在这方面继续进行探索和尝试。

04未来方向

可以看到,视频正在越来越多的作为人与人之间的信息传播媒介,而且视频流量占据着互联网流量的一半以上。目前各大公司和运营商都在边缘计算领域积极布局,纷纷推出了各自的解决方案。关于找到一个可大规模落地并产生效益的应用的问题,爱奇艺给出了一个明确的答案——边缘缓存应用。通过边缘计算可以有效的降低视频带宽成本,提升观看体验。当然,我们也期待着更多的 AI 和大数据等云能力,逐渐在边缘计算落地开花。

站在边缘计算平台的角度看,各个公司的平台各有侧重。其中 K3S侧重在构建边缘的轻量级 K8S集群,国内各大公司给出的方案则更侧重另一个方向——云边协同(这一点和 IPES 类似),且不约而同的都基本兼容 K8S,差异点主要在比如支持 P2P分发镜像(openyurt),对云边协同“长连接”通道的理解或实现不同(Websocket、QUIC、mqtt),对工业物联网更友好(kubeedge)等等。

对于 IPES 来说,既要保持已有边缘缓存应用生态的继续运转,也要合理跟进主流技术包括云原生等方面,为未来纳入更多设备和落地支持更多应用提前做准备。在可见的未来,IPES 还有但不限于以下工作要做:

  • 兼容 k8s
  • 加强集群管理能力
  • 加强配置管理能力
  • 提供更多应用友好的服务支持

写在最后

在尝试部署在边缘节点时,不少应用遇到从传统数据中心迁移过来后的“水土不服”的情况。这些应用往往设计之初假定具备了传统数据中心提供的比如固定外网 IP 地址、公共端口、内网域名访问等条件,而在容器化或边缘计算场景下部署时,这些问题都需要经过适当的修改,甚至是服务的拆分,才可以更好的运行起来。

所以,边缘计算既然看作是云计算能力的延伸,那么在架构上和应用开发方式上,也是一脉相承。积极合理地采用云原生架构思想,可以更快更好地利用边缘计算的能力。

发表评论

邮箱地址不会被公开。 必填项已用*标注

青ICP备20000204号-2