親歷Intel CPU漏洞的正面襲擊

作為已經(jīng)3年多沒(méi)有寫(xiě)過(guò)代碼的程序員來(lái)說(shuō)，本篇不應(yīng)該算是一篇技術(shù)型的文章，而是作為服務(wù)上千家客戶的ToB大數(shù)據(jù)創(chuàng)業(yè)公司的一次經(jīng)歷，可能很多人對(duì)于我們的產(chǎn)品了解并不多，所以我先簡(jiǎn)單介紹下我們的技術(shù)和業(yè)務(wù)應(yīng)用場(chǎng)景，我們有多個(gè)SaaS產(chǎn)品，有給游戲公司提供免費(fèi)使用的游戲數(shù)據(jù)分析平臺(tái)，有專門(mén)做效果廣告監(jiān)測(cè)的Ad Tracking系統(tǒng)，以及把移動(dòng)廣告監(jiān)測(cè)和多維用戶行為分析數(shù)據(jù)打通的TrackingIO系統(tǒng)，其中系統(tǒng)架構(gòu)較為復(fù)雜的是TrackingIO，同時(shí)使用TrackingIO的客戶也較多，每天的數(shù)據(jù)點(diǎn)數(shù)為幾十億的規(guī)模，而本文標(biāo)題中提到的Intel CPU漏洞對(duì)于我們的幾個(gè)SaaS產(chǎn)品均有影響，我主要以TrackingIO作為案例總結(jié)。

系統(tǒng)架構(gòu)介紹：
TrackingIO的技術(shù)架構(gòu)方面，我們使用了典型的Haddop生態(tài)系統(tǒng)作為大數(shù)據(jù)架構(gòu)基礎(chǔ)，2016年我們使用混合云的方式部署的服務(wù)，2017年都遷移到了AWS，其中用戶Log收集的服務(wù)我們?cè)缙谑褂肧cribed和Flume但是發(fā)現(xiàn)均存在丟數(shù)據(jù)的情況，所以后來(lái)我們自己寫(xiě)了一套Java的分布式的日志收集系統(tǒng)，實(shí)時(shí)計(jì)算方面我們用典型的Kafka + Storm的流式計(jì)算架構(gòu)，持久化的NoSql數(shù)據(jù)庫(kù)一部分用了Redis，一部分用了AWS的DynamoDB，實(shí)時(shí)用戶行為分析的部分是結(jié)合了Parquet + Kudu + Presto，離線計(jì)算用AWS EMR + Hive， 另外離線數(shù)據(jù)挖掘的獨(dú)立系統(tǒng)我們用了Spark，系統(tǒng)架構(gòu)如下：

數(shù)據(jù)流向：

整體架構(gòu)：

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

發(fā)現(xiàn)漏洞影響的過(guò)程：
我們的系統(tǒng)是部署在AWS上的，平時(shí)正常情況下，即便是每天在數(shù)據(jù)發(fā)送的高峰期間，Storm消耗Kafka集群的數(shù)據(jù)也不會(huì)有Message Lag，而1/4號(hào)從傍晚開(kāi)始，我們的監(jiān)控系統(tǒng)開(kāi)始發(fā)現(xiàn)有Kafka數(shù)據(jù)堆積，很快數(shù)據(jù)擠壓就超過(guò)了2億條，如圖所示：

Kafka數(shù)據(jù)堆積的問(wèn)題，可能由不同的因素引發(fā)，比如之前我們就遇到過(guò)Dynamo DB的讀寫(xiě)并發(fā)高導(dǎo)致Storm的數(shù)據(jù)消耗慢的情況，除了Kafka數(shù)據(jù)的堆積，我們還發(fā)現(xiàn)Receiver Cluster也出現(xiàn)了整體處理性能的下降，Timeout等問(wèn)題。

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

