親歷IntelCPU漏洞的正面襲擊-創(chuàng)新互聯(lián)

作為已經(jīng)3年多沒有寫過代碼的程序員來說，本篇不應(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)，有專門做效果廣告監(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é)。

創(chuàng)新互聯(lián)為您提適合企業(yè)的網(wǎng)站設(shè)計(jì)?讓您的網(wǎng)站在搜索引擎具有高度排名，讓您的網(wǎng)站具備超強(qiáng)的網(wǎng)絡(luò)競(jìng)爭(zhēng)力！結(jié)合企業(yè)自身，進(jìn)行網(wǎng)站設(shè)計(jì)及把握，最后結(jié)合企業(yè)文化和具體宗旨等，才能創(chuàng)作出一份性化解決方案。從網(wǎng)站策劃到做網(wǎng)站、成都做網(wǎng)站， 我們的網(wǎng)頁(yè)設(shè)計(jì)師為您提供的解決方案。

系統(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ù)的情況，所以后來我們自己寫了一套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ù)落地到本地磁盤，一部分?jǐn)?shù)據(jù)發(fā)送至Kafka集群。
3，Storm集群從Kafka讀取數(shù)據(jù)后，做業(yè)務(wù)邏輯處理，其中一部分邏輯要讀寫Redis，一部分邏輯要讀寫Dynamo DB。
4，實(shí)時(shí)的多維用戶行為分析MR程序從Kafka讀取數(shù)據(jù)寫入Kudu，并同步到Hive，離線的數(shù)據(jù)交給Parquet做批量模型處理，最后由Presto視圖做數(shù)據(jù)合并。
5，離線的程序全部交給ETL系統(tǒng)做處理，本次不做介紹。

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

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

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

每個(gè)節(jié)點(diǎn)都增加了一些服務(wù)器后，到了凌晨3、4點(diǎn)鐘整個(gè)集群數(shù)據(jù)在低谷的時(shí)候，Storm的消耗速度依然沒有顯著提升，我們OPS就開始懷疑是不是1月2號(hào)Google發(fā)布的Intel CPU漏洞的問題影響，但在凌晨我們無(wú)法和AWS確認(rèn)技術(shù)細(xì)節(jié)，只能等到1/5號(hào)上班后，我們得到了AWS的確認(rèn)，他們升級(jí)了Intel的CPU內(nèi)核補(bǔ)丁來修復(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的消耗速度開始恢復(fù)，集群消耗Kafka的數(shù)據(jù)也提高到了每10分鐘1200萬(wàn)條以上，監(jiān)控來看數(shù)據(jù)積壓開始下降，而因?yàn)榉e壓數(shù)據(jù)量太大，導(dǎo)致zookeeper的集群壓力也變大，中間我們還升級(jí)了一次zookeeper的磁盤空間，到了1/6號(hào)凌晨集群擠壓的所有數(shù)據(jù)全部消耗完畢，數(shù)據(jù)無(wú)一條丟失，如下圖：

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

帶來的影響：
1，我們服務(wù)的上千家客戶均無(wú)法查看實(shí)時(shí)數(shù)據(jù)，導(dǎo)致所有正在投放廣告的客戶無(wú)法實(shí)時(shí)看到廣告監(jiān)測(cè)效果數(shù)據(jù)，對(duì)投放產(chǎn)生了明顯的影響，時(shí)間之久是我們提供服務(wù)以來史無(wú)前例的。
2，因?yàn)檎wCPU性能下降，導(dǎo)致我們整體計(jì)算能力下降，為了解決問題，不得不增加更多的計(jì)算單元，評(píng)估下來是這樣的：
2.1，Redis整體計(jì)算能力，下降超過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í)緩存來提升性能的，本次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)生的影響來看，我們的系統(tǒng)架構(gòu)還有很多需要完善的地方，而這種CPU級(jí)別的漏洞對(duì)于全球的計(jì)算機(jī)、互聯(lián)網(wǎng)行業(yè)均帶來的影響還是很可怕的，還是希望各個(gè)公司的IT部門盡快修復(fù)此Bug，防止?jié)撛诘?**帶來更大的損失。

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)站名稱：親歷IntelCPU漏洞的正面襲擊-創(chuàng)新互聯(lián)
文章源于：http://muchs.cn/article4/djhcie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、品牌網(wǎng)站設(shè)計(jì)、云服務(wù)器、網(wǎng)站改版、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)