服务器 频道

微信NLP算法微服务治理实践分享

  01 概述

  马斯克收购了推特,但对其技术表示不满。认为主页速度过慢是因为有 1000 多个 RPC。先不评价马斯克所说的原因是否正确,但可以看出,互联网上为用户提供的一个完整的服务,背后会有大量的微服务调用。  

  以微信读书推荐为例,分为召回和排序两个阶段。  

  请求到达后,会先从用户特征微服务拉取特征,把特征组合在一起进行特征筛选,然后调用召回相关的微服务,这一流程还需要乘以一个 N,因为我们是多路召回,会有很多类似的召回流程在同时运行。下面的是排序阶段,从多个特征微服务中拉取相关特征,组合后多次调用排序模型服务。获得最终结果后,一方面将最终结果返回给调用方,另一方面还要将流程的一些日志发送给日志系统留档。

  读书推荐只是微信读书整个 APP 中非常小的一部分,由此可见,即便是一个比较小的服务后面也会有大量的微服务调用。管中窥豹,可以意料到整个微信读书的系统会有巨量的微服务调用。

  大量的微服务带来了什么问题?  

  根据日常工作的总结,主要是有以上三方面的挑战:

  ① 管理方面:主要是围绕如何高效地管理、开发以及部署大量的算法微服务。

  ② 性能方面:要尽量提升微服务,特别是算法微服务的性能。

  ③ 调度方面:如何在多个同类算法微服务之间实现高效合理的负载均衡。

  02 微服务所面临的管理问题

  1. 开发和部署:CI/CD 系统提供自动打包和部署

  第一点是我们提供了一些自动打包和部署的流水线,减轻算法同学开发算法微服务的压力,现在算法同学只需要写一个 Python 函数,流水线会自动拉取预先写好的一系列微服务模板,并将算法同学开发的函数填入,快速搭建微服务。

  2. 扩缩容:任务积压感知自动扩缩容

  第二点是关于微服务的自动扩缩容,我们采取的是任务积压感知的方案。我们会主动去探测某一类任务积压或空闲的程度,当积压超过某一阈值后就会自动触发扩容操作;当空闲达到某一阈值后,也会去触发缩减微服务的进程数。

  3. 微服务组织:图灵完备 DAG / DSL / 自动压测 / 自动部署

  第三点是如何把大量的微服务组织在一起,来构造出完整的上层服务。我们的上层服务是用 DAG 去表示的,DAG 的每一个节点代表一个对微服务的调用,每一条边代表服务间数据的传递。针对 DAG,还专门开发了 DSL(领域特定语言),更好地描述和构造 DAG。并且我们围绕 DSL 开发了一系列基于网页的工具,可以直接在浏览器里进行上层服务的可视化构建、压测和部署。

  4. 性能监控:Trace 系统

  第四点性能监控,当上层服务出现问题时要去定位问题,我们构建了一套自己的 Trace 系统。针对每一个外来请求,都有一整套的追踪,可以查看请求在每一个微服务的耗时,从而发现系统的性能瓶颈。

  03 微服务所面临的性能问题

  一般来说,算法的性能耗时都在深度学习模型上,优化算法微服务的性能很大一部分着力点就在优化深度学习模型 infer 性能。可以选择专用的 infer 框架,或尝试深度学习编译器,Kernel 优化等等方法,对于这些方案,我们认为并不是完全有必要。在很多情况下,我们直接用 Python 脚本上线,一样可以达到比肩 C++ 的性能。

  不是完全有必要的原因在于,这些方案确实能带来比较好的性能,但是性能好不是服务唯一的要求。有一个很著名的二八定律,以人与资源来描述,就是 20% 的人会产生 80% 的资源,换句话说,20% 的人会提供 80% 的贡献。对于微服务来说,也是适用的。

  我们可以把微服务分为两类,首先,成熟稳定的服务,数量不多,可能只占有 20%,但是承担了 80% 的流量。另一类是一些实验性的或者还在开发迭代中的服务,数量很多,占了 80%,但是承担的流量却只占用的 20%,很重要的一点是,经常会有变更和迭代,因此对快速开发和上线也会有比较强的需求。

  前面提到的方法,比如 Infer 框架,Kernel 优化等,不可避免的需要额外消耗开发成本。成熟稳定的服务还是很适合这类方法,因为变更比较少,做一次优化能持续使用很久。另一方面,这些服务承担的流量很大,可能一点点的性能提升,就能带来巨大的影响,所以值得去投入成本。

  但这些方法对于实验性服务就不那么合适了,因为实验性服务会频繁更新,我们无法对每一个新模型都去做新的优化。针对实验性服务,我们针对 GPU 混合部署场景,自研了 Python 解释器 —— PyInter。实现了不用修改任何代码,直接用 Python 脚本上线,同时可以获得接近甚至超过 C++ 的性能。  

  我们以 Huggingface 的 bert-base 为标准,上图的横轴是并发进程数,表示我们部署的模型副本的数量,可以看出我们的 PyInter 在模型副本数较多的情况下 QPS 甚至超越了 onnxruntime。  

  通过上图,可以看到 PyInter 在模型副本数较多的情况下相对于多进程和 ONNXRuntime 降低了差不多 80% 的显存占用,而且大家注意,不管模型的副本数是多少,PyInter 的显存占用数是维持不变的。

  我们回到之前比较基础的问题:Python 真的慢吗?

  没错,Python 是真的慢,但是 Python 做科学计算并不慢,因为真正做计算的地方并非 Python,而是调用 MKL 或者 cuBLAS 这种专用的计算库。

  那么 Python 的性能瓶颈主要在哪呢?主要在于多线程下的 GIL(Global Interpreter Lock),导致多线程下同一时间只能有一个线程处于工作状态。这种形式的多线程对于 IO 密集型任务可能是有帮助的,但对于模型部署这种计算密集型的任务来说是毫无意义的。  

  那是不是换成多进程,就能解决问题呢?  

  其实不是,多进程确实可以解决 GIL 的问题,但也会带来其它新的问题。首先,多进程之间很难共享 CUDA Context/model,会造成很大的显存浪费,这样的话,在一张显卡上部署不了几个模型。第二个是 GPU 的问题,GPU 在同一时间只能执行一个进程的任务,并且 GPU 在多个进程间频繁切换也会消耗时间。

  对于 Python 场景下,比较理想的模式如下图所示:  

  通过多线程部署,并且去掉 GIL 的影响,这也正是 PyInter 的主要设计思路,将多个模型的副本放到多个线程中去执行,同时为每个 Python 任务创建一个单独的互相隔离的 Python 解释器,这样多个任务的 GIL 就不会互相干扰了。这样做集合了多进程和多线程的优点,一方面 GIL 互相独立,另一方面本质上还是单进程多线程的模式,所以显存对象可以共享,也不存在 GPU 的进程切换开销。

  PyInter 实现的关键是进程内动态库的隔离,解释器的隔离,本质上是动态库的隔离,这里自研了动态库加载器,类似 dlopen,但支持“隔离”和“共享”两种动态库加载方式。  

  以“隔离”方式加载动态库,会把动态库加载到不同的虚拟空间,不同的虚拟空间互相之间看不到。以“共享”方式加载动态库,那么动态库可以在进程中任何地方看到和使用,包括各个虚拟空间内部。

  以“隔离”方式加载 Python 解释器相关的库,再以“共享”方式加载 cuda 相关的库,这样就实现了在隔离解释器的同时共享显存资源。

  04 微服务所面临的调度问题

  多个微服务起到同等的重要程度以及同样的作用,那么如何在多个微服务之间实现动态的负载均衡。动态负载均衡很重要,但几乎不可能做到完美。

  为什么动态负载均衡很重要?原因有以下几点:

  (1)机器硬件差异(CPU / GPU);

  (2)Request 长度差异(翻译 2 个字 / 翻译 200 个字);

  (3)Random 负载均衡下,长尾效应明显:

  ① P99/P50 差异可达 10 倍;

  ② P999/P50 差异可达 20 倍。

  (4)对微服务来说,长尾才是决定整体速度的关键。

  处理一个请求的耗时,变化比较大,算力区别、请求长度等都会影响耗时。微服务数量增多,总会有一些微服务命中长尾部分,会影响整个系统的响应时间。

  为什么动态负载均衡难以完美?

  方案一:所有机器跑一遍 Benchmark。

  这种方案不“动态”,无法应对 Request 长度的差异。并且也不存在一个完美的 Benchmark 能反应性能,对于不同模型来说不同机器的反应都会不同。

  方案二:实时获取每一台机器的状态,把任务发给负载最轻的。

  这一方案比较直观,但问题在于在分布式系统中没有真正的“实时”,信息从一台机器传递到另一台机器一定会花费时间,而在这一时间中,机器状态就可以发生了改变。比如在某一瞬间,某一台 Worker 机器是最空闲的,多台负责任务分发的 Master 机器都感知到了,于是都把任务分配给这台最空闲的 Worker,这台最空闲的 Worker 瞬间变成了最忙的,这就是负载均衡中著名的潮汐效应。

  方案三:维护一个全局唯一的任务队列,所有负责任务分发的 Master 都把任务发送到队列中,所有 Worker 都从队列中取任务。

  这一方案中,任务队列本身就可能成为一个单点瓶颈,难以横向扩展。

  动态负载均衡难以完美的根本原因是信息的传递需要时间,当一个状态被观测到后,这个状态一定已经“过去”了。Youtube 上有一个视频,推荐给大家,“Load Balancing is Impossible” https://www.youtube.com/watch?v=kpvbOzHUakA。

  关于动态负载均衡算法,Power of 2 Choices 算法是随机选择两个 worker,将任务分配给更空闲的那个。这个算法是我们目前使用的动态均衡算法的基础。但是 Power of 2 Choices 算法存在两大问题:首先,每次分配任务之前都需要去查询下 Worker 的空闲状态,多了一次 RTT;另外,有可能随机选择的两个 worker 刚好都很忙。为了解决这些问题,我们进行了改进。  

  改进后的算法是 Joint-Idle-Queue。  

  我们在 Master 机器上增加了两个部件,Idle-Queue 和 Amnesia。Idle-Queue 用来记录目前有哪些 Worker 处于空闲状态。Amnesia 记录在最近一段时间内有哪些 Worker 给自己发送过心跳包,如果某个 Worker 长期没有发送过心跳包,那么 Amnesia 就会逐渐将其遗忘掉。每一个 Worker 周期性上报自己是否空闲,空闲的 Worker 选择一个 Master 上报自己的 IdIeness,并且报告自己可以处理的数量。Worker 在选择 Master 时也是用到 Power of 2 Choices 算法,对其他的 Master,Worker 上报心跳包。

  有新的任务到达时,Master 从 Idle-Queue 里随机 pick 两个,选择历史 latency 更低的。如果 Idle-Queue 是空的,就会去看 Amnesia。从 Amnesia 中随机 pick 两个,选择历史 latency 更低的。

  在实际的效果上,采用该算法,可以把 P99/P50 压缩到 1.5 倍,相比 Random 算法有 10 倍的提升。

  05 总结

  在模型服务化的实践中,我们遇到了三个方面的挑战:

  首先是对于大量的微服务,如何进行管理,如何优化开发、上线和部署的流程,我们的解决方案是尽量自动化,抽取重复流程,将其做成自动化流水线和程序;

  第二是模型性能优化方面,如何让深度学习模型微服务运行得更加高效,我们的解决方案是从模型的实际需求出发,对于比较稳定、流量较大的服务进行定制化的优化,对于实验型的服务采用 PyInter,直接用 Python 脚本上线服务,也能达到 C++ 的性能;

  第三是任务调度问题,如何实现动态负载均衡,我们的解决方案是在 Power of 2 Choices 的基础上,开发了 JIQ 算法,大幅缓解了服务耗时的长尾问题。

0
相关文章