親歷Intel CPU漏洞的正面襲擊

作為已經3年多沒有寫過代碼的程序員來說，本篇不應該算是一篇技術型的文章，而是作為服務上千家客戶的ToB大數據創業公司的一次經歷，可能很多人對于我們的產品了解并不多，所以我先簡單介紹下我們的技術和業務應用場景，我們有多個SaaS產品，有給游戲公司提供免費使用的游戲數據分析平臺，有專門做效果廣告監測的Ad Tracking系統，以及把移動廣告監測和多維用戶行為分析數據打通的TrackingIO系統，其中系統架構較為復雜的是TrackingIO，同時使用TrackingIO的客戶也較多，每天的數據點數為幾十億的規模，而本文標題中提到的Intel CPU漏洞對于我們的幾個SaaS產品均有影響，我主要以TrackingIO作為案例總結。

系統架構介紹：
TrackingIO的技術架構方面，我們使用了典型的Haddop生態系統作為大數據架構基礎，2016年我們使用混合云的方式部署的服務，2017年都遷移到了AWS，其中用戶Log收集的服務我們早期使用Scribed和Flume但是發現均存在丟數據的情況，所以后來我們自己寫了一套Java的分布式的日志收集系統，實時計算方面我們用典型的Kafka + Storm的流式計算架構，持久化的NoSql數據庫一部分用了Redis，一部分用了AWS的DynamoDB，實時用戶行為分析的部分是結合了Parquet + Kudu + Presto，離線計算用AWS EMR + Hive， 另外離線數據挖掘的獨立系統我們用了Spark，系統架構如下：

數據流向：

整體架構：

主要的業務場景：
1，客戶在客戶端，或者服務器端接我們的Android、iOS、REST API的SDK，報送數據到我們的Log Receiver的Cluster。
2，Receiver的集群收到數據后做一些業務邏輯處理后，一部分數據落地到本地磁盤，一部分數據發送至Kafka集群。
3，Storm集群從Kafka讀取數據后，做業務邏輯處理，其中一部分邏輯要讀寫Redis，一部分邏輯要讀寫Dynamo DB。
4，實時的多維用戶行為分析MR程序從Kafka讀取數據寫入Kudu，并同步到Hive，離線的數據交給Parquet做批量模型處理，最后由Presto視圖做數據合并。
5，離線的程序全部交給ETL系統做處理，本次不做介紹。

發現漏洞影響的過程：
我們的系統是部署在AWS上的，平時正常情況下，即便是每天在數據發送的高峰期間，Storm消耗Kafka集群的數據也不會有Message Lag，而1/4號從傍晚開始，我們的監控系統開始發現有Kafka數據堆積，很快數據擠壓就超過了2億條，如圖所示：

Kafka數據堆積的問題，可能由不同的因素引發，比如之前我們就遇到過Dynamo DB的讀寫并發高導致Storm的數據消耗慢的情況，除了Kafka數據的堆積，我們還發現Receiver Cluster也出現了整體處理性能的下降，Timeout等問題。

在數據流量沒有異常增加的情況下，我們程序也沒有做什么更新，出現這個現象，我們還是有諸多疑惑的，然而解決問題是首要任務，OPS給Storm的集群逐步增加了4倍的服務器，給Receiver Cluster增加了30%的服務器，Receiver的問題很快解決了，然而發現Kafka堆積的消耗還是沒有快多少，反而擠壓越來越多，數據消耗每10分鐘只有不到500萬條，從Redis的監控數據看連接數是上來了（如圖），但Storm的Spout程序有很多超時發生。

每個節點都增加了一些服務器后，到了凌晨3、4點鐘整個集群數據在低谷的時候，Storm的消耗速度依然沒有顯著提升，我們OPS就開始懷疑是不是1月2號Google發布的Intel CPU漏洞的問題影響，但在凌晨我們無法和AWS確認技術細節，只能等到1/5號上班后，我們得到了AWS的確認，他們升級了Intel的CPU內核補丁來修復Intel CPU的漏洞，導致所有服務器的CPU性能均有下降，其中我們用的r3.large（3代CPU）的類型影響最大。

解決辦法：
在得到AWS官方確認后，我們將整個Redis集群使用的CPU類型升級到了r4.xlarge，同時增大了Redis集群服務器規模之后，Storm的消耗速度開始恢復，集群消耗Kafka的數據也提高到了每10分鐘1200萬條以上，監控來看數據積壓開始下降，而因為積壓數據量太大，導致zookeeper的集群壓力也變大，中間我們還升級了一次zookeeper的磁盤空間，到了1/6號凌晨集群擠壓的所有數據全部消耗完畢，數據無一條丟失，如下圖：

目前來看，解決本次Intel CPU漏洞的辦法就是增加機器，對于CPU密集型或者依賴CPU緩存的服務則增加了更多服務器。（本案例基于服務部署在AWS上的情況）
如果沒有用云服務，延遲修復Intel CPU漏洞，讓服務器帶著漏洞裸奔，也不會受此影響，但不排除有被******，盜取數據的風險。

帶來的影響：
1，我們服務的上千家客戶均無法查看實時數據，導致所有正在投放廣告的客戶無法實時看到廣告監測效果數據，對投放產生了明顯的影響，時間之久是我們提供服務以來史無前例的。
2，因為整體CPU性能下降，導致我們整體計算能力下降，為了解決問題，不得不增加更多的計算單元，評估下來是這樣的：
2.1，Redis整體計算能力，下降超過50%
2.2，Receiver Cluster等網絡IO密集型服務，下降30%
2.3，編譯執行的程序，下降20%左右
2.4，其他服務器，下降5%左右

為什么Redis性能下降如此明顯：
1方面是因為AWS的第三代Intel CPU受漏洞影響最為嚴重，性能下降最多，另外1方面，Redis的設計是特別依賴CPU的2、3級緩存來提升性能的，本次Intel CPU漏洞補丁修復后，導致CPU的緩存能力下降，從而影響Redis的性能（這塊還需要深入做專業度更強的技術研究）

關于Intel CPU漏洞：
原始文章：（需要×××）
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

如何看待 2018 年 1 月 2 日爆出的 Intel CPU 設計漏洞？
https://www.zhihu.com/question/265012502/answer/289320187?utm_medium=social&utm_source=wechat_session&from=timeline&isappinstalled=0

詳解Intel漏洞怎么拿到內核數據的：
https://mp.weixin.qq.com/s/2OBig3rejp1yUupBH9O7FA

比較專業的分析Meltdown和Spectre漏洞的文章：

1. https://meltdownattack.com/meltdown.pdf
2. https://spectreattack.com/spectre.pdf
3. https://securitytracker.com/id/1040071

結語：
從本次漏洞產生的影響來看，我們的系統架構還有很多需要完善的地方，而這種CPU級別的漏洞對于全球的計算機、互聯網行業均帶來的影響還是很可怕的，還是希望各個公司的IT部門盡快修復此Bug，防止潛在的***帶來更大的損失。

最后感謝我們所有客戶的理解和支持，我們將一如既往提供越來越完善的大數據產品和服務！在應對突發問題上相信我們的工程師團隊能夠做的越來越好。