2017双11技术揭秘—千亿级流量来袭，如何用硬件加速技术为CPU减负？

摘要：

在刚过去的2017年双11零点流量高峰的考验下，主站接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提高21%左右。

做者：王发康（毅松）

主站接入层是阿里2015年全站HTTPS项目诞生的产品，目前已经承载集团90%以上的入口流量。2016年主站接入层不只在运维自动化、高可用领域取得重大突破，并且软件层面上也作过不少性能优化，促使2016年双11平稳度过。秉着软硬件结合的性能优化思想，2017年主站接入层在硬件加速领域迈出了第一步。在刚过去的2017年双11零点流量高峰的考验下，主站接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提高21%左右。

背景介绍

众所周知，通用处理器（CPU）的摩尔定律已入暮年，而机器学习和Web服务须要的运算能力却指数级增加。随着现在硬件技术的成熟发展，普通CPU不管是在计算能力，仍是资源成本上相对于一些专用加速硬件已经没有绝对优点，这也促使硬件加速技术获得各大公司的青睐，譬如三大互联网巨头百度、阿里、腾讯内部的接入层采用相似KeyLess方案来加速HTTPS的卸载，不只提升了用户体验，还节省了机器成本。根据当前调研结果发现：目前业内各大公司接入层针对于Gzip采用硬件加速仍是一片空白，阿里接入层首次结合硬件加速技术卸载Gzip不只带来了性能提高，并且对业界在此领域的发展也有重大影响意义。

接入层Tengine当前性能瓶颈是CPU，譬如Gzip模块在Tengine中CPU占比高达15%-20%左右，相比于其它模块CPU消耗高、占比呈增加趋势（后端应用压缩逻辑后续统一前置接入层）、且集中，因此Gzip模块使用硬件卸载对于性能提高、成本优化是不可或缺。

分析与调研

分析前先简单介绍下什么是硬件加速： 硬件加速（Hardware Acceleration）就是利用硬件模块来替代软件算法以充分利用硬件所固有的快速特性（硬件加速一般比软件算法的效率要高），从而达到性能提高、成本优化目的，当前主要是以下两大加速方式：

• FPGA 现场可编程门阵列，可针对某个具体的软件算法进行定制化编程，譬如业内的智能网卡；
• ASIC 专用集成电路，它是面向专门用途的电路、专门为一个用户设计和制造的，譬如Intel的QAT卡仅支持特定加减密、压缩算法；
  FPGA与ASIC的对好比下表格所示：

模式	上市速度	性能	一次性成本	量产成本	可配置
FPGA	周期较短	较差(1x)	较低	高(100x)	灵活
ASIC	周期较长	好(4x)	较高	低(1x)	有限

接入层Tengine CPU消耗分析

主站接入层承载集团90%以上的入口流量，看似只是做为一个七层流量转发网关，可是却作了很是之多的事情，譬如https卸载及加速、单元化、智能流量转发策略、灰度分流、限流、安全防攻击、流量镜像、链路追踪、页面打点等等，这一系列功能的背后是Tengine众多模块的支持。因为功能点比较多，因此这就致使Tengine的CPU消耗比较分散，其主流程处理以下图所示:

各模块CPU消耗占比Top 5以下表格所示：

模块名称	功能介绍	CPU占比
Gzip	解压缩	15%-20%
Sinfo	流量镜像	10%
TMD	限流	8%
Lua	lua相关业务	8%
WAF	防火墙	6%

其它众多模块 ... ...

就当前接入层流量模型分析来看，Gzip单个模块CPU消耗占比达到15%-20%左右（注：主要是压缩消耗）且占比呈上升趋势，因此对Gzip使用硬件卸载迫在眉睫。

加速方案调研

Intel QAT卡

QAT(Quick Assist Technology )是Intel公司推出的一种专用硬件加速卡，不只对SSL非对称加解密算法（RSA、ECDH、ECDSA、DH、DSA等）具备加速，并且对数据的压缩与解压也具备加速效果；QAT加速卡提供zlib压缩算法、且zlib shim对其原生zlib与QAT之间作了适配，调用方式和zlib库方式基本一致，需在上层业务中开启zlib QAT模式、相对来讲对上层业务改造较少.

智能网卡