每個(gè)節(jié)點(diǎn)都增加了一些服務(wù)器后，到了凌晨3、4點(diǎn)鐘整個(gè)集群數(shù)據(jù)在低谷的時(shí)候，Storm的消耗速度依然沒(méi)有顯著提升，我們OPS就開(kāi)始懷疑是不是1月2號(hào)Google發(fā)布的Intel CPU漏洞的問(wèn)題影響，但在凌晨我們無(wú)法和AWS確認(rèn)技術(shù)細(xì)節(jié)，只能等到1/5號(hào)上班后，我們得到了AWS的確認(rèn)，他們升級(jí)了Intel的CPU內(nèi)核補(bǔ)丁來(lái)修復(fù)Intel CPU的漏洞，導(dǎo)致所有服務(wù)器的CPU性能均有下降，其中我們用的r3.large（3代CPU）的類型影響最大。

解決辦法：
在得到AWS官方確認(rèn)后，我們將整個(gè)Redis集群使用的CPU類型升級(jí)到了r4.xlarge，同時(shí)增大了Redis集群服務(wù)器規(guī)模之后，Storm的消耗速度開(kāi)始恢復(fù)，集群消耗Kafka的數(shù)據(jù)也提高到了每10分鐘1200萬(wàn)條以上，監(jiān)控來(lái)看數(shù)據(jù)積壓開(kāi)始下降，而因?yàn)榉e壓數(shù)據(jù)量太大，導(dǎo)致zookeeper的集群壓力也變大，中間我們還升級(jí)了一次zookeeper的磁盤(pán)空間，到了1/6號(hào)凌晨集群擠壓的所有數(shù)據(jù)全部消耗完畢，數(shù)據(jù)無(wú)一條丟失，如下圖：

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

帶來(lái)的影響：
1，我們服務(wù)的上千家客戶均無(wú)法查看實(shí)時(shí)數(shù)據(jù)，導(dǎo)致所有正在投放廣告的客戶無(wú)法實(shí)時(shí)看到廣告監(jiān)測(cè)效果數(shù)據(jù)，對(duì)投放產(chǎn)生了明顯的影響，時(shí)間之久是我們提供服務(wù)以來(lái)史無(wú)前例的。
2，因?yàn)檎wCPU性能下降，導(dǎo)致我們整體計(jì)算能力下降，為了解決問(wèn)題，不得不增加更多的計(jì)算單元，評(píng)估下來(lái)是這樣的：
2.1，Redis整體計(jì)算能力，下降超過(guò)50%
2.2，Receiver Cluster等網(wǎng)絡(luò)IO密集型服務(wù)，下降30%
2.3，編譯執(zhí)行的程序，下降20%左右
2.4，其他服務(wù)器，下降5%左右

為什么Redis性能下降如此明顯：
1方面是因?yàn)锳WS的第三代Intel CPU受漏洞影響最為嚴(yán)重，性能下降最多，另外1方面，Redis的設(shè)計(jì)是特別依賴CPU的2、3級(jí)緩存來(lái)提升性能的，本次Intel CPU漏洞補(bǔ)丁修復(fù)后，導(dǎo)致CPU的緩存能力下降，從而影響Redis的性能（這塊還需要深入做專業(yè)度更強(qiáng)的技術(shù)研究）

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

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

詳解Intel漏洞怎么拿到內(nèi)核數(shù)據(jù)的：
https://mp.weixin.qq.com/s/2OBig3rejp1yUupBH9O7FA

比較專業(yè)的分析Meltdown和Spectre漏洞的文章：

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

結(jié)語(yǔ)：
從本次漏洞產(chǎn)生的影響來(lái)看，我們的系統(tǒng)架構(gòu)還有很多需要完善的地方，而這種CPU級(jí)別的漏洞對(duì)于全球的計(jì)算機(jī)、互聯(lián)網(wǎng)行業(yè)均帶來(lái)的影響還是很可怕的，還是希望各個(gè)公司的IT部門(mén)盡快修復(fù)此Bug，防止?jié)撛诘?**帶來(lái)更大的損失。

最后感謝我們所有客戶的理解和支持，我們將一如既往提供越來(lái)越完善的大數(shù)據(jù)產(chǎn)品和服務(wù)！在應(yīng)對(duì)突發(fā)問(wèn)題上相信我們的工程師團(tuán)隊(duì)能夠做的越來(lái)越好。