亚马逊AWS官方博客
FreeWheel 云环境治理实践 – 计算实例选型
前言
随着 Freewheel 大量业务陆续迁移到云计算中,团队依托于云计算的可靠性和灵活性,摆脱了以往传统机房的限制,从而更加从容高效地专注于服务优化。云计算平台具备弹性化和可扩展化等等特性,理论上较传统的方式更具备成本效益,但如果没有合理的使用资源,很容易造成预算超支。因此成本管理对于云计算用户们都会是一个重点领域。
本文将分享 Freewheel 如何通过计算实例选型来控制与优化相关费用。
背景
目前 Amazon EC2(之后简称为 EC2)的费用占我们云计算消费的很大一部分,所以对 EC2 的成本优化很容易影响整体账单的走势。
我们针对 EC2 费用的优化,主要分为两部分:
- 短期优化
- 通过选择性价比更高的机型替换当前机型,简单直接的降低成本。
- 长期优化
- 提升业务服务的性能,从而提升单位资源的处理能力。
- 构建弹性化服务架构,如动态容量控制,采纳 spot 实例等。
- X86_64 转型 ARM64 架构,采用性价比更高的平台机型。
本文主要关注第一种短期优化,即直接通过机型变更,以较小的侵入性快速地实现成本降低。
需求分析
如上文所述,更换合理的计算实例机型,通过单机性价比层面的提升,从而直接的降低成本,这样对于业务团队有很小的侵入性,不需要投入过多的技术精力和较长周期,即可获得立竿见影的效果。
我们做选型的思路大致如下:
- 选择实例类型,需要参考业务的特性,比如计算优化型、内存优化、存储优化、网络优化等。
- 评估单机硬件容量需求,如 vCPUs、内存、网络、存储等指标。
- 选择性价比较高的机型,在过滤出的可用机型中对比性价比。
- 模拟业务系统压测,若压测结果符合预期,即投产该机型。
但实际实施起来还是有一些困难,截止当前,AWS 已经提供超过 700 种实例类型,并且在全球不同地区的价格与供给策略也略有区别。并且我们可以看到的也只有官方提供的硬件信息,仅凭纸面信息对比,外加长时间的生产环境迭代验证,不是我们需要的快速精准方案。
如果我们能量化出每种机型的性能,进而量化出性价比的指标,通过这些数据指标,就可以清晰的帮助我们做一些选型的决策。下面我们来一起看下如何构建一套全局性指标,并利用所得的数据。
构建统一的衡量指标
关于通用的衡量指标,我们可以分为两类:
- 实例基础的硬件指标:节选一些 AWS 官方提供的标准数据。
- 实例压测的真实指标:通过三方工具,针对不同规格实例的压测数据。
经过一些调研和验证,我们关注的指标具体内容如下表:
指标类型 | 指标数据 | 压测工具 | |
AWS | CPU | vCPUs | AWS 官方提供 |
Network | Network Baseline Performance | ||
EBS | EBS Baseline Bandwidth | ||
EBS Baseline IOPS | |||
EBS Baseline Throughput | |||
System | Overview | System Index Score | unixbench |
CPU | CPU Events Per Second | sysbench | |
CPU P95 Latency | |||
Memory | Memory Operations Per Second | ||
Memory Data transferred per second | |||
Memory P95 Latency (ms) | |||
Memory Copy Bandwidth | stream | ||
Memory Scale Bandwidth | |||
Memory Add Bandwidth | |||
Memory Triad Bandwidth | |||
Storage | Storage Random Write IOPS | fio | |
Storage Random Write IO latency | |||
Storage Random Write Bandwidth | |||
Storage Random Read IOPS | |||
Storage Random Read IO Latency | |||
Storage Random Read Bandwidth | |||
Storage Sequential Write IOPS | |||
Storage Sequential Write IO Latency | |||
Storage Sequential Write IO Bandwidth | |||
Storage Sequential Read IOPS | |||
Storage Sequential Read IO Latency | |||
Storage Sequential Read IO Bandwidth |
接下来就是压测过程,尽可能避免环境变量的影响,尽量发挥机器全部性能,我们的压测方案如下:
- OS 采用公司生产环境底层的 GoldenAMI,在 Amazon Linux 2 的基础上仅做了一些安全加固。
- 单机压测 5 轮,去掉最高与最低值,取平均值。
- 对有异议的数据,人工进行复测。
最后通过不同维度指标的组合,再配合上实例单价,我们可以计算出各种性价比,比如 System Index Score / 实例地域单价,或内存、带宽、磁盘等指标 / 实例地域单价等。
构建推荐机型方案
我们看下 AWS 实例的命名规则,如下图:
命名规则中包含了很多说明信息,我们可以按照以下原则构建推荐方案:
- 同类型实例,尽可能选择最新一代的机型,新机型的性价比较老机型会有一定的提升。
- 跨类型实例,按需选择性价比高的机型,可以参考日常监控来制定替换方案。
- 跨 CPU 架构实例,选择性价比高的 ARM64 机型替换 x86_64 机型,这种推荐需要考虑业务本身是否支持跨平台迁移。
构建自动化系统
定义出了统一衡量指标,接下来可以压测实例了。我们压测的目标是正在使用的和即将使用的以及推荐的实力类型。同时由于 AWS 的实例类型确实太丰富了,而且更新频率也很高,所以我们把这些重复工作做成了自动化方案。
自动化大致分为三部分:
- 客户端:负责自动启动压测和上报数据。
- 后端:调度实例实施压测,接收并计算数据指标。
- 前端:多维度的展现数据。
其中 Apptio 是一个分析 AWS Cost and Usage Report (简称 CUR) 数据的三方服务,我们系统从中获取 Organization 内的实例用量数据,这可以帮助我们找出用量较大的机型,从而最大化节省费用。
通过自动化系统,我们可以定期获得全 Organization 账号下的 EC2 机型用量数据,对于 Organization 内新采用的机型自动完成压测。管理员通过分析这些机型数据构建推荐策略,最后这些信息都会反馈到报表中,帮助用户提供最终决策。
构建横评系统
至此,指标和数据都准备好了,让我们看下分析的结果。
这里我们以 16vCPUs 和 32GB 内存的几个计算优化型实例做对比举例。
基准实例类型:
- c5.4xlarge:x86_64 平台下的 Intel 架构,经典机型。
对比实例类型:
- c6i.4xlarge:x86_64 平台下的 Intel 架构。
- c6a.4xlarge:x86_64 平台下的 AMD 架构。
- c7i.4xlarge:x86_64 平台下的 Intel 架构,当前最新一代。
- c7a.4xlarge:x86_64 平台下的 AMD 架构,当前最新一代。
先看下官方提供的基础信息。
CPU 和内存基础信息
vCPUs、内存容量、CPU 架构一致,CPU 型号和倍频有所差异,具体信息如下图:
网络指标信息
同配置级别的新机型均在网卡吞吐上有 25%的提升,这里建议关注 Baseline Performance 这个基准性能参数,具体信息如下图:
存储指标信息
同配置级别的新机型均在 EBS IO 和吞吐上有一致的提升,具体信息如下图:
实例类型基础信息
可以看出这些机型定位均一致,属于不同 family 的同类型机型。
以下信息为我们系统压测的数据。
压测基准信息
可以看出新机型对经典机型全方位均有提升。其中 System Index Score 代表实例的综合实力,其他指标分别从 IO、带宽等维度展现 CPU、内存、存储(EBS 或实例存储)的单项性能。
注:以下测试结果仅代表 FreeWheel,仅作参考。
性价比信息
根据压测数据,再配比上价格,可以评估计算出该机型的性价比。如下图所示,我们选择通过 System Index Score 数据来关注实例的整体性能,这里也可以通过其他指标来按需衡量不同维度的性价比,比如内存或者磁盘等。
除了性价比,这里还需要关注几个信息。有些机型不是在所有地区都有供应的,在不同地区的价格也会有差异。在同类型的实例中,每种机型也有不同的性能取向。这些信息也需要在计划更换机型的考虑范围内。
压测报告
最后,详细的测试数据会被记录在案,供团队做更多的研究和参考。
构建推荐系统
综合线上实际数据和横评结果,我们可以构建出一套性价比较高的推荐方案,报告节选如下:
结语
在量化出的性能指标帮助下,通过更换合理的机型,让我们快速地优化了不少 EC2 费用。
同时我们也正在着手 ARM64 平台的迁移工作,因为压测发现 AWS Graviton 架构相对 x86_64 平台,有着很高的性价比提升,并且 AWS Graviton3 较 AWS Graviton2 也有不小的提升。
后续我们计划把实际业务指标也融合到这套系统里,追溯分析不同服务模块更换机型后的实际性能表现,从而从业务场景角度提供一个新维度指标。
最后,建议大家实施更换实例类型前需要做好如下准备:
- 确认目标实例类型供应量在对应的可用区或者地区是否有充足的库存可以使用。
- 制定好备用实例类型列表与其优先级,避免因一些不可抗拒的原因造成服务影响。
优化无止境,各厂商与开源社区都在努力为终端用户供各种优质的工具来支持云资源管理,无论利用何种工具,我们都要坚持把确保安全、提高协作效率作为核心目标不断推进技术演变。