INIC（Intelligent Network Interface Card）是网络研发事业部自研产品，以网络处理器为核心的高性能网络接入卡，对于网络报文数据的处理很是合适，针对Tengine的gzip卸载有以下两种方案：

• 提供压缩API给host，把压缩数据返回host，由host封包发送；
• host和网卡约定压缩flag，host发送未压缩报文，智能网卡收到后进行压缩，而且从新封包发送；

FPGA卡

FPGA（Field-Programmable Gate Array）现场可编程门阵列，须要对接入层使用的zlib算法使用硬件语言从新开发、进行电路烧写，且上层交互驱动也须要从零开发；

方案对比

智能网卡的方案1相比于QAT对zlib处理没有性能上的优点，智能网卡只是对zlib进行软件卸载、相对于QAT并不具备加速做用；其方案2须要把Tengine一部分业务逻辑抽取到网卡中作：如spdy、http二、chunked、ssl对称加密、响应body限速等逻辑，其成本及风险高，方案3的FPGA方式相对来讲开发成本较高、且相关资源匮乏。

综上所述最终采用QAT加速卡对接入层Tengine的Gzip进行卸载、加速。

方案实施

QAT驱动采用UIO（Userspace I/O）技术，其大部分处于用户态、只有少部分处理硬件中断应答等逻辑处于内核态，这样不只方便用户调试，并且还解决了内核不支持浮点数运算的问题。固然QAT加速卡也顺应了Docker虚拟化的潮流，其采用SRIOV技术，能够在虚拟机之间高效共享PCIe（Peripheral Component Interconnect Express）设备，当前DH895XCC系列芯片最高可支持32个虚拟机共享QAT，从而达到充分利用硬件资源。其次QAT属于ASIC模式相比于FPGA具备更好的加速效果，主要缘由是因为FPGA为了可重构，致使其逻辑查找表、触发器众多以及相同逻辑电路在布线上延时变大。

接入层Tengine目前采用的是下图左边的实线加速链路，其中Zlib Shim、QAT User Space Api、QAT Driver做为Tengine Gzip与底层硬件QAT的通讯适配层，此方式对上层业务入侵较小、其软件架构以下图所示：

虽然该方案看起来比较简单，可是真正线上实施的时候仍是遇到了很是多的问题（功能、性能方面），譬如：

架构不合理

• 使用的初版驱动Intel-Qat2.6.0-60，当QPS为1k左右时CPU很快打满（注：正常状况下QPS为1k时，CPU消耗6%左右），且CPU消耗中90%以上都是消耗在内核态，以下图所示：

使用strace进行相关系统热点函数统计发现，其CPU主要消耗在ioctl系统函数上，以下所示：

经过perf查看ioctl主要是执行内存分配命令，因为Zlib Shim须要开辟连续的物理内存、因此出现频繁调用 compact_zone进行内碎片整理，其调用热的高达88.096%，以下图所示（注：热度表示该函数该函数自身的热度、调出： 表示被调用函数的热度总和、整体： 热度 + 调出）：

同Intel研发联调讨论后发现是因为当前Intel QAT的Zlib Shim的模型不合理所致使，经过推进其改造采用OOT的内存管理模块USDM（内部维护一个HugePage内存池）方案解决。

• 使用上述问题解决后的驱动intel-qatOOT31092，测试后发现CPU节省效果不佳（用户态CPU减小、可是增长了内核态的CPU），经分析、发现使用QAT加速后，部分系统函数CPU占比变高，如 open、ioctl、futex，以下图所示（注：左边的是使用QAT后各系统热点函数），使用QAT后open、ioctl、futex执行时间占比高达8.95（注：3.91 + 2.68 + 2.36），而未使用版本对应占比时间才0.44（注：0.24 + 0.14 + 0.06）；

分析其Tengine的worker进程堆栈信息发现open、ioctl都是成对出现（即一次http请求出现4次该系统调用），该现象反馈给Intel的研发同窗后得知是因为新驱动的Zlib Shim致使，经过优化改造后open、ioctl调用频率明显减小。可是其futex系统调用频度却没有减小，仍是致使内核态的CPU占比较高，经过strace跟踪发现一个http压缩请求后会屡次调用futex、以下图所示，同Intel研发同窗了解到Zlib Shim采用多线程方式，其futex操做来自zlib shim等待QAT压缩或解压缩数据返回的逻辑。

