快手Y-tech
最新技术干货分享
背景
快手作为国内最主要的短视频社区之一,每天都产生海量的视频创作,其中“特效”视频是不可忽视的一部分。
Y-tech 通过在计算机视觉,图形学以及机器学习的交叉领域不断探索,持续为快手提供令人惊艳的“特效”视频。
支撑这些丰富的视频特效,不仅需要精巧的算法,同时还有图形和图像相关的推理和渲染带来的庞大计算量。由于部分特效消耗计算资源高,而端上计算资源有限;或是适配多种端上版本复杂性高等困难,诞生了服务端特效需求。
通过用户上传媒体文件,服务端处理,下发给用户的流程,使更多复杂或带有新特性的魔表短期落地成为可能。
挑战
Y-tech 服务端特效相较于一般意义上的服务,具有特别的挑战。
在服务实现方面,挑战主要来源于实时性要求和复杂性、资源占用间的矛盾。服务端特效计算是面向最终用户的,基于服务质量考虑,对实时性有一定的要求。而特效推理和渲染本身特点是:
推理目标和渲染过程复杂多变,不适合定义为简单一致的接口
针对图形图像的计算,通常数据量大,在很多场景下延迟高达秒级,可以达到 2--5 秒,占用资源多
输入输出可能包含多媒体信息,对带宽要求高
考虑到超高延迟的图形图像处理场景,且 Y-tech 往往并不是服务端特效链路中唯一的一环,这要求我们综合考虑延迟对于整个链路的压力,以及有限资源的合理分配。
同时,我们需要考虑分离服务层与算法层,降低分布式特性为服务端特效引入的额外复杂性。
可借鉴的开源方案
面对上述问题,我们主要可以将问题归结为:
在高延迟的场景中维持高并发的可能:考虑到整个系统的压力,高延迟的解决方案通常是非阻塞式的异步处理。在同一个服务内部,这往往体现为,通过消息循环解耦并发与线程资源。而在快手的微服务系统中,就要求 Y-tech 特效平台本身考虑非阻塞的接口和实现;
剥离分布式系统造成的复杂性:为了更好地开发人员能力,服务端特效需要一个平台式的基础设施,可以隔离快手微服务系统造成的复杂性,使得特效开发等同于本地应用,开发人员可以专注于特效算法本身。
基于以上考虑,我们调研了部分知名的开源框架。
工作流式服务组织框架
工作流式服务组织框架的出发点是,通过消息系统,解耦微服务间的固定 API 限制,进行灵活的微服务组装。另外带来的额外好处是,每个服务本身都成为了非阻塞式的异步调用。这恰好是我们为了解决高延迟和并发之间的矛盾需要寻求的解决方案。
以 Netflix Conductor 为例,这类系统的通常架构为:
翻译自 https://netflix.github.io/conductor/architecture/
针对 Y-tech 服务端特效场景,这样的架构,有两点值得借鉴:
独立的执行决策服务,以及任务队列,这是整个工作流系统的核心,也可以做到非阻塞地调度不同特效;
对任务元数据的存储和管理,为非阻塞异步任务状态追踪提供必要基础。
而作为通用框架,这些系统通常不会考虑服务端特效本身特点,尤其在计算资源和并发量对用户请求的分配上,并没有进行细节的讨论和解决。
无服务框架
无服务框架可以比较简单的做到服务开发和业务逻辑分离,业务逻辑仅以函数的方式提供给框架,框架本身解决了部署、流量控制等问题。完整的无服务框架与微服务组织框架类似,我们可以将它的主要功能分解为两个层次:
基本的部署和流量调度能力
基于流量,对业务函数进行冷启动和延迟调用的能力
以 kubernetes 上知名的无服务扩展 knative 为例,它依赖 k8s 提供的基本部署和流量调度能力,并且引入了激活器进行流量感知,触发服务冷启动:
根据 youtube 视频 Inside Knative Serving
(https://www.youtube.com/watch?v=-tvQgLbcNtg)整理
作为典型的无服务框架,knative 明显对业务逻辑进行了封装,在这个关封装中,可以注意到:
knative 提供了请求队列,记录流量,做到可以延迟发送请求
请求队列与业务逻辑在不同的容器中,天然利用了容器隔离,在业务逻辑分层的同时,保证业务逻辑不会影响框架本身
类似于前面分析的工作流组织框架,knative 这类无服务框架并没有针对高延迟函数的特别处理,同时需要注意,无服务框架中,容器的启动时间也是影响冷启动流程延迟的重要因素。而 Y-tech 特效通常有较多依赖,容器启动流程较慢。
Y-tech服务端特效平台设计
综上,为了实现非阻塞式 API,考虑引入任务队列,以及单独的任务调度管理,实现任务的调度以及任务运行状态的追踪;另外为进行服务和特效算法的分层开发,同时保持服务稳定,对特效算法和服务外围结构进行进程隔离更为安全。
针对 Y-tech 服务端特效中大量高延迟场景,我们依然面临了一些困难,包括:
为了用有限的资源尽可能提供特效服务,在用户可以接受的范围内,应该允许一定次数重试;
同时由于决定采用非阻塞接口,重试机制在客户端容易引入更大延迟
特效算法本身依赖复杂,单独的容器镜像体积较大,通过镜像方式启动延迟较高
考虑到这些因素,依托快手基础架构,任务平台的基础设计如图:
在开源架构的基础上,我们主要做出如下调整:
在基础的任务队列外,添加延迟重试队列,利用已有队列组件的延迟消息特性,实现任务在资源不足状态下的延迟重试;降低任务丢弃概率
通过快手动态配置组件配合进程隔离方式,动态调整和加载特效算法模块,显著减少特效算法需要重新拉取的执行文件大小
未来计划
服务端特效平台目前已经完成了基本开发,并且上线了若干服务端特效。但我们可以看到,整体结构中仍然有多处可以优化的环节,例如如何更有效的组织输入输出,更大程度的降低体验延迟;或是是否可以有效引入工作流模型,进行特效的进一步组合等等。快手 Y-tech 仍将在服务端设计和实现上进行更多探索尝试。
你可能还想看
等你来
Y-tech
Y-tech团队是快手公司在人工智能领域的探索者和先行者。我们致力于通过计算机视觉、计算机图形学、机器学习、AR/VR/HCI等多领域的交叉探索,一方面帮助每个人更好地进行自我表达和内容创作,另一方面也为用户提供更好的内容体验和交互方式。Y-tech在北京、深圳、杭州、Palo Alto均有研发团队。如果你对我们做的事情感兴趣,欢迎联系并加入我们!
Y-tech长期招聘(全职和实习生):计算机视觉、计算机图形学、多模态技术、机器学习、AI工程架构、美颜技术、特效技术、性能优化、平台开发、工具开发、技术美术、技术产品经理等方向的优秀人才。联系方式:ytechservice@kuaishou.com
Y-tech///