亚马逊 EMR 在 EC2 上的成本优化：全球金融服务提供商如何将成本降低 30%

关键要点 在这篇文章中，我们讨论了一家全球金融服务提供商如何将他们的 Apache Hadoop 集群迁移到 AWS，并使用最佳实践将其 Amazon EMR、Amazon EC2 和 Amazon S3 的成本降低了 30%。通过与 DevOps团队的紧密合作，借助数据驱动的方法以及专注于成本优化的黑客马拉松，使其取得了显著成效。

在此文中，我们重点介绍了帮助一家全球金融服务提供商将其 Apache Hadoop 集群迁移到 AWS 时获得的关键经验，以及帮助其将 、 (Amazon EC2) 和 (Amazon S3) 成本降低超过 30% 的最佳实践。

背景

在 2022 年初，该全球金融服务提供商的一个业务部门开始将其客户解决方案迁移到 AWS。这包括 Web 应用程序、Apache HBase数据存储、Apache Solr 搜索集群和 Apache Hadoop 集群，涉及超过 150 台服务器节点和 1 PB的数据。这些本地集群支持实时数据摄取和批处理。

由于数据中心关闭的紧迫迁移时间表，他们实施了将 Apache Hadoop 集群提升和迁移至 Amazon EMR on EC2 的策略，详细信息请参见 。

Amazon EMR on EC2 为业务部门提供了灵活性，使他们能够在几乎不更改的情况下运行应用程序，使用已安装必要 Spark、Hive 和 HBase软件及版本的托管 Hadoop 集群。由于这些集群都是托管的，他们能够拆分大型本地集群，根据每个用例在 AWS上部署专用的瞬态和持久集群，而无需增加运营开销。

挑战

尽管提升和迁移策略使业务部门以较低风险完成迁移，并使其工程团队能够专注于产品开发，但这也导致了持续增加的 AWS 成本。

业务部门为不同用例部署了瞬态和持久集群。多个应用组件依赖于 Spark Streaming 进行实时分析，这些组件部署在持久集群上。他们还在持久集群上部署了 HBase 环境。

在初始部署后，他们发现若干配置问题，导致性能不理想和成本增加。尽管使用了 Amazon EMR 管理的扩缩机制，但由于设置了最低 40 个 ，导致资源浪费。核心节点的自动扩缩配置也存在错误，导致缩放事件关闭了包含 shuffle 数据的核心节点。业务部门还实施了 Amazon EMR 的 ，但由于 EMR on EC2 集群在运行 Spark应用程序时数据丢失，某些作业的运行时间比计划的长了五倍。在这种情况下，自动终止策略并未将集群标记为空闲，因为仍有作业在运行。

最后，开发（dev）、用户接受测试（UAT）和生产（prod）环境的配置也过度分配，导致其管理扩缩策略的最小容量单位太高，造成更高的成本，如下图所示。

删除)

短期成本优化策略

该业务部门在 4 个月内完成了应用程序、数据库和 Hadoop集群的迁移。他们的首要目标是尽快摆脱数据中心，然后进行成本优化和现代化。尽管他们预计提升和迁移策略将导致更高的前期成本，但实际成本比预期高出 40%，这加快了他们优化的必要性。

他们与共享服务团队和 AWS团队合作，制定了成本优化策略。业务部门首先专注于实施不需要产品开发团队参与或不影响生产力的成本优化最佳实践。他们进行了成本分析，确定最大成本贡献者为运行 Spark 的 EMR on EC2 集群、运行 HBase 的 EMR on EC2 集群、Amazon S3 存储和运行 Solr 的 EC2 实例。

业务部门开始通过自动化在开发环境中强制实施 EMR 集群的自动终止。他们考虑使用 Amazon EMR isIdle 的 指标来构建事件驱动的解决方案，配合 。他们实施了更严格的政策，在较低环境中对集群进行 3小时后关闭，不论是否使用。还更新了 DEV 和 UAT 的管理扩缩策略，将最小集群大小设置为 3 个实例，以便集群按需扩展。最终这导致了开发和 UAT成本减少 60%，如下图所示。

删除)

在初步的生产部署中，他们有一部分 Spark 作业运行在一个旧版的 Amazon EMR 5.(x) 持久集群上。为了优化成本，他们将小规模作业和大型作业在不同持久集群上运行，并配置了支持每个集群作业所需的核心节点的最小数量。将核心节点设置为固定数目，同时仅对任务节点使用管理扩缩是一种推荐的 ，避免了 shuffle 数据丢失的问题。这也改善了缩放时间，因为任务节点不会在 Hadoop 分布式文件系统 (HDFS) 中存储数据。

