AWS 正式发布 Amazon EMR Managed Scaling——这是一项用于自动调整集群大小的新功能,能够以最低成本实现最佳性能。通过 EMR Managed Scaling,您可以为集群指定最低与最高计算限制,并由 Amazon EMR 自动调整集群规模以实现最优性能与资源利用率。EMR Managed Scaling 负责对集群上所运行工作负载的相关核心指标进行连续采样。目前,Amazon EMR 5.30.1 以及更高版本*上的 Apache Spark、Apache Hive 以及基于 YARN 的工作负载皆可支持 EMR Managed Scaling。
用例与收益
在 EMR Managed Scaling 发布之前,用户需要提前预测工作负载模式或根据对应用框架(例如 Apache Spark 或 Apache Hive)的深入理解编写出自定义自动扩展规则。但工作负载预测以及编写自定义规则往往难度极大且容易出错。一旦对集群资源规划不当,配置过低可能破坏 SLA 或者影响业务性能,而配置过高则会导致资源利用率不足以及成本超支。
EMR Managed Scaling 能够自动根据工作负载对集群资源进行规模伸缩,借此实现最佳性能与最低运营成本。大家无需预测工作负载模式或编写自定义逻辑,即可轻松建立起可扩展集群。EMR Managed Scaling 能够持续监控工作负载中的各项关键指标,优化集群大小以实现最优资源利用率。Amazon EMR 可以在峰值时段扩大集群规模,并在闲置期间无损收缩集群规模,从而降低成本、优化集群容量并保障最佳性能。只需数次单击,我们即可设置集群的计算上限,并将其余操作工作交由 Amazon EMR 负责。借助 EMR Managed Scaling,Amazon EMR 还能够以 1 分钟间隔发布高分辨率指标,帮助用户直观查看 Amazon EMR Managed Scaling 对于传入工作负载做出的反应。关于更多详细信息,请参阅了解EMR Managed Scaling指标。
为了举例说明,我们配置了一套 EMR 集群,其中启用 EMR Managed Scaling 并将节点数量区间设置为 1 到 20 个,每节点 16 vCPU。我们每隔 30 分钟向该集群提交多项并行 Spark 作业(取自 TPC-DS 基准测试)。EMR 集群全部使用默认设置,以下 Amazon CloudWatch 仪表板所示为 EMR Managed Scaling 如何根据集群当前负载调整集群大小、在峰值期间执行规模扩展并在闲置时段进行规模收缩。与固定大小的集群相比,在此用例中启用 EMR Managed Scaling 能够将运营成本降低 60%。
EMR Managed Scaling vs. Auto Scaling
Amazon EMR 提供两种集群扩展方式:大家可以使用 Amazon EMR 于 2016 年实现的 Auto Scaling 支持选项,也可以使用此次刚刚推出的 EMR Managed Scaling。如果您运行的应用程序基于 Apache Spark、Apache Hive 或者 YARN,而且希望获得全托管使用体验,我们建议您使用 EMR Managed Scaling。如果需要根据自定义指标为运行在集群中的应用程序定义定制化规则,则适合使用 Auto Scaling。下表总结了这两种方法之间的区别。
EMR Managed Scaling 现可支持 EMR 实例队列
竞价型实例属于 AWS 云中处于闲置状态的Amazon Elastic Compute Cloud (Amazon EC2)容量,相较于常规按需实例,充分利用这部分资源可以为您节约高达 90%的运营成本。当需要回收容量时,Amazon EC2 会提前 2 分钟通知当前竞价实例即将中断。由于 Spark 及其他基于 YARN 的工作负载拥有容错性,因此使用竞价型实例通过 Amazon EMR 运行数据处理工作负载已经成为一类常见用例。关于更多详细信息,请参阅使用Amazon EC2竞价实例配合Amazon EMR运行Apache Spark应用程序的最佳实践。
EMR Managed Scaling 还提供对 Amazon EMR 实例队列的支持。您可以在同一集群之内无缝扩展竞价型实例、按需实例以及由成本节约计划提供的部分实例。
如果竞价容量发生中断或者不再可用,跨多种实例家族与大小的各竞价容量池(包含当前可用区中的各种 EC2 实例类型)将及时跟进,尽可能减少工作负载受到的实际影响。我们将此称为竞价多元化。Amazon EMR 允许用户配置实例队列以自动执行这项策略。如果大家正使用 Amazon EMR 运行大规模数据处理工作负载,且工作负载本身具有容错能力,则建议各位在任务队列中使用竞价实例、在核心队列(即不具备容错性的集群部分,例如 Spark Driver 或 HDFS 节点)中使用按需实例,在充分发挥竞价实例的成本优势的同时保障负载稳定性。
您也可以通过特定方式配置 EMR Managed Scaling(详见后文中的「节点分配策略」部分),以确保 EMR 集群仅扩展竞价实例上的任务节点。在使用实例队列的情况下,我们可以为集群中的各按需实例与竞价实例指定目标容量。每个队列最多可以指定 5 种 EC2 实例类型,以供 Amazon EMR 在处理工作负载时使用。您还可以为不同的可用区选择多个子网。在集群启动时,Amazon EMR 会执行实例置备,直到当前容量符合目标要求。当 Amazon EMR 启动集群时,它会跨各子网、可用区、实例家族与大小进行调配,保证以最低成本配置出中断风险最低的集群容量。使用 EMR Managed Scaling,大家还可以调整实例队列的大小,并为各个实例队列设置按需与竞价容量上限。关于更多详细信息,请参阅配置实例队列。
配置 EMR Managed Scaling
EMR Managed Scaling 的配置过程非常简单。大家只需要启用 EMR Managed Scaling,而后为集群节点设置实例或者 vCPU 数量(在使用实例组的情况下)或者容量单位(在使用实例队列的情况下)的最低与最高限制即可。我们甚至可以在正在运行的集群上,以及在集群配置过程中启用 EMR Managed Scaling。关于更多详细信息,请参阅在Amazon EMR中使用EMR Managed Scaling。
节点分配策略
通过 EMR Managed Scaling,我们可以控制集群规模伸缩中的最低与最高容量限度。用于控制这些限度的参数包括:
MinimumCapacityUnits – 集群大小的下限
MaximumCapacityUnits – 集群大小的上限
MaximumCoreCapacityUnits – 核心节点组的上限
MaximumOnDemandCapacityUnits – 由按需市场提供的配置容量上限
后两项参数可以使大家选择使用按需或竞价市场上的容量扩展实例(MaximumOnDemandCapacityUnits )、或者选择扩展核心节点或任务节点(MaximumCoreCapacityUnits)。您可以使用这些参数在核心节点/任务节点以及按需实例/竞价实例之间分配容量。大家可以把这些参数简单理解成调节滑块,可以随意调上调下。
仅调整核心节点
在本用例中,我们的集群至少包含 5 个节点,最多则可包含 100 个节点。通过将最大核心节点容量设置为最大,并将最大按需节点数量设置为最大,我们就可以保证 EMR Managed Scaling 只调整核心节点且仅使用按需实例。下图所示,为此配置的基本架构。
仅调整任务节点(按需实例)
如果将最大核心节点数设定为最小值,即可仅调整任务实例的节点数。在这种用例中,集群仅调整任务节点,且仅使用按需实例。下图所示,为此配置的基本架构。
仅调整任务节点(竞价实例)
如果我们将按需容量的最大值设置为最低,则可调整集群所使用的竞价节点的最高与最低容量水平。由于最大核心节点数量即为集群的最低规模水平,因此规模伸缩将仅使用任务节点进行。下图所示,为此配置的基本架构。
最佳实践:使用按需实例调整核心节点,使用竞价实例调整任务节点
在这方面,最佳实践建议使用按需实例支持核心节点(因为其中包含 HDFS),并使用竞价实例支持任务节点。由于核心节点中包含 HDFS,因此一旦节点突然丢失,则可能影响作业性能甚至引发数据丢失。下图所示,为集群使用按需实例将核心节点扩展为最大核心容量,并使用竞价实例支持任务节点的基本架构。
总结
本文探讨了 EMR Managed Scaling 功能,它可以自动调整集群大小,借此以最低成本实现最佳性能。关于更多详细信息,请参阅在Amazon EMR中使用EMR Managed Scaling,或查看 EMR Managed Scaling 演示:
*我们在 EMR 6.0 上尚不支持 EMR Managed Scaling,但相关支持将在 6.1+版本中推出。
作者介绍:
Abhishek Sinha
Abhishek Sinha 是一名 Amazon Athena 高级产品经理
Joseph Marques
Joseph Marques 是 Amazon Web Services 负责 EMR 的首席工程师。
Srinivas Addanki
Amazon Web Services 公司软件开发经理。
Vishal Vyas
Amazon Web Services 公司软件开发工程师。
本文转载自亚马逊 AWS 官方博客。
原文链接:
Amazon EMR Managed Scaling 介绍——自动调整集群大小,高效节约运营成本
评论