本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

基于 Amazon 的扩展策略 SQS

本节介绍如何根据亚马逊简单队列服务 (AmazonSQS) 队列中系统负载的变化来扩展 Auto Scaling 组。要详细了解如何使用亚马逊SQS，请参阅亚马逊简单队列服务开发者指南。

在某些情况下，您可能会考虑扩展以响应 Amazon SQS 队列中的活动。例如，假设您有 Web 应用程序，让用户上传图像并联机使用。在此场景中，每个图像需要先调整大小并编码，然后才能发布。该应用程序在 Auto Scaling 组中的EC2实例上运行，并且配置为处理您的典型上传速率。不正常的实例将终止并进行替换，以始终保持当前的实例等级。该应用程序将图像的原始位图数据放入SQS队列中进行处理。它处理这些图像，然后将处理的图像发布到某个位置以供用户查看。如果上传的图像数不随时间波动，则适用于此场景的架构可以良好运作。但是，如果上传数量随着时间波动，您可以考虑使用动态扩展来缩放 Auto Scaling 组的容量。

将目标跟踪与合适的指标结合使用

如果您使用基于自定义 Amazon SQS 队列指标的目标跟踪扩展策略，则动态扩展可以更有效地适应应用程序的需求曲线。有关为目标跟踪选择指标的更多信息，请参阅 选择指标。

使用诸如目标跟踪之类的 A CloudWatch mazon SQS 指标的问题在ApproximateNumberOfMessagesVisible于，队列中的消息数量可能不会与处理队列消息的 Auto Scaling 组的大小成比例变化。这是因为SQS队列中的消息数量并不能仅定义所需的实例数量。Auto Scaling 组中的实例数可能由多种因素决定，包括处理消息所需的时间以及可接受的延迟长度（队列延迟）。

该解决方案使用要维护的每个实例的积压 指标以及每个实例的可接受积压 的目标值。您可以按以下所示计算这些数字：

例如，假设您当前有一个包含 10 个实例的自动扩缩组，并且队列中的可见消息数量（ApproximateNumberOfMessages）是 1500。如果每条消息的平均处理时间为 0.1 秒，最长可接受延迟为 10 秒，则每个实例的可接受积压为 10/0.1，即 100 条消息。这意味着您的目标跟踪策略的目标值为 100。当每个实例的积压达到目标值时，将发生横向扩展事件。由于每个实例已经积压了 150 条消息（10 个实例 1500 条消息），该组会横向扩展并增加了 5 个实例以维持与目标值的比例。

以下过程演示如何发布自定义指标和创建目标跟踪扩展策略，以根据这些计算值来配置您的 Auto Scaling 组进行扩展。

此配置有三个主要部分：

下图演示了此配置的架构。

限制和先决条件

要使用此配置，您需要注意以下限制：

以下各节将指导您使用来完成需要执行的任务。 AWS CLI 例如，要获取反映队列当前使用情况的指标数据，您可以使用SQSget-queue-attributes命令。确保已CLI安装并配置。

在开始之前，您必须有一个可供使用的 Amazon SQS 队列。以下各节假设您已经有一个队列（标准队列或FIFO）、一个 Auto Scaling 组以及运行使用该队列的应用程序的EC2实例。有关亚马逊的更多信息SQS，请参阅《亚马逊简单队列服务开发者指南》。

Amazon SQS 和实例缩减保护

在实例终止时尚未处理的消息将返回到SQS队列中，在那里它们可以由另一个仍在运行的实例进行处理。对于执行长时间运行任务的应用程序，您可以选择使用实例扩展保护来控制 Auto Scaling 组扩展时终止哪些队列工作程序。

以下伪代码显示了保护长时间运行、队列驱动的工件进程免受缩放终止的一种方法。

while (true)
{
  SetInstanceProtection(False);
  Work = GetNextWorkUnit();
  SetInstanceProtection(True);
  ProcessWorkUnit(Work);
  SetInstanceProtection(False);
}

有关更多信息，请参阅 设计您的应用程序以优雅地处理实例终止。