3

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

一些问题：

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

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

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

4

2 回答 2

5

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

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

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

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

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

于 2012-08-16T18:57:48.597 回答
1

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

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

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

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

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

于 2012-08-16T19:03:24.697 回答