分享 如何科学使用青云的秒级计费

chrisloong · 2014年12月03日 · 最后由 flowerwrong 回复于 2015年03月10日 · 8042 次阅读
本帖已被管理员设置为精华贴

在今年北京的 rubyconf 上,@fsword分享过基于青云 API 的作品larrow-runner,应该是第一个 ruby-client 实现。

下面的内容,之前在青云深圳沙龙分享过,可能社区里没人去,整理成文字版再来分享下。

先看看友好速搭的部署架构: 一共部署了三十多台主机,是很常规的 web 应用三层架构。

系统动态请求统计图: 下午: 晚上:

下午和晚上的请求数,差距很大,午夜以后,基本没请求。 对于大部分应用,应该都有这种忙闲的周期。在闲的时候,保持最小可用就可以,没必要浪费。 既然青云将 IaaS 做成水电一样的资源,那也要学会节约。我们目前节约的方式,就是定时开关机。 动机很单纯: 一台 2 核 4G 的主机,运行时 0.45 元/小时,关机时 0.032 元/小时。

关机的时候,要避免中断当前正在处理的请求,所以要先从 nginx 下手。在 nginx 里面设置定时任务,执行 ruby 脚本,修改 upstream 配置,移除那些要关机的主机 IP,再通过service nginx reload更新配置。reload 是用HUP 信号,不会对正在处理的请求造成影响:

Configuration reload Start the new worker processes with a new configuration Gracefully shutdown the old worker processes

之后等 20 分钟,主要是等要关机的 unicorn,将请求处理完。之后 crontab 执行 ruby 脚本,通过 API 关机,可以直接用larrow-qingcloud 中的 class

conn = Connection.new('your_key', 'your_secret', 'zone_id')
# 调用关机接口
conn.get 'StopInstances',{ 'instances.1' => 'i-xxxx', 'instances.2' => 'i-xxxxx', 'zone' => 'gd1'}

注意,执行调用接口的主机,时间必须同步。

定时开机的话,顺序正好反过来。先通过 API 启动主机,主机中的 unicorn 配置成开机启动。然后等一段时间,等主机和 unicorn 启动完成,就更改 nginx 的 upstream 配置。

通过这种方式,全年可以节约 8% 的开支。有些包年月的 IaaS 服务商,可以打折,同样能节省开支。但是,节省开支,并非我们终极目的。

友好速搭作为服务商,商家做活动,不会通知我们做准备。商家在活动期间,系统负载不够,转化率降低,那就出大事了。

所以,我们正在尝试基于青云的 API,把这个节约体系,做的更智能。目前这个阶段,系统的负载瓶颈,主要是在中间的 Rack App 层,这个层面的主机数量也最多。我们要实现应用主机资源池,设定应用主机数量的上下限,通过算法,分析判断负载趋势,再通过工程,部署或销毁主机。

这个节省得太极品了。。。。不得不进来跪着点赞。。。。

...这个风险和收益不成比例吧?

#2 楼 @kungs 省不是最终目的,主要是探索 auto scale,我们业务场景很需要。 #3 楼 @quakewang :thumbsup: 对,就是这个目的。工程的那部分,现在用青云的 API 容易实现。但算法那部分,只是设定上下限,觉得还不够好,最好能结合趋势判断,在上升还是下降。

为何是定时呢。应该时刻检测当前负载,负载大于一定数值了就开新机器,小于了就砍机器,永远把负载保持在一个中间数值

#5 楼 @msg7086 目标是让流程实时并自动化。不过比较复杂,一步步来吧。

都这样了,省了才 8 个点,感觉亏

#7 楼 @nxbtch 有很多包年月服务商,根据部署主机数量,直接打折,确实简单省事。 但是既然有这种秒级计费,写个脚本就能省,那何尝不用。 这个方案只是实现目标的第一步,最终是要能根据实际负载,实现自动伸缩。

@ChrisLoong 自动伸缩如果可以实现无缝并且完全可以自己判断,那就牛逼。青云提供的这些 api 的确很诱人阿

Auto Scale 应该由青云来做, 不然每个人都需要 重复制造车轮. 感觉这是很基本的 saas 需求.

昨天从工单了解到, 青云会在这个月底上线 Auto-Scaling 功能, 很期待.

#10 楼 @summer_charlie 不同的业务系统,可能需求不一样。如果用 PaaS,那 PaaS 层面可能就是 Auto Scale 了。但是 IaaS 层面,服务商要提供统一的 Auto Scale 方案,不清楚会从哪方面切入,关注看看。

OGX 社区 现在也部署在青云上了。很好玩、很强大的 SDN!而且上面还能用 CoreOS 跑 docker,技术极客们不能错过啊!

#12 楼 @cuterxy 看到 版主,好古老的词汇呀。

#13 楼 @chrisloong 呵呵!你要不要去申请一个玩玩?😄

能告知你们研究了哪些 auto scaling 算法吗

#15 楼 @flowerwrong 主要有两种方式: 1)阈值算法 监测实际的数据,比如带宽、会话数量、平均负载等,设定上限,超过就 scale。 简单,容易实现,但是 scale 会滞后。 2)预测算法 实现比较复杂,但可以提前做 scale。在算法层面,可以做很多优化。在scryer-netflixs-predictive-auto-scaling,介绍了两种:FFT-Based Prediction,linear regression with clustered data points。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号