Solr 集群运行在 EC2 实例上。为了优化此环境，他们进行了性能测试，以确定最适合其工作负载的 EC2 实例。

在 1 PB 数据量的情况下，Amazon S3 每月成本贡献超过 15%。该业务部门启用了 存储类别，以优化历史数据的存储费用，同时将他们的 Amazon S3 每月成本降低了超过 40%，如下图所示。他们还将 (Amazon EBS) 卷从 gp2 迁移到 gp3 卷类型。

删除)

长期成本优化策略

在实现了初步的成本节约后，业务部门与 AWS 团队合作组织了一场财务黑客马拉松 (FinHack) 活动。此次黑客马拉松的目标是通过使用数据驱动的过程进一步降低成本，测试 Spark 作业的成本优化策略。为了准备黑客马拉松，他们确定了一组作业，用于测试不同 Amazon EMR 部署选项（Amazon EC2、）和配置（Spot、AWSGraviton、Amazon EMR 管理扩缩、EC2 实例集群），以找出每个作业的最优化解决方案。以下是某个作业的测试计划示例表。

业务部门在 FinHack 活动前后进行了广泛的 Spot 实例测试。他们最初使用 和 来创建最佳实例集群配置。他们还通过查询 Spot 放置分数使用

API 自动选择运行作业的最佳可用区。

在 FinHack 期间，他们还开发了一个 EMR 作业跟踪脚本和报告，以详细追踪每个作业的成本并衡量持续改进。他们使用 AWS SDK forPython (Boto3) 列出其账户中所有瞬态集群的状态，并报告

和每个作业的实例小时。

在执行测试计划的过程中，他们发现了几个额外的改进领域：

• 其中一个测试作业对 Solr 集群发出 API 调用，这导致了设计瓶颈。为了防止 Spark 作业压垮集群，他们对 executor.cores 和 spark.dynamicAllocation.maxExecutors 属性进行了微调。
• 任务节点的 EBS 卷过大。他们将大小减少至 100 GB，以获得额外的成本节约。
• 他们根据选择的实例类型设置单位/权重，更新了其实例集群配置。
• 在初始迁移过程中，他们设置的 spark.sql.shuffle.partitions 配置过高。该配置是针对其本地集群微调的，但尚未更新以与 EMR 集群保持一致。他们通过将值设置为集群中的 vCore 数量的一到两倍对该配置进行了优化。

在 FinHack 之后，他们为使用 Terraform 部署的持久集群和使用 (AmazonMWAA) 部署的瞬态集群强制实施了成本分配标记策略。他们还使用 和 部署了 。

成果

该业务部门在 3 个月中将每月成本减少了 30%。这使得他们能够继续迁移剩余的本地工作负载。他们每月的 2,000 个作业中大部分现已运行在 EMR瞬态集群上。他们还将 AWS Graviton 的使用提高至每月总使用小时的 40%，在非生产环境中 Spot 的使用增加至 10%。

结论

通过数据驱动的方法，包括成本分析、遵循 AWS 最佳实践、配置优化以及财务黑客马拉松期间的广泛测试，全球金融服务提供商在 3 个月内成功将 AWS成本降低了 30%。关键策略包括执行自动终止政策、优化管理扩缩配置、使用 Spot 实例、采用 AWS Graviton 实例、微调 Spark 和 HBase 配置、实施成本分配标记及开发成本跟踪仪表板。他们与 AWS团队的伙伴关系以及专注于实施短期和长期最佳实践，使他们能够在优化大数据工作负载的同时继续进行云迁移努力。

有关更多成本优化最佳实践，我们建议访问 。

关于作者

Omar Gonzalez 是亚马逊网络服务公司的一名高级解决方案架构师，在加利福尼亚南部拥有超过 20 年的 IT经验。他热衷于帮助客户通过技术推动业务价值。在工作之余，他喜欢远足和与家人共度美好时光。

Navnit Shukla 是一名专注于分析的 AWS专家解决方案架构师，热衷于帮助客户从数据中发掘有价值的洞察。通过发挥他的专业知识，他开发创新解决方案，使企业能够做出明智的数据驱动决策。NavnitShukla 还是书籍 的作者，展示了他在该领域的专业知识。他还运营一个 YouTube 渠道 ，分享关于云技术和分析的见解。请通过 与他联系。