阿里七层流量入口 Tengine硬件加速探索之路

Tengine在软件层面已经有了深度的调试和优化经验,但是在硬件层面,通用处理器(CPU)已经进入了摩尔定律,有了瓶颈。而在业务量突飞猛进的当下,如何利用硬件来提升性能,承载双11等大型活动的洪峰流量,保障活动平稳度过呢?

本文作者:王发康,花名毅松,负责集团主站统一接入层Tengine的开发与维护。今天分享的主题是《阿里七层流量入口Tengine硬件加速探索之路》。

接入层系统介绍

接入层是2015年阿里巴巴全站HTTPS诞生的一个产品。作为一个电商网站,为了保护用户信息安全、账户、交易的安全,全站HTTPS是势在必行,如果淘宝、天猫、聚划算等各业务方在后端各自做接入层,机器成本高,而且证书管理复杂。为了解决问题,我们做了统一接入层,来做HTTPS卸载和流量分发等通用功能。

所有的阿里集团流量通过四层LVS,到达统一接入层,统一接入层根据不同的维度域名转发到对应的后端APP,并且提供智能的流量分发策略。因为抽象出一层,通用的安全防攻击、链路追踪等高级功能,都可以在这一层统一实现。



接入层是集团所有流量的入口,它的稳定性是非常重要的。同时,接入层提供了这么多高级功能,所以对其性能的挑战也非常大。业务驱动了技术创新,2017年接入层在硬件加速领域迈出了第一步。

性能瓶颈分析及解决

我们要对自己的系统做性能优化,首先我们要找到系统的瓶颈点,并且进行分析与调研。

主站接入层承载集团90%以上的入口流量,同时支持着很多高级功能,比如HTTPS卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等,这一系列功能的背后是Tengine众多模块的支持。由于功能点比较多,所以这就导致Tengine的CPU消耗比较分散,消耗CPU比较大的来自两个处HTTPS和Gzip,这就是性能瓶颈之所在。

一、HTTPS卸载篇

虽然全站HTTPS已经是一个老生常谈的话题,但是国内为何能做到的网站却还是屈指可数?原因简单总结来说有两点,首先使用HTTPS后使得网站访问速度变“慢”,其次导致服务器CPU消耗变高、从而机器成本变“贵”。

软件优化方案:如Session复用、OCSP Stapling、False Start、dynamic record size、TLS1.3、HSTS等。 但软件层面如何优化也无法满足流量日益增长的速度,加上CPU摩尔定律已入暮年,使得专用硬件卸载CPU密集型运算成为业界一个通用解决方案。

Tengine基于Intel QAT的异步加速方案总体架构



由三部分组成Tengine的ssl_async指令、OpenSSL + QAT Engine及QAT Driver。其中Tengine通过适配OpenSSL-1.1.0的异步接口,将私钥操作卸载至Intel提供的引擎(QAT engine)中,引擎通过 QAT驱动调用硬件完成非对称算法取回结果。

该方案在Tengine2.2.2中已经开源。

Tengine启用ssl_async QAT加速后的效果如何?

RSA套件提升3.8倍(8核时)
ECDHE-RSA提升2.65倍(8核时)
ECDHE-ECDSA(P-384) 提升2倍(16核时)
ECDHE-ECDSA(P-256) 8核达到QAT硬件处理峰值16k左右, 只有23%的性能提升。



HTTPS卸载方案可以减少物理机数量,节省CPU资源,为公司带来价值。

二、Gzip卸载篇

当前接入层Gzip模块的CPU占比达到15-20%,如果我们能卸载掉Gzip的CPU消耗,让出来的CPU就可以用于处理更多请求和提升性能。

然而目前业内各大公司接入层针对于Gzip采用硬件加速还是一片空白,阿里在接入层结合硬件加速技术卸载Gzip调研了几套方案:


方案一是和Intel合作的QAT卡的加速方案,直接把相关软件算法固化到硬件中去,链路会更精简。
方案二智能网卡方案,需要把Tengine一部分业务逻辑抽取到网卡中做,其成本及风险高,而且只是对zlib进行软件卸载,相对于QAT并不具有加速作用。
方案三是FPGA卡方案,相对来说开发成本较高,且相关资源匮乏。

综上评估,选择方案一对Gzip进行卸载及加速。

Tengine Gzip 硬件加速方案实践

