1. 程式人生 > >親歷Intel CPU漏洞的正面襲擊

親歷Intel CPU漏洞的正面襲擊

全部 就是 數據合並 更新 疑惑 無法查看 而是 lin 了解

作為已經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,防止潛在的攻擊帶來更大的損失。

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

親歷Intel CPU漏洞的正面襲擊