用于处理需求峰值的EC2

Question

我正在为执行一些cpu密集型工作的移动应用程序编写后端。我们预计该应用在大多数情况下不会有大量使用，但会偶尔出现高需求高峰。我在想，我们应该做的是预留几台24/7服务器来处理低需求流量的稳定状态，然后根据需要添加和删除EC2实例来处理峰值。移动应用程序将首先击中一个简单的负载均衡服务器，在所有可用的处理服务器中执行简单的循环用户分配。负载平衡器将处理新的EC2实例，并根据需要将其恢复。

一些问题：

我没写过这样的事情之前，这听起来是个不错的策略？

处理新的EC2实例的最佳方法是什么？我想我可以提前创建X实例，根据需要设置它们（安装软件等），然后停止每个实例。然后，负载均衡器将根据需要启动和停止实例（例如通过boto）。我认为这应该比创建新实例并通过脚本或其他东西安装所有内容更快更容易。好主意？

我在这里关心的一件事是关闭EC2实例并重新开启的成本。我查看了AWS使用情况报告，并且很难解释它。我可以看到启动停止的实例是一项潜在的昂贵操作。但是，似乎是因为我刚开始一个停止的实例，而不是从头开始一个新的实例，它应该不会太糟糕。这听起来是对的吗？

Answer 1

这是一个非常合理的策略。我以前成功地使用过它。你可能想看Elastic Load Balancing（ELB）与Auto Scaling的组合。从概念上讲，两者应该解决这个确切的问题。

回到2010年左右，ELB在某些类型的HTTP请求中遇到了一些问题，导致我们无法使用它。我明白这些问题已经解决。

由于ELB不是一个选项，我们根据需要手动从EBS快照启动实例，并手动将它们添加到NGinX负载平衡器。这当然可以使用AWS API进行自动化，但是我们的高峰期是可预测的（月末），我们只是要求某人启动新实例并没有考虑自动执行任务。

当一个实例停止时，我相信您支付的唯一费用是支持实例及其数据的EBS存储。除非您的实例有大量关联的数据，否则EBS存储费用应该很小。自从我上次使用AWS以来，事情可能已经发生了变化，但如果发生这种变化，我会感到惊讶。

Answer 2

首先关于成本，实例是从头开始还是从停止状态开始对成本没有影响。您需要为您使用的计算单位的数量计费。

其次，你要做的就是自动缩放。你所做的是建立一个启动配置，指定你要使用的AMI（以及你正在使用的任何用户数据配置，ELB和你将要使用的可用性区域，最小和最大实例数量等等）。您使用该启动配置设置了一个扩展组，然后设置扩展策略以确定要将哪些扩展操作附加到该组，然后将云监控警报附加到每个策略以触发扩展操作。

您没有储存服务器，您连接到ELB或类似的东西。一切都基于创建一个AMI，用作所需服务器的模板。

您应该在下面的链接自动缩放读了起来：

http://aws.amazon.com/autoscaling/