技术类初创公司的AWS成本优化 - 计算资源篇

最近翻了下一本讲AWS成本优化的书。书里提到了一个叫KAO的框架（拼音一念真的很牛），觉得虽然抽象但是好歹是个框架，于是想借用下，再结合自己这些年在初创公司的经验，聊聊从成本的角度，我们对AWS的架构应该有哪些思考。文章是关于AWS的，但是类似的思路，应该也可以扩展到阿里云、华为云等其他的云平台上。

1. 简介

2019年的今天，公有云计算早就不是什么让人眼前一亮的黑科技。但是在媒体舆论趋于平静的背后，我们看到的是公有云计算确实成为了我们这个时代各种庞大的商业、政务生态系统的IT基础设施。如果聚焦到技术类初创公司的角度，公有云计算大幅度的减小了初期团队需要花费在基础设备和运维方面的成本，为企业快速的迭代试错提供了可能。对于一部分技术类初创公司，比如电商和o2o行业，以及saas、paas类的产品，这种优势尤其明显。有些云平台对于新账户还会有不同程度的补贴（比如我们的创业公司在AWS的境外和国内平台上就分别获得了平台的资助，初期的一段时间都在0现金使用AWS的各种服务）。

但是我们也应该看到公有云计算的长期运维成本并不低。我创投圈的朋友所在的公司，在公司规模增长，并且度过了云平台补贴期以后，每个月几十万上百万人民币的AWS或者阿里云账单并不少见。对于资源有限同时又要追求极致增长的初创公司，把宝贵的现金从IT运营中节省出来，投入到客户价值的挖掘和最大化，对企业的发展是会有不小帮助的。

说回前面提到的KAO框架 - KAO是知识（Knowledge），架构（Architecture），运营（Operation）的英文首字母缩写。也就是说要想有效的优化AWS的成本，我们需要

熟悉AWS的各种服务，他们各自在性能、维护和成本上的优势和劣势
基于从1)中获得的知识，设计满足业务要求，同时最小化成本的系统架构（从优化理论的角度说，就是基于业务要求的约束，对成本函数求最小值）
通过对AWS环境的监控、分析，对成本进行持续优化

具体的，我们针对三个最主要的服务类别，运用这个框架分别来谈：

计算 - EC2，ECS，Lambda等
存储 - S3，EBS，EFS，snowball等
网络 - Route53，ELB，VPC，Subnet，各种Gateway，等等

另外一些重要的服务比如Kinesis，RDS，DynamoDB，ElasticCache会专门再谈。这一篇总结一下计算资源的优化思路。

2. 计算

AWS的计算服务主要分三类，EC2，容器类（ECS，ECK，和Fargate），Serverless（Lambda）。说到这里不得不分享一下这张著名的图片（出处不详，侵删）

image

AWS的计算服务，对应的正是图里“猴变人”的后三个阶段。

2.1 EC2

据说EC2从region, availability zone, instance type到tenancy option, scheduling, 外挂的elastic inference有超过1百万个option。这里面的细节很多，我尝试抓一下重点

选合适的region: 对于有海外和全球业务的公司，选一个合适的region是很关键的。一般来说，亚太地区的东京、新加坡等region可以提供相对低的操作延时；美国本土的尤其是东海岸的region费用更低；南美的AWS region的费用是最高的。

选合适的instance type和size: 各种instance type的大致使用场景官方文档已经比较详细，概括起来可以见下图。选用的适合一方面根据自己的需求重点，另一方面也应该计算单位CPU和内存的获取成本（如下表）。在同一个type下，一般来说size每增加1档，相对的CPU性能（用AWS的专有单位ECU衡量）和内存的量就会增大一倍，价格也会贵一倍；在同一个type和size下，一般更新的一代instance会有更好的性能并且更低的花费，比如c5.large比起c4.large，CPU和内存分别有12.5%和6.7%的性能提升，但是每小时的费用却降低了15%。所以能升级尽量升级。

摘自《Mastering AWS Cost Optimization》

避免使用商业license的操作系统：EC2 instance是可以选择Redhat或者Windows操作系统的，但是相应的花费都会更高。如果不是基于行业政策、惯例这类商务需求，建议使用AWS Linux, Ubuntu这种免费的操作系统。

对稳定的使用场景购买reserved instance: 这个和手机话费是一个道理，签绑定合同比不签的话费要便宜；同样是签了合同，预存（预付）话费多的更划算。所以如果有一部分稳定核心的计算资源是不会变动的，并且现金流允许，可以考虑购买3年的reserved instance并且pay upfront。这里要注意的是reserved instance是一种权益，有标准和可转两种，可以被转换、拆分用在不同的instance type上，甚至不同的availability zone上。

围绕spot instance设计架构：spot instance随时会有被terminate的可能，但是成本是同配置的on-demand instance的35%到15%，所以如果业务场景允许，完全值得思考如何能尽可能多的使用spot instance，并且做设计上的权衡。比如在一个load balancer背后用一部分reserved instance负担一部分load，其余通过一个动态的spot instance的资源池来补充；再比如内部的ETL和数据分析，也可以设计成使用spot instance来完成的批处理模式……针对spot instance设计的大致思路无非是把状态存储隔离开，尽量使用spot instance处理无状态的部分。另外，spot instance可以被设置成最多6小时不被terminate。这样的instance可以被用于对instance的稳定性需求更高的场景。当然这样的策略的费用会比一般的spot instance更高。

EC2还有一些比较有意思的选项，值得探索和尝试：

