亲历IntelCPU漏洞的正面袭击-创新互联
作为已经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漏洞的文章:
- https://meltdownattack.com/meltdown.pdf
- https://spectreattack.com/spectre.pdf
- https://securitytracker.com/id/1040071
结语:
从本次漏洞产生的影响来看,我们的系统架构还有很多需要完善的地方,而这种CPU级别的漏洞对于全球的计算机、互联网行业均带来的影响还是很可怕的,还是希望各个公司的IT部门尽快修复此Bug,防止潜在的***带来更大的损失。
最后感谢我们所有客户的理解和支持,我们将一如既往提供越来越完善的大数据产品和服务!在应对突发问题上相信我们的工程师团队能够做的越来越好。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网站栏目:亲历IntelCPU漏洞的正面袭击-创新互联
网页URL:http://pwwzsj.com/article/djhcie.html