共计 5145 个字符，预计需要花费 13 分钟才能阅读完成。
作者：邢建辉
GrowingIO 运维开发工程师，次要负责平台化，自动化方向的设计与开发。
背景
营收和老本是任何一家企业都须要关注的问题。
当一家互联网公司倒退到肯定规模时，服务器老本会变成一项重大的开销，优化服务器老本也将变成一件提上日程的工作。GrowingIO 次要服务运行在 AWS 上，上面次要针对 GrowingIO 在 AWS 上的一些优化。
老本剖析
1. 概览剖析
在开始老本优化之前，须要先做布局，通过布局来确定实施方案，而不是拍脑袋间接去做，这样可能最初就是花了很大力量，老本升高的成果却不是很显著。
做布局须要通过数据做根据，通过数据分析来确定优化的优先级，例如哪些优化计划会使总体老本降落最快，哪些老本破费的并不合理。下图为 AWS 中的账单中一些概览。
通过 AWS 的账单概览中咱们能够发现费用排名顺次为 EC2，DataTransfer 等，上面针对 EC2，DataTransfer 等咱们须要做账单的详细分析。
2. 细节剖析
（1）数据收集
AWS 的账单中只能做到对总体的一个概览，例如只显示到 c5.xlarge 机型的 Reserved Instances 和 On Demand 的破费，而流量费用也只显示到 out of CNN1 的总数，这些信息只能让咱们总体的看到费用的大抵破费形成，对于宏大的资源，这些信息并不能帮忙咱们精准定位到优化具体资源上。
这里咱们通过 Cost Management Preferences 中将具体账单文件保留到 S3 中，账单中的详细信息 https://docs.aws.amazon.com/c…
（2）数据标签
这里须要阐明的是在做具体账单时最好提前将 AWS 的所有资源打上对立 tag，咱们依据本人的状况打了次要如下四个标签：
打完标签后须要将 AWS 的账单中的 tag 激活，否则生成的具体账单中不会蕴含 tag 信息，具体步骤为在 AWS 账单页面的 cost allocation tags 中将对应 tag active，这样在生成的账单文件中会蕴含 active 的 tag，如 user:App 等相似字段。
（3）数据可视化
GrowingIO 通过 Azkaban 工作自动化对账单数据进行可视化，流程大抵如下。
- 预处理阶段，将账单文件导出，并进行拆分与荡涤后存入 PG 中。
- 统计计算阶段，对于预处理中的原始数据进行按团队，利用等维度进行聚合计算后存入到 PG 中。
- 数据可视化阶段，通过 Grafana 等图形工具对统计后的数据做图形展现。
通过数据可视化基于 App(服务类别)，AWS:Usage(费用类别)，Env(环境)等维度，进行费用的排序，这样能够使咱们比拟直观的找到费用较高的破费。
例如对于利用的维度，发现 Hadoop 的老本是最高的，而 Hadoop 的存储，计算等维度使用量也是排名靠前，那么第一优化的就是 Hadoop 的存储和计算。
上面是局部的展现图表，别离展现了 S3 的各 Bucket，各应用服务，各 ELB 的费用等局部信息(费用列因为比拟敏感，已被暗藏)。
只有账单的后果还不够，咱们还须要依据监控的数据来做理论应用状况的计算，例如能够导出一段时间内的 CPU，内存，磁盘的平均值，95 分位，方差等数值，并将账单和监控数据进行聚合来获取资源的实在应用状况，例如 Hadoop 的计算，内存使用率都比拟高，毛峰个别呈现在整点计算，Kafka，Hadoop，API 的磁盘使用量和吞吐量较大，然而 IOPS 并不高，API 的流量较低等状况。
通过这些数据，咱们能够开始有针对性的做老本优化。
针对性优化
1. EC2 计算实例优化
（1）EC2 免费模式
在开始 EC2 的优化前咱们须要相熟一下 AWS EC2 的一些免费模式。
-
AWS 对于实例免费分为 Reserved Instance(RI) 和 On Demand(OD) 两种形式，其中 RI 为用户向 AWS 承诺应用某一机型一段的工夫，同时 AWS 会给出相应的折扣，个别状况下 RI 相比 OD 都会节俭 60% 多的费用，所以对于稳固且运行工夫较长的业务肯定要抉择 RI。
-
不同代的机型免费不一样，例如 RI 中 m5.xlarge 的 ￥516.11/ 月与 m4.xlarge 的 ￥764.12/ 月比照节俭了大概 32.5%，所以要关注不同代机型的价格，根本都是最新一代的比上一代的便宜，降级过程中须要留神 kernel 版本较低的须要先降级 kernel 再替换机型，否则更换机型会失败。
-
t3 系列机型的计费应用积分形式，如 CPU 闲暇时积分，忙时耗费积分，总的应用不到肯定分数的状况则不额外收费，对于业务有峰值，但平时应用较低的举荐应用 t3 系列，t3 计费具体模式为 https://aws.amazon.com/cn/abo…
- 对于机型的抉择肯定要依据服务的个性来抉择，不同机型的实例价格差距比拟大，上面列了一些机型的价格比照和应用场景，机型中的 a 代表 AMD。
（2）EC2 实例费用的可优化检测
针对 AWS 中 RI 和 OD 的个性，并且新一代相比老一代的机型费用升高的状况，咱们做了如下的性能。
-
依据 RI 的实例类型和数量比照理论应用的实例类型和数量计算得出以后须要预留的实例类型。
-
依据 RI 的过期工夫计算出将来一段时间陆续到期的 RI 机型。
- 通过机型的价格比照 (如 m3，m5 和 t3) 和监控中的资源应用状况计算，得出实例可应用的机型，并且给出对应的费用状况。
举个例子，主动举荐计算出以后 kafka01 节点的预留实例还有 7 天工夫将会到期，并且 kafka01 应用的是 m3.xlarge 机型，同时发现 kafka01 CPU 均匀使用率并不高。则发出通知，kafka01 的预留实例 m3.xlarge 7 天后将到期，以后费用 xxx/ 月，应用 m5.xlarge 费用 xxx/ 月，t3.xlarge 费用 xxx/ 月。
（3）Yarn 计算资源的优化
从之前的剖析来看 Hadoop 中 Yarn 的计算成本是最大的一块，针对 Yarn 咱们做了如下的一些事件。
- 合并 Spark 工作，缩小 driver 的数量
Spark On Yarn 分为 client 和 cluster 两种模式，cluster 模式中 driver 会跑在 yarn application master 上，目前咱们在应用的大部分都是 cluster 的模式，因为当初 spark 工作较多，这样会导致同时启动大量的 driver 来进行工作的治理，因为 driver 对于资源的使用率并不高，这样就会导致肯定的资源节约，所以咱们将一些资源较小的工作进行合并进而缩小 driver 的数量。
- 依据理论使用量，适当升高工作申请的资源数量
- 优化数据模型，放慢计算速度，升高资源使用量
- 降级 AWS 机型，升高 EC2 应用老本
通过数据下面机型的比照，咱们决定将 Nodemanager 的机型从 m3 和 m4 切换到 m5，依据计算总体计算成本大略会升高 30%+，在机型变更的过程中要思考 RI 的到期状况，否则花双份钱就得失相当了。
（4）资源应用不充沛的实例优化
GrowingIO 是一家针对企业提供数据服务的公司，所以产品的流量也次要集中在数据采集和计算这块，面向用户这块会有局部服务的压力不是很高，然而同时又要保障服务的高可用而部署至多双节点。
针对这种状况并联合上方针对 AWS 的机型剖析，咱们对这部分服务采纳了 t3 的机型，一方面费用较低，另一方面 t3 机型能够针对短时的业务压力能够具备肯定的计算能力，没有采纳 t3a 的起因是 t3a 相比 t3 的计算能力降落 20% 而价格只便宜了 10%，导致咱们认为 t3a 的性价比并不高。
2. EBS 存储优化
（1）EBS 类型和免费比照
咱们在来看一下 AWS 的 EBS 类型和性能，以下局部援用官网数据。
（2）HDFS 存储优化
后面曾经对 Hadoop 的计算做过了优化，HDFS 的存储也是老本的大头。
上面依据监控和数据端共事提供的数据分析能够得出一些以下论断。
- 磁盘的 IOPS 只有在小时工作运行时比拟高，平时绝对较低。
- 最近 XX 天的数据拜访频率较高。
- 大于 XX 个月的历史数据的拜访频率非常低。
依据以上景象咱们能够发现 HDFS 不同的数据对磁盘的需要并不一样。
能够总结出数据类型分为 Hot，Standard 和 Archive。
剖析完了 HDFS 的存储个性，这时须要引入 HDFS 的 Storage Types 的个性了，链接 https://hadoop.apache.org/doc…
这里 HDFS 的存储类型分为 RAM_DISK，SSD，DISK 和 ARCHIVE。
RAM_DISK 应用基于特定场景，依据理论业务判断是否须要。而对于 SSD，DISK 和 ARCHIVE 则别离对应上方的 Hot，Standard 和 Archive 的不同场景。
这里咱们抉择了 gp2，st1 和 sc1 别离对应 Hot，Standard 和 Archive 的业务场景。
最初依据布局将 HDFS 的磁盘转成不同的磁盘类型。
这里说一下 AWS 比拟弱小的性能，磁盘类型的在线转换，例如 gp2 能够间接转成 st1 类型的同时提供服务，然而在类型转换时有 6 小时的冷却期。
（3）其余方面的一些优化
- 例如 Kafka，API 等程序读写的场景，如果之前应用的是 gp2 磁盘，那么对立替换成 st1 类型的磁盘。
- 在 EBS 的类型比照中咱们发现 Magnetic 是比拟适宜磁盘大小和性能都要求不高的场景，例如程序搁置目录，所以这一波中将这种类型的磁盘对立替换成 Magnetic 类型。
3. 流量优化
（1）流量免费模式
- NAT 网关应用费用 ¥0.427/ 小时，同时数据处理费用为 ¥0.427/GB。
- 数据自 AWS 传出到 Internet 费用为 ￥0.933/GB。
- 数据自 Internet 出入到 AWS 费用为 ￥0.000/GB。
- 应用私有或弹性 IP 的费用 ¥ 0.067/GB。
- 数据跨 Region 费用为 ￥0.067/GB。
（2）HTTP2.0 Header 压缩
在开始具体流量优化之前，咱们先来简略的介绍一下 HTTP2.0 的 Header 压缩技术。
HTTP2.0 针对当初每个网页大量的 HTTP 申请而导致大部分流量都耗费在 HTTP Header 上的状况减少了 Header 压缩，具体能够参考 https://httpwg.org/specs/rfc7…，原理大抵为服务端和客户端同时保护一份固定动态表和一份动静表，通过传输过程中只传输对应 Header 的索引来达到优化流量的目标，并且 HTTP2.0 协定向下兼容。
（3）服务流量的优化
GrowingIO 是国内当先的数据驱动增长解决方案供应商，流量费用也非常十分宏大。
因为 GrowingIO 服务场景的特殊性，以下办法并不齐全适宜所有公司。
首先咱们先剖析一下服务流量的场景和个性。
- 大部分流量为进站申请，出站的申请携带数据量较小。
- 出站的流量大部分为 TCP 和 HTTP 的 Header 数据。
- AWS 的流量只计算出站流量费用，入站的收费。
针对以上的状况，咱们对于进站的流量不须要关怀，注意力次要集中在出站流量上即可。
依据下面介绍的 HTTP2.0 Header 压缩的个性，咱们决定将服务切换到 HTTP2.0，通过肯定测试后，咱们将 AWS ELB 替换成 Application Load Balancer 模式后默认会开启 HTTP2.0，依据前期的察看出站流量也的确降落了有 30%+。
4. S3 能够优化的方面
S3 为 AWS 的对象存储，依据每个公司的业务用法并不一样，这里简略说一下 S3 应用时可能带来额定费用的中央：
- 尽量将 S3 和 EC2 放在同一 Region 中，否则 S3 和 EC2 之间的传输将产生流量费用。
- 如果将 S3 作为动态 web 服务器，并且流量较大，倡议将 S3 作为 CDN 源站，S3 对于互联网的申请流量和申请次数同时免费。
- 除非明确的归档和备份文件，尽量不要抉择 Glacier 类型，在拜访 Glacier 对象时费用十分昂扬。
- 定期清理不再须要的文件。
将来可做的事件
1. 前期还能够针对 API 的 Response Header 进行一些裁剪，将 Header 进行优化，从而进一步升高出站的流量。
2. 应用 Auto Scaling 性能将一些服务进行动静伸缩，从而将资源应用调配更为正当。
3. 将一些服务搬到 Kubernetes 上进行更正当的资源分配。
4. 依据业务团队将账单具体拆分，将账单跟监控数据关联做成自动化，定期生成报告并进行 review 从而推动整个团队的老本意识。
总结
对于老本优化，每个公司具体的优化措施须要针对具体的业务场景来制定方案，以上只是列出了一些 GrowingIO 在老本优化时一些通用的点。老本优化是一个均衡的过程，在老本，性能，稳定性，零碎冗余中互相平衡后的一个后果，并且是一个长期战斗。
对于 GrowingIO
GrowingIO 是国内当先的数据驱动增长解决方案供应商。为产品、经营、市场、数据团队及管理者提供客户数据平台、获客剖析、产品剖析、智能经营等产品和咨询服务，帮忙企业在数据化降级的路上，晋升数据驱动能力，实现更好的增长。
点击「此处」获取 GrowingIO 15 天收费试用！