EC2用于应对需求激增

Question

我正在为做一些CPU密集型工作的移动应用程序编写后端。我们预计该应用在大多数情况下不会大量使用，但偶尔会有大量需求激增。我当时在想我们应该做的是保留几个24/7服务器来处理低需求流量的稳定状态，然后根据需要添加和删除EC2实例以应对峰值。该移动应用程序将首先运行一个简单的负载平衡服务器，该服务器在所有可用的处理服务器之间进行简单的循环用户分配。负载平衡器将处理启动新的EC2实例，并根据需要将其关闭。

一些问题：

我以前从未写过类似的东西，这听起来像是个好策略吗？

处理新EC2实例上下移动的最佳方法是什么？我当时想我可以提前创建X个实例，根据需要进行设置（安装软件等），然后停止每个实例。然后，负载平衡器将根据需要启动和停止实例（例如，通过boto）。我认为这比尝试创建新实例并通过脚本或其他方式安装所有实例要快得多，也容易得多。好主意？

我在这里担心的一件事是关闭EC2实例然后重新打开的成本。我查看了《 AWS使用情况报告》，但难以解释它。我可以看到启动已停止的实例是一项潜在的昂贵操作。但是似乎因为我只是启动一个停止的实例，而不是从头开始配置一个新实例，所以它应该还不错。听起来对吗？

Answer 1

这是一个非常合理的策略。我以前成功使用过。

您可能需要结合使用Auto Scaling来查看Elastic Load Balancing（ELB）。从概念上讲，两者应解决这个确切的问题。

当我在2010年左右进行此操作时，ELB在某些类型的HTTP请求上遇到了一些问题，使我们无法使用它。我了解这些问题已解决。

由于不是ELB选项，因此我们根据需要从EBS快照手动启动了实例，并将它们手动添加到NGinX负载均衡器中。当然可以使用AWS API将其自动化，但是我们的高峰非常可预测（本月末），以至于我们只是委托某人来启动新实例，而无法自动完成任务。

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