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採用硬件加速的空白，對此領域的發展具備必定的影響意義。

點擊查看原文