资讯专栏INFORMATION COLUMN

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

shadajin / 3225人阅读

摘要:今天分享的主题是阿里七层流量入口硬件加速探索之路。业务驱动了技术创新,年接入层在硬件加速领域迈出了第一步。三监控,对硬件加速相关的资源指标进行实时监控和报警,防患于未然。硬件加速效果上线后我们获得了一些加速效果的数据。

摘要: Tengine在软件层面已经有了深度的调试和优化经验,但是在硬件层面,通用处理器(CPU)已经进入了摩尔定律,有了瓶颈。而在业务量突飞猛进的当下,如何利用硬件来提升性能,承载双11等大型活动的洪峰流量,保障活动平稳度过呢?本文作者:王发康,花名毅松,负责集团主站统一接入层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会在软件和硬件层面继续探索,为集团和用户提供更加高可用、高性能、低成本、安全、运维自动化的系统。

原文链接

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/11370.html

相关文章

  • 一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等

    摘要:内容概述本文将从负载均衡技术的分类技术原理常见实现算法常用方案等入手,为您详细讲解负载均衡技术的方方面面。这其中,四层和七层负载均衡技术最为常用,它们也是本文介绍的重点。对应的负载均衡器称为四层交换机,主要分析层及层,实现四层负载均衡。 1、引言 关于负载均衡的解释,百度词条里:负载均衡,英文叫Load Balance,意思就是将请求或者数据分摊到多个操作单元上进行执行,共同完成工作任...

    keke 评论0 收藏0
  • 微服务网关方案调研

    摘要:综述经调研,使用解决方案的占多数,已经能满足绝大多数公司需求。但除了一些超级公司外,比如阿里,京东,他们是自己撸的一套网关。 综述 经调研,使用Spring Cloud Zuul解决方案的占多数,已经能满足绝大多数公司需求。但除了一些超级公司外,比如阿里,京东,他们是自己撸的一套网关。此外,点评直接采用的nginx负载均衡前置网关,而没用第七层网关,原因据说是七层网关会影响性能,但由于...

    Y3G 评论0 收藏0
  • 简述CDN 什么是CDN 为什么要用CDN CDN适用场景

    摘要:用户向缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端。当处理器引用存储器中的某地址时,高速缓冲存储器便检查是否存有该地址。 考虑到对CDN认知程度的各层小伙伴,开头有必要简单介绍下CDN原理(高年级同学可以直接跳过): 一、CDN的基本原理和基础架构 CDN是将源站内容分发至最接近用户的节点,使用户可就近取得所需内容,提高用户访问的响应速度和成功率。解决因分布...

    番茄西红柿 评论0 收藏0
  • 简述CDN 什么是CDN 为什么要用CDN CDN适用场景

    摘要:用户向缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端。当处理器引用存储器中的某地址时,高速缓冲存储器便检查是否存有该地址。 考虑到对CDN认知程度的各层小伙伴,开头有必要简单介绍下CDN原理(高年级同学可以直接跳过): 一、CDN的基本原理和基础架构 CDN是将源站内容分发至最接近用户的节点,使用户可就近取得所需内容,提高用户访问的响应速度和成功率。解决因分布...

    didikee 评论0 收藏0
  • 人工智能帮助千万用户完成「隐形征信」计算

    摘要:量化派是一家数据驱动的科技金融公司,通过人工智能大数据机器学习等前沿技术提供消费信贷撮合及消费场景下的白条服务,每年处理千万级用户信用及信用消费申请。 「小杨」最近装修房子,准备去银行贷款,但是听说好多人会因为个人征信问题被银行拒绝贷款!于是,他先查了一下自己的央行征信,发现竟然没有自己的征信信息,「小杨」陷入了沉思,自己经常在淘宝、jd 上买东西,也有淘宝花呗和京东白条,怎么会没有征...

    Developer 评论0 收藏0

发表评论

0条评论

shadajin

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<