Tengine 在软件层面已经有了深度的调试和优化经验, 但是在硬件层面, 通用处理器 (CPU) 已经进入了摩尔定律, 有了瓶颈. 而在业务量突飞猛进的当下, 如何利用硬件来提升性能, 承载双 11 等大型活动的洪峰流量, 保障活动平稳度过呢?
接入层系统介绍
接入层是 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: https://github.com/alibaba/tengine
作者 Github: https://github.com/wangfakang
[招聘广告] Tengine 资深开发工程师 / 研发专家
负责阿里巴巴集团基础 web 服务平台软件设计与开发;
负责阿里巴巴集团图片处理服务平台的构建和研发;
主导架构设计, 系统的演进和技术难题攻关, 满足迅速增长的阿里巴巴集团平台的业务与性能要求;
负责通过软硬件结合的方式来提升整体性能;
熟悉 nginx/tengine/openresty/openssl 等至少一种开发经验;
欢迎志同道合的伙伴加入, 联系邮箱: fakang.wfk@alibaba-inc.com
来源: https://yq.aliyun.com/articles/597750