左边的图是软件方案,请求进来后,在软件层面做一些压缩,全部是用CPU在做。右边是通过QAT卡来加速,把红色那部分全部卸载到QAT卡里,通过改造Tengine中的Gzip这个模块,让它去调用QAT的驱动,通过硬件做压缩,最终送回Tengine传输给用户。



在这个过程中,我们也遇到了非常多的坑。

使用的第一版驱动Intel-Qat 2.6.0-60,当QPS为1k左右时,从上图可以看出,横坐标是时间,纵坐标是CPU消耗百分比,跑到第五秒左右,CPU很快打满,这相当于根本跑不起来。


针对这个问题,我们使用strace进行相关系统热点函数统计发现,其CPU主要消耗在ioctl系统函数上,如下所示:


ioctl主要是做上层应用程序和底层通讯的,并且CPU消耗中90%以上都是消耗在内核态。因为最初的每个压缩请求都要送到硬件中去,buffer需要开辟连续的物理内存,系统跑久了,一旦遇到连续内存分配不成功的情况,就会需要ioctl去分配内存,出现频繁调用 compact_zone进行内碎片整理,其调用热的高达88.096%,如果分配失败了,就会触发内存去做碎片整理,所以就会出现sys态CPU持续上升的情况。

这个问题解决后,也并没有那么顺利,我们遇到了下面的问题。

在日常压测时,我们发现CPU用了Gzip卸载方案后,节省效果上并没有明显的提升。user态CPU降低了10%左右,但是sys态CPU相对于软件版的CPU提升了10%。所以,节省效果不明显。

经分析,我们发现使用QAT后,部分系统函数CPU占比变高,如下图所示(注:左边的是使用QAT后各系统热点函数,右边是软件版原生tengine的各系统热点函数)open、ioctl、futex执行 时间占比高达8.95(注:3.91 + 2.68 + 2.36),而未使用版本对应占比时间才0.44(注:0.24 + 0.14 + 0.06)。


open和ioctl是由于Zlib Shim适配层处理逻辑有一些问题,通过优化改造后open、ioctl调用频率明显减少。但是其futex系统调用频度却没有减少,还是导致内核态的CPU占比较高,通过strace跟踪发现一个http压缩请求后会多次调用futex,Zlib Shim采用多线程方式,其futex操作来自zlib shim等待QAT压缩或解压缩数据返回的逻辑,由于Tengine是多进程单线程、采用epoll异步IO事件模式,联调Intel的研发同学对Zlib Shim进行改造(去线程),最终futex系统调用也明显减少。

一路走来,通过无数次的性能优化、功能测试,我们与Intel研发同学一起探讨之后,才使得QAT在功能、性能、架构方面等众多问题得以快速解决。

运维与监控

问题解决后,接下来我们进行上线前的准备。

一、压测和演练,这里主要关注高流量、压缩与解压缩流量混跑等情况下的性能提升情况,同时关注数据完整性校验。
二、容灾保护,在运行过程中,当硬件资源缺乏导致Gzip执行失败,会自动切换软件版本,硬件资源恢复后自动切回。
三、监控,对硬件加速相关的资源指标进行实时监控和报警,防患于未然。
四、部署与发布,因为存在硬件和软件两个版本,所以采用单rpm软件包、双二进制模式,从而降低软件版与硬件加速版之间的耦合度,自动识别部署机器是否开启QAT,并选择正确的二进制执行。



硬件加速效果

上线后我们获得了一些加速效果的数据。当QPS为10k左右时,Tengine Gzip使用QAT加速后,CPU节省在15%左右,且Gzip基本上完全卸载,随着其占比变高,优化效果将越来越好。在2017年双11零点流量峰值附近,Tengine加速机器相比普通机器性能提升 21%。



展望及总结

Tengine首次采用硬件加速技术卸载Gzip,不仅带来性能上的提升,而且使得接入层在硬件加速领域再次打下了坚实的基础,对业界在此领域的发展也有重大影响意义。在未来,Tengine会在软件和硬件层面继续探索,为集团和用户提供更加高可用、高性能、低成本、安全、运维自动化的系统。



Tengine官网:http://tengine.taobao.org

Tengine Github:github.com/alibaba/teng

作者Github:github.com/wangfakang


本文作者:樰篱

原文链接

更多技术干货敬请关注云栖社区知乎机构号:阿里云云栖社区 - 知乎

本文为云栖社区原创内容,未经允许不得转载。

文章被以下专栏收录