非Intel CPU：AWS提供有AMD的ec2 instance，可以根据需要使用节约成本。例如m5a.large（AMD处理器）就比使用Intel CPU的m5.large节省大约10%的使用费用。另外A系列的instance使用arm处理器，可以作为某些开发和生产环境使用。
可外部挂载的elastic graphics和elastic inference：专业的graphics或者深度学习的G和P instances的使用成本都比较高，如果使用场景并不需要一个专门优化的instance，可以考虑使用一般的instance然后挂载外部的显卡。比如深度学习的模型训练完成后的预测场景，是可以使用elastic inference的。
Dedicated host和bare metal：默认情况下，EC2 instances是虚拟主机，用户是不知道也无法控制自己的instance是在哪一台物理主机上的，也无法控制自己和谁在共享一台物理主机。Dedicated host和bare metal提供的是不同于这种共享模式的专有资源，用于用更低的成本使用离线购买的软件，比如Windows操作系统。
超线程设置：有些按CPU授权的软件，可以在EC2 instance上设置关闭超线程以减少license开销。

2.2 ECS, ECK, Fargate

微服务架构的是现在最主流的互联网和SaaS平台的首选的架构。这种架构的种种在这里就不讲了，有兴趣可以去读Sam Newman的著作《Building Microservices》，是一本非常值得读的书。

这部分的费用也相对简单：

ECS是免费的
ECK的每个cluster需要额外费用
Fargate是managed service，不需要手动管理instance。服务按照使用的CPU和内存来收费 - 一般情况下Fargate的费用会高于使用ECS和ECK，但是由于Fargate简化了运维的工作，所以对于初创公司往往是划算的。（毕竟在咱们行业，高素质的人才才是最昂贵的……）

2.3 Lambda

Serverless架构带来的运维方面的简化，对于研发和业务效率的提升是巨大的，这是很多新的初创公司拥抱serverless的初衷。但是serverless架构的实际花费还是需要细细思考和审计的。

Lambda的收费模式看起来比较简单，主要有两个方面

请求数：us-east-1 region上每一百万个请求$0.2
处理时间+系统资源：us-east-1 region上1GB内存上限的Lambda每秒钟$0.00001667

（另外一个对一些微软技术栈的公司很有吸引力的点是，Lambda是可以用C#编写逻辑，运行在.net runtime上的。然而用户确并不需要为因此用到的Windows server支付任何额外的软件费用）

从两个角度看起来Lambda都不贵，然而实际使用的时候，还是有很多相关费用需要注意。首先Lambda本身是个无状态的逻辑单元，既不能直接接受API request，也不能持久化任何的状态。这一特性决定了Lambda往往会和API Gateway和类似DynamoDB、Kinesis这样的数据服务一起使用。在衡量是使用EC2，container还是Lambda的时候，这两部分的连带费用需要一起考虑。另外比较复杂的状态机系统可能还会用到step function作为状态管理服务，也会增加实际的总使用成本。

其次，失败的或者有未被处理的运行时异常的异步和streaming request会被重试，产生额外的费用。所以如果代码质量不高，没有有效的处理各种异常，也会导致计划外的成本产生。

另外Lambda并不适合处理高密度、长时间运行的计算逻辑：第一，Lambda函数的执行时间是有上限的，超过以后就会直接被中止，从而出发重试逻辑；第二，相比于EC2和container，Lambda的成本在处理相对高频的计算逻辑时其实更高。书中有一个t2.micro instance和Lambda对比处理每秒一次的request时产生的费用，结果是 $8.4 vs$ 43.2，ec2 instance完胜。

即使抛开经济从纯技术的角度，Lambda也有一些局限。比如分布式计算：Lambda的模式是让数据流向逻辑，这样当前主流的基于“让逻辑流向数据”的大数据系统，如Spark，Presto等，都很难在Lambda的世界里实现（开源世界有一些有趣的尝试，比如：https://github.com/qubole/spark-on-lambda）。这使得很多的大数据分析场景目前都还无法使用Lambda来完成的。

综上，对于Lambda的使用需要针对研发和业务需求，具体问题具体分析。目前来看，在相对轻量的，使用较少内存，计算量不大的逻辑上使用Lambda是比较合理的选择。

2.4 KAO框架在计算系统上的使用

在有了上述的这些基本知识（Knowledge）以后，公司就需要有经验和技术能力的人来根据这些外部约束来设计或调整系统架构，这就是KAO中A(rchitecture)的部分。这两年所谓的cloud-native，cloud-first架构，就旨在在设计系统之初就以公有云服务的优势、限制和费用模型作为重要的考量，来做出类似于系统的模块化、技术栈等等基础的设计决定。

曾有同事开玩笑道，几十年前，架构师是真的在从零设计系统。可现在，更像在用公有云的服务组装系统。这也许对架构师是一种新的约束，但是对于整个行业无疑是有推动作用的。

最后是O(peration)的部分。这一部分的细节很多，用文字很难写清楚。一方面云服务的成本控制的确可以通过一次次自上而下的推动来达到目的。但是技术公司的增长和变化都是非常迅速的，比起靠组织架构层层传到一线来推动的成本管理，显然一个好的运营框架、流程、乃至文化，才是一个企业在云服务成本管理上成功的关键。我们所谓的优化，应该只是好的运营框架下自然而然的、每天都在发生的事情。遗憾的是对于运营，世界上从来就没有统一的最优解，哪怕仅仅只是针对AWS的费用优化。上文提到的这本书中有一个阶梯形的示意图，提供了一个做云计算成本控制的思路，可以作为参考：