亚马逊云科技Amazon Compute Optimizer如今推出了一项新功能，可以利用多个CPU架构（包括基于x86的实例和基于Amazon Graviton的实例）更轻松地优化EC2实例。Compute Optimizer是一项可选服务基础设施，可为工作负载推荐最佳Amazon资源，通过分析历史利用率指标来降低成本并提高性能。Amazon Graviton处理器由亚马逊云科技使用64位Arm内核定制构建，可为在Amazon EC2中运行的云工作负载提供最佳性价比，与当前基于x86的同类实例相比，性价比最高可提高40%。因此，对Graviton感兴趣的用户一直想找到一种可扩展的方式来了解在Graviton迁移过程中应该优先处理哪些EC2实例。从今天开始，可以使用Compute Optimizer来查找能够以最小的迁移工作量带来最大回报的工作负载。
工作原理
Compute Optimizer通过提供迁移工作量评级，找到以最小的迁移工作量获得最大回报的工作负载。迁移工作量等级从非常低到高不等，反映了从当前实例类型迁移到推荐实例类型可能需要的工作量，具体取决于实例架构的差异以及工作负载是否与推荐的实例类型兼容。
有关运行的工作负载类型的线索有助于估计迁移到Graviton需要多少工作量。对于某些工作负载，转换到Graviton很简单，只需直接更新实例类型和关联的Amazon Machine Images（AMIs），或在各种启动或CloudFormation模板中更新即可。对于其他工作负载，可能需要使用其他软件版本或更改源代码。转换最快、最容易的工作负载是基于Linux的开源应用程序。许多开源项目已经支持Arm64，并进一步支持Graviton。因此，许多客户在开始进行Graviton迁移时，会先检查工作负载是否在与Graviton兼容的应用程序列表中。然后将这些信息与Compute Optimizer预计能够节省的费用相结合，列出Graviton迁移机会清单。
由于Compute Optimizer无法查看实例，只能查看实例属性以获取有关EC2实例上运行的工作负载类型的线索。Compute Optimizer使用的线索基于客户提供的实例属性，例如实例标签、Amazon Marketplace产品名称、AMI名称和CloudFormation模板名称。例如，当一个实例标有“key: applicationType”和“value: hadoop”时，Compute Optimizer将识别该应用程序为Apache Hadoop。因为主要的框架（如Apache Hadoop、Apache Spark和其他许多框架）都在Graviton上运行，所以Compute Optimizer会指出Graviton的迁移工作量很小，并让客户查看文档，了解将Hadoop应用程序迁移到Graviton所需的步骤。
再举一个例子，Compute Optimizer看到有实例正在使用Microsoft Windows SQL Server AMI时，就会推断SQL Server正在运行。由于要将SQL Server工作负载现代化并迁移到Arm需要大量工作，Compute Optimizer将指出Graviton迁移工作量较大。要向Compute Optimizer提供哪个应用程序正在运行的线索，最有效的方法是在每个实例上添加“应用程序类型”标签。如果Compute Optimizer没有足够的线索，则表明它没有足够的信息来指导迁移。
以下是各级迁移工作量的描述：
● 非常低：推荐的实例类型具有与当前实例类型相同的CPU架构。通常，客户可以直接修改实例类型，或者对新的实例类型进行简单的重新部署。所以这只是优化，而不是迁移。
● 比较低：推荐的实例类型的CPU架构与当前实例类型不同，但迁移路径比较简单。例如，将Apache Hadoop或Redis从x86迁移到Graviton就属于这一类，因为Hadoop和Redis都有兼容Graviton的版本。
● 中等：推荐的实例类型的CPU架构与当前实例类型不同，而Compute Optimizer也没有足够的信息来提供迁移指导。
● 高：推荐的实例类型的CPU架构与当前实例类型不同，并且该工作负载在推荐的CPU架构上没有已知的兼容版本。这种情况下，客户可能需要重新编译其应用程序或重新构建其工作负载的平台（例如从SQL Server迁移到MySQL）。
