91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

親歷Intel CPU漏洞的正面襲擊

發布時間:2020-06-22 02:12:00 來源:網絡 閱讀:1222 作者:Tonyreyun 欄目:安全技術

作為已經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,系統架構如下:

數據流向:
親歷Intel CPU漏洞的正面襲擊

整體架構:
親歷Intel CPU漏洞的正面襲擊

主要的業務場景:
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億條,如圖所示:
親歷Intel CPU漏洞的正面襲擊

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

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

親歷Intel CPU漏洞的正面襲擊

每個節點都增加了一些服務器后,到了凌晨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漏洞的正面襲擊

目前來看,解決本次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,防止潛在的***帶來更大的損失。

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

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

大厂| 乌海市| 天等县| 莫力| 永胜县| 麻江县| 麟游县| 黑水县| 宁阳县| 女性| 高阳县| 汉源县| 井冈山市| 广平县| 临桂县| 青河县| 望江县| 醴陵市| 台江县| 读书| 淮南市| 青川县| 霞浦县| 尼玛县| 乌恰县| 通辽市| 黔南| 波密县| 建昌县| 含山县| 漳浦县| 平果县| 伽师县| 乌兰县| 扎兰屯市| 饶阳县| 滦平县| 筠连县| 临泉县| 谢通门县| 昌邑市|