用于处理需求峰值的 EC2答案

【问题标题】：EC2 for handling demand spikes用于处理需求峰值的 EC2
【发布时间】：2012-08-13 04:23:59
【问题描述】：

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

一些问题：

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

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

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

【问题讨论】：

标签： amazon-ec2 scalability load-balancing

【解决方案1】：

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

您可能希望将Elastic Load Balancing (ELB) 与Auto Scaling 结合使用。从概念上讲，两者应该可以解决这个确切的问题。

当我在 2010 年左右这样做时，ELB 在某些类型的 HTTP 请求方面遇到了一些问题，导致我们无法使用它。我知道这些问题已经解决。

由于 ELB 不是一个选项，我们根据需要从 EBS 快照手动启动实例，并手动将它们添加到 NGinX 负载均衡器。这当然可以使用 AWS API 实现自动化，但我们的峰值是如此可预测（月底），以至于我们只是指派某人启动新实例，而没有抽出时间来自动化该任务。

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

【讨论】：

只是为了添加有关原始帖子的更多信息。当您使用 Auto Scaling 时，您不会停止和启动您将启动和终止的服务器。不同之处在于，您在服务器上的任何数据都不会被保存，并且 EBS 存储没有成本，因为它不存在。如果您连接了根设备以外的 EBS 卷，具体取决于配置，这些卷可能会在实例终止后保留。

【解决方案2】：

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

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

您没有保留连接到 ELB 或类似设备的服务器。一切都基于创建单个 AMI，用作您需要的服务器的模板。

您应该在下面的链接中阅读有关自动缩放的内容：

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

【讨论】：

如果您停止一个实例，您仍然需要为支持该实例的存储付费（我上次检查过）。
@EricJ。是的，您当然必须为存储付费，我只是在谈论 EC2 的使用，其中启动/停止的行为除了相关的使用时间费用外，对其本身没有任何价格影响。