首页 -> 新闻中心 -> 云计算 -> 正文
GrowingIO运维总监王硕:Auto Scaling System for AWS
2017-08-07

王硕

大家好,我叫王硕,来自于 GrowingIO。

刚才听上一个演讲嘉宾讲精益看板很有感触,作为运维来讲,在某些公司有时候会非常痛苦,因为出了问题大家都会先找你,恨不得你就是那个干坏事的人,背锅的人,有些公司出大问题,老板会站在你身后看你去解决问题,而且日常会有很多插入的工作,最终会导致工作不是那么开心。我之前就职的两家公司都是外企,更讲究有效率的工作和加班,其实还是比较不错的,即使加班也会有加班费,法定节假日加班是 3 倍工资。每天工作不会让你干满 8 个小时,6 个小时已经不错了,如果你能高效干 4 个小时已经挺好了。如果你去参加开发者大会经常会听到敏捷这个词,在之前的公司当中,我们就是用 Scrum 来高效的管理 DevOps 团队的。

今天我讲的演讲主题是如何基于 AWS 做自动伸缩系统,AWS 是云计算的鼻祖,是最开始做云计算的。我们在 AWS 还没有提供自动伸缩服务之前我们就已经做出了自动伸缩系统,而且是使用了 Spot Instances,也就是竞价实例。

在进入正题之前先介绍一下 GrowingIO,GrowingIO 是基于用户行为的新一代数据分析产品,无需埋点即可采集全量、实时用户行为数据,数据分析更精细,帮助管理者、产品经理、市场运营、数据分析师、增长黑客等提升转化率、优化网站 / APP,实现用户快速增长和变现。这是一件非常有挑战的事情。放眼今天我们来看整个运维行业,如果你只是一个传统的 Ops,在大公司做一颗螺丝钉是完全没有问题的,但是如果你想去一家创业公司,你想让自己变得有竞争力,你必须成为 DevOps,你必须具有很强的开发背景。而今后不仅仅你要具有很强的开发背景、运维背景等相关的知识,你还要具备 Growth 思想,大数据分析的能力,而 GrowingIO 能够帮助你成为这样的人,欢迎加入 GrowingIO。

进入正题,为什么要做自动伸缩系统,首先集群要承载高峰期的压力,其次也要减少低峰期的服务器成本。DevOps 要干的事情很多,Cost Saving 是其中很重要的一个方面,这是我们做自动伸缩系统的一个目的。

接下来讲一讲 AWS 的 Instnaces 类型,首先最常见的一种是 On-Demand Instances,不管是按小时计费还是分钟计费,说白了起来就计费,基本上国内的云厂商都会支持这种方式。第二种是 Reserved Instances,国内的云厂商大部分也支持这功能。第三种是 Spot Instances,比如说一个机器你出一块钱我出两块钱,价高者得,这是一个竞价的过程。国内实现这个功能的厂商并不多。我们如果想降低服务器的费用,就要很好的利用 Spot Instances。我们就是通过这种方式,节省了很多服务器的费用,当然具体细节还涉及到很多复杂的东西,有可能很小的一个机型,通过不同的竞价反而价钱会比较高。比如说 A 机型本来要小于 B 机型,但也许通过竞价,价钱要比 B 机型价钱高,这里涉及到竞价算法的事情。

讲一讲我们遇到的痛点有哪些。首先,AWS 这么大的云厂商,我们都可能遇到某个机房机器不够的情况,你的自动伸缩系统要有能力 Launch 不同类型的机器、甚至不同机房的机器。第二,有些机器有可能因为某些特殊的原因,他是不能够被关闭的。第三个是网络原因,AWS 在全球市场是做得非常成功,但是在巴西市场做的不是特别好,经常有网络方面的问题。

讲一讲我们做这个系统的几个原则。第一点,我们尽可能的 Launch 竞价实例,这样成本最低。第二,如果其他机型没有了,AWS 机房没这个机型了,我们要有能力 Launch 其他的机型。第三,如果某个机房没机器了,我们可以在另外一个机房 Launch 服务器。第四点,在缩容的过程当中,我们要优先关闭 On-Demand Instances,说白了就是优先关贵的。最后一点,要保证整个集群要有至少那么几台 On Demond 机器来保证正常工作。

接下来讲一下 DevOps 今后的发展方向。如果你只是一个传统的 Ops,其实不太具备市场竞争力,就今天来看,如果你具有很强的开发能力,目前来讲你还能够找到一个比较好的工作,未来你一定要是具有大数据分析的能力,再加上 DevOps,你才能够具备一定的市场竞争力。我之前是在 LinkedIn 工作,做社交的公司都会有做一个 PYMK 的东西,People You May Know,其实就是做人脉的推荐,你可能对这个人感兴趣,他把这个人推荐给你了,或者说国内的很多做酒店的,比如说携程之类的,他也会给你推荐一些酒店。但是 DevOps 有什么场景需要这些大数据分析呢,我们之前做传统运维,你无法预测服务器未来会发生什么。今天每天服务器产生这么多数据,不管是系统级别的还是服务级别的,你怎么样去预测这台服务器明天会不会出现问题呢?能不能基于大数据分析,预测未来哪些服务器可能会出现问题,哪些服务可能会出现问题呢?我们在做面向用户这种产品的时候经常会讲用户的画像是什么,对于 DevOps 来讲,你的服务器相关的服务的画像又是什么?这是一个非常值得思考的问题,也是今后 DevOps 需要做的事情,DevOps 已经转型至 AIOps 了。

有很多数据需要分析,这些数据怎么收集起来的呢,不同公司有不同做法,简单来讲,就是你有 Agent 收集各种渠道来的 Metrics,让后放到一个时序数据库里进行存储,目前国内大公司用的最多的就是 OpenTSDB,我们通过对这些数据进行分析,来对服务器以及服务做一定的画像,预测未来它是否会出现问题。

接下来简单介绍一下 TSDB,这是全球的 TSDB 排行榜,目前来讲排第一的是 InfluxDB,国内用得不是特别多,据我了解目前国内只有七牛和饿了么在用。OpenTSDB 不用说,淘宝、百度、滴滴都在用。TSDB 有几个比较重要的概念,第一个是时间,因为它是一个时序数据库,第二是你的 Metric 是什么,第三是你的 Value 是什么,第四个是你的 Tags 是什么。比如我想统计你的响应时间,Response Time是个Value。但是你想通过不同维度来看这条 Metric,你会有打很多 Tag。你通过 Tag,按照不同维度去聚合,进行一定的数据分析。GrowingIO 这个季度的 OKR 有个指标就是关于系统稳定性的,而首先要做的就是要收集系统稳定性指标,而 GrowingIO 用了一周左右就把整个框架搭建起来了。在 GrowingIO 做事其实是非常快的,这就是创业公司的魅力。

接下来讲我们有了这些数据之后就要开始做分析,简单来讲就是我们通过历史数据,通过不同的 Detection Model,去进行建模,预测未来会是什么状态。异常检测的方式,我们目前还在做,因为现在我们只是把数据收集起来,有相应的图,接下来的工作就是要做 Detection Model 方面的数学建模的事情。

就是以上这些内容,我们现在还在持续招人,欢迎优秀的人加入 GrowingIO,最好有大数据背景,如果大家想加入 GrowingIO 可以给我发邮件或者加我微信。

新闻搜索

覆盖全国各省会城市及海外城市的网速测试
→选择要测试的地区
→选择目标测试点