公有云的一个优势就是弹性伸缩, 那么如何衡量一家云计算客户的弹性使用水平呢? 我设计了一个指标: 计算实例次日存活率(compute_instance_2nd_day_survival_ratio). 指标含义是: 计算第 N+1 天的所有运行过的计算实例中, 非当天启动的计算实例的占比(也就是在第 N 天就出现过的计算实例占比是多少). 其中计算实例的含义可以指虚拟机, 也可以指其他计算资源. 这个指标越低, 代表计算资源都是当天启动的, 那么就可以从侧面反映该公司的计算资源都是弹性伸缩的.
指标计算方法
计算方法也非常简单, 拿 AWS 的 EC2 为例, 为了计算 compute_instance_2nd_day_survival_ratio, 大概思路如下:
1. AWS 中所有的 EC2 都有一个全局唯一 ID, 类似 i-13dvwdfw. 每天收集所有运行过的 EC2 实例 ID, 按天存储到一张表中
注意是采集所有运行过的 EC2 instance_id, 启动后关闭也算在内.
2. 通过一个简单的 SQL JOIN 即可实现计算, 类似 SQL 如下:
-- 第 N +1 天的时间SET data_date='2017-07-16';-- 第 N 天的时间SET data_date_base='2017-07-15;
WITH new_ids AS
-- 第 N + 1天的所有 instance_id 去重
( SELECT instance_id
FROM devops.ec2_instance_log
WHERE data_date = $
GROUP BY 1),
-- 第 N 天的所有 instance_id 去重
base_ids AS
( SELECT instance_id
FROM devops.ec2_instance_log
WHERE data_date = $
GROUP BY 1)
-- 计算两天能够 JOIN 上的 instance_id 数量和总共 instance_id 数量
-- 比例数字后续再自行处理
SELECT sum(if(base_ids.instance_id IS NOT NULL, 1, 0)) AS total_old_cnt,
sum(if(new_ids.instance_id IS NOT NULL, 1, 0)) AS survival_old_cnt
FROM base_ids
LEFT OUTER JOIN new_ids ON base_ids.instance_id = new_ids.instance_id
指标背后的思考
既然要最大限度的发挥弹性计算的能力, 背后的诉求是根据负载动态调整计算资源, 最大限度满足计算资源需求, 而在低谷期间释放多余计算资源避免浪费. 那么计算实例的隔日存活率就代表着这部分计算实例从第 N 天一直存活到次日(第 N+1 天), 也就是没有”弹”. 得知这个数值后, 持续追问背后的原因: 为什么没有自动弹?
再抽象一层来说, 其实是理念的变革, 不知道你是否听说过 Pets vs Cattles 这个著名的说法, 大概意思就是之前大家的服务器都是当做宠物(Pets) 来对待的, 细心照顾, 可一旦出现故障, 恢复的成本就会非常高; 而如果起初设计时计算资源就是作为牲口(Cattles)来对待的, 按需取用, 一定会倒逼自己的系统设计容错性大幅度提升, 也避免浪费, 节省成本.
如何更好的实现弹性
基础设施构建
想要让更好的实现弹性, 必须实现 Immutable Infrastructure, 让自己的基础设施是有版本的, 可测试的, 并且是无法变更的; 如果需要变更, 重新构建一个新的版本. 实现的工具也非常多, 个人非常喜欢 Hashcorp 实现的工具 Packer, 支持跨厂商的虚拟机 Image 构建, 非常方便.
弹性伸缩产品支持
弹性伸缩产品的基础架构抽象上来说, 可以分成三个部分:
1. 感知
感知模块负责收集和统计核心弹性驱动指标, 作为后续决策模块的技术数据输入; 例如 AWS 的 ASG 可以通过 CloudWatch 中的 Metric 作为感知模块.
2. 决策
在基于感知模块的数据, 针对预先配置的规则判断当前是否需要触发扩容或者缩容动作.
3. 行动
在接收到决策模块的扩容或者缩容指令后, 进行对应的操作. 例如如果想扩容虚拟机, 行动模块需要调用对应的 EC2 启动 API, 提供 ImageID/AZ/初始化脚本等参数, 请求 EC2 服务确定新的虚拟机节点.
具体每家云厂商实现如何, 就看各家的功力了. 我个人使用比较多的是 AWS 家的 Autoscaling Group(下文简称 ASG), 非常好用.
IaC: Infrastructure as Code 基础设施即代码
所有基础设施代码化, 通过代码定义自己基础设施, 进一步提升自己的基础设施灵活性和容错. 例如如果自己系统里的 ASG 都是通过运维同学点击鼠标构建的, 哪天误删了恢复起来就蛋疼了. 这里实名推荐 Hashicorp 公司的 Terraform.
总结
弹性的确是可以带来计算资源的不必要的浪费, 但是否会最终节省云计算费用就是另外一个话题了, 毕竟成本优化也是个技术活. 不过总体来说, 如果自己公司的业务是典型的白天扛流量, 夜间扛计算的场景, 更敏捷更弹性的基础架构一定会带来成本的节省.