因为Tengine是多进程单线程、采用epoll异步IO事件模式，联调Intel的研发同窗对Zlib Shim进行改造（去线程），最终futex系统调用也明显减小。

经过分析并推进Intel对QAT进行屡次架构上的改造，才使得QAT的加速特性更好的发挥。

功能不完善

• 使用QAT后执行reload，可能致使请求响应异常，以下所示：

因为每一个worker进程都须要分配一个QAT Instance用于数据解压缩，Tengine在reload的瞬间worker进程数可能会翻倍、而QAT Instance初始版本只有64个、因此新启动的worker进程可能分配不到Instance、致使请求失败。
针对此问题Intel提供的新版本QAT，其Instance数量从64提升到256个避免此问题的发生，同时咱们提出容灾保护方案：当Instance没法分配了须要自动降级为软件压缩，提升其可用性。

• Zlib Shim huge page内存泄漏，致使QAT驱动core dump：
  Tengine使用内存池模式进行内存的管理，即调用(In)DeflateInit分配的空间无需调用(In)DeflateEnd处理、在请求结束的时候会调用请求r相关的释放操做，进行内存的归还，可是因为Zlib Shim使用的huge page必须调用(In)DeflateEnd才释放给USDM，经过改造Tengine Gzip相关代码后，该问题得以解决，而QAT驱动的core dump也是因为hugepage的泄漏致使没法成功分配致使。
• Zlib Shim状态机不完善致使特定场景下的压缩、解压缩请求异常，等众多问题就不一一介绍。
  一路走来，经过无数次的性能优化、功能测试，屡次同Intel研发同窗一块儿探讨以后，才使得QAT在功能、性能、架构方面等众多问题得以快速解决，下面就准备上线前期准备工做。

运维梳理

部署发布
采用单rpm软件包、双二进制模式，从而下降软件版与硬件加速版之间的耦合度，自动识别部署机器是否开启QAT，并选择正确的二进制执行；

容灾保护
运行过程当中因为某种资源的缺少致使硬件加速版本Gzip执行失败，将会自动切换为软件版本、待资源可用时自动切换到硬件加速版本；

可维护与监控
虽然上线前作过一系列压测、稳定性并未出现异常，但对硬件加速的相关资源指标进行实时监控仍是必不可少；

加速效果

测试机器
cpu型号：Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 32核 内核：2.6.32 Zlib版本：zlib-1.2.8 QAT驱动版本：intel-qatOOT40052
数据对比
同等条件下，开启QAT加速后CPU平均值为41%左右，未开启QAT加速的CPU平均值为48%左右，以下图所示：

相同条件下，开启QAT加速后系统load平均值为12.09，关闭QAT加速时系统load平均值为14.22，以下图所示：

相同条件下，开启与关闭QAT加速后，响应RT波动不相上下，以下所示：

同等条件下，各模块热点函数图对好比下所示，其中红色圈中的是Gzip相关函数（注：左侧是开启QAT加速）：

同比条件下Tengine Gzip使用QAT加速卡后，CPU消耗从48%降低到41%，系统负载load降低2个，且根据模块热点函数图对比发现Gzip基本上已经彻底卸载。

场景	CPU消耗	系统负载load	响应时间RT（ms）
开启QAT加速	41%	12.09	58.88
关闭QAT加速	48%	14.22	59.47

结论
综上数据对比，当qps为10k左右时Tengine Gzip使用QAT加速后CPU节省15%左右，且Gzip基本上彻底卸载、随着其占比变高，优化效果将越好。

在双11零点高峰的考验下，接入层Tengine Gzip硬件加速机器运行平稳、同等条件下相比于未开启QAT加速的机器性能提高21%左右；

总结

接入层Tengine Gzip硬件加速项目是阿里存储技术Tair&Tengine团队及服务器研发计算团队与英特尔数据中心网络平台团队齐心合力下的产物，不只带来了性能提高，并且使得接入层在硬件加速领域再次打下了坚实的基础、为明年SSL+Gzip架构上整合作好了沉淀，同时也填充了业内接入层对Gzip采用硬件加速的空白，对此领域的发展具备必定的影响意义。

点击查看原文