作者:王发康(毅松)
主站接入层是阿里 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 | 周期较短 | 较差 (1x) | 较低 | 高 (100x) | 灵活 |
ASIC | 周期较长 | 好 (4x) | 较高 | 低 (1x) | 有限 |
主站接入层承载集团 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 使用硬件卸载迫在眉睫。
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 卸载有如下两种方案:
FPGA(Field-Programmable Gate Array)现场可编程门阵列,需要对接入层使用的 zlib 算法使用硬件语言重新开发、进行电路烧写,且上层交互驱动也需要从零开发;
智能网卡的方案 1 相比于 QAT 对 zlib 处理没有性能上的优势,智能网卡只是对 zlib 进行软件卸载、相对于 QAT 并不具有加速作用;其方案 2 需要把 Tengine 一部分业务逻辑抽取到网卡中做:如 spdy、http2、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 的通信适配层,此方式对上层业务入侵较小、其软件架构如下图所示:
虽然该方案看起来比较简单,但是真正线上实施的时候还是遇到了非常多的问题(功能、性能方面),譬如:
使用 strace 进行相关系统热点函数统计发现,其 CPU 主要消耗在 ioctl 系统函数上,如下所示:
通过 perf 查看 ioctl 主要是执行内存分配命令,由于 Zlib Shim 需要开辟连续的物理内存、所以出现频繁调用 compact_zone 进行内碎片整理,其调用热的高达 88.096%,如下图所示(注:热度表示该函数该函数自身的热度、调出: 表示被调用函数的热度总和、总体: 热度 + 调出):
同 Intel 研发联调讨论后发现是由于当前 Intel QAT 的 Zlib Shim 的模型不合理所导致,通过推动其改造采用 OOT 的内存管理模块 USDM(内部维护一个 HugePage 内存池)方案解决。
分析其 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 的加速特性更好的发挥。
由于每个 worker 进程都需要分配一个 QAT Instance 用于数据解压缩,Tengine 在 reload 的瞬间 worker 进程数可能会翻倍、而 QAT Instance 初始版本只有 64 个、所以新启动的 worker 进程可能分配不到 Instance、导致请求失败。
针对此问题 Intel 提供的新版本 QAT,其 Instance 数量从 64 提高到 256 个避免此问题的发生,同时我们提出容灾保护方案:当 Instance 无法分配了需要自动降级为软件压缩,提高其可用性。
采用单 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 采用硬件加速的空白,对此领域的发展具有一定的影响意义。
来源: https://yq.aliyun.com/articles/317066