是否可以拥有默认为0的AWS EC2比例组,并且只有在有工作要做时才包含实例?

Ste*_*hen 7 amazon-ec2 amazon-sqs amazon-web-services autoscaling

我正在尝试设置EC2 Scaling组,该组可根据SQS队列中的项目数进行扩展.

当SQS队列中有项可见时,我需要Scaling组有1个实例可用,当SQS队列为空时(例如,没有可见或不可见的消息),我希望有0个实例.

所需的实例设置为0,min设置为0,max设置为1.

我在SQS队列上设置了cloudwatch警报,以便在可见消息大于零时触发,并在非可见消息小于1时触发警报(即没有更多工作要做).

目前Cloudwatch警报触发器用于创建实例,但随后缩放组会自动杀死实例以满足所需的设置.我期望警报在最小和最大设置内调整所需的实例数,但事实并非如此.

Joh*_*ein 12

是的,你当然可以拥有一个Auto Scaling组:

  • 最小值= 0
  • 最大值= 1
  • 警报:当ApproximateNumberOfMessagesVisible> 0表示1分钟时,添加1个实例

这将导致Auto Scaling在队列中有消息等待时启动实例.它将继续尝试启动更多实例,但Maximum设置会将其限制为1个实例.

没有消息时的扩展有点过分.

首先,实际上很难知道何时进行扩展.如果有消息等待处理,那么ApproximateNumberOfMessagesVisible将大于零.但是,没有消息等待,这并不一定意味着您希望扩展,因为消息可能正在处理("在飞行中"),如下所示ApproximateNumberOfMessagesNotVisible.所以,如果这两个都为零,你只想要缩小.遗憾的是,CloudWatch警报只能引用一个指标而不是两个指标.

其次,当Amazon SQS队列为空时,它不会向Amazon CloudWatch发送指标.这种情况很有意义,因为队列大多是空的,所以它会不断发送零度量.但是,它会导致CloudWatch在队列为空时未收到指标的问题.相反,警报将进入INSUFFICIENT_DATA状态.

因此,您可以创建警报:

  • ApproximateNumberOfMessagesVisible= 0持续15分钟时,删除1个实例,但将操作设置为触发INSUFFICIENT_DATA而不是ALARM

请注意建议的"15分钟"延迟以避免颠簸实例.这是快速连续添加和删除实例的地方,因为消息是定期进入的,但不经常发生.因此,最好在决定放大之前等待一段时间.(毕竟,Amazon EC2实例每小时收费,因此通常不会产生额外费用.)

这留下了在处理消息时实例终止的问题.这可以通过利用Auto Scaling生命周期挂钩来避免,该挂钩在实例即将终止时发送信号,使应用程序有机会延迟终止直到工作完成.然后,只有在消息处理完成后,您的应用程序才会发出信号表明它已准备好终止.

底线

以上大部分取决于:

  • 您的应用程序接收消息的频率
  • 处理邮件需要多长时间
  • 节省的成本

如果您的消息不经常且易于处理,则可能值得连续运行t2.micro实例.以2c /小时,扩展的好处很小.此外,在添加和删除实际支付的实例时总是存在风险*更多**,因为实例按小时收费 - 运行实例30分钟,终止实例,然后启动另一个实例30分钟实际上收取两个小时的费用.

最后,您可以考虑使用AWS Lambda而不是Amazon EC2实例.Lambda非常适合短期代码执行而无需服务器.虽然它不能由SQS队列中的消息触发,但它可以通过您将消息发送到队列的任何进程触发 - 通过直接调用Lambda,或者将消息发送到Amazon SNS主题,该主题位于转身可以打电话给Lambda.

  • 好答案,@ John Rotenstein!既然它支持SQS触发器,可能值得更新有关Lambda的部分。此外,CloudWatch现在支持指标算术,这在第一个建议的解决方案体系结构(用于评估两个指标)中很有用。 (3认同)