有人可以帮我找出有效的自动缩放配置吗？

Question

这是我第一次发布网络应用程序。我打算将 Django 与 Nginx 和其他几个已通过管道传输的脚本一起使用。我想知道我可以使用哪种自动缩放策略。

现在，我正在玩免费的 EC2 微型实例。效果很好。

我不确定我是否能负担得起专用的 RDS。我正在寻找最具成本效益的配置。我正在考虑使用负载均衡器设置的微型实例进行自动缩放，但我还没有弄清楚如何在所有实例中同步数据库。

我也在考虑其他替代方案，如 App Engine 和 Heroku，但我认为它不会给我像 VM 这样的自由。是否有 PaaS 可以让普通 VM 自动扩展而无需担心？

此外，它有某种图表可以大致告诉我 Micro、Small 等实例每个可以承受多少流量。

有人可以透露一些信息吗？

Answer 1

扩展应用程序是您必须设计应用程序才能做到的事情 - 无论平台如何。

一些考虑因素包括：

• 使所有节点都可以使用文件（例如上传、源代码更改等）
• 在所有节点之间共享会话信息
• 跨多个节点复制数据库
• 确定节点的健康状况以及何时启动新节点

我建议最好的方法是首先将您的数据库卸载到另一个实例。如果您的数据库和应用程序在不同的实例上运行，您可以独立扩展每个实例，并且可以更轻松地管理问题。（参见这篇文章- 有点旧，但同样有效）。

其次，你想扩大和缩小。使用 EC2，您可以从较大的实例类型中获得更好的性能——就性能而言，一个小实例优于 3 个微实例。我的建议是横向扩展到两个节点（用于故障转移），然后在继续横向扩展（在更持久的基础上）之前开始为更大的实例类型切换节点。不过，无论如何，请保持自动缩放功能，以便您的应用程序可以随时处理额外的负载。

单独扩展您的数据库 - 通常您的应用程序需要比数据库更多的节点（您的数据库可能会从更高的内存实例中受益）。另请记住，RDS 不会为您进行缩放。

亚马逊不提供“流量”图表 - 因为这完全取决于您的应用程序（处理器密集型的高度动态应用程序可以比在相同硬件上提供静态页面的应用程序提供的请求少得多）。然而，它在这里提供了一个有点“主观”的比较。值得强调的一点是“I/O 性能”。该描述符包括网络带宽和磁盘 i/o。较小的实例更容易受到性能变化的影响（尤其是可用带宽）。由于 EBS 卷需要网络带宽，这也会影响它们的性能。

至于微实例 - 只要您的应用程序值得，就升级到一个小实例。您会发现，每当您在微型上“爆破”cpu 时，性能都会随之受到影响（由顶部的“窃取”值表示）。其他实例（您不拥有的）可以在微型实例上使用大量 CPU。

还值得一提的是，您可以将自动缩放组的大小设置为“1”，这样您就可以在实例不可用时重新启动它。（不过，出现的问题是将当前数据取回该新实例，因为它是从快照启动的）。

如果您可以使用 MySQL 集群（它使用不同的存储引擎 - ndbcluster）或带有分片的 NoSQL 解决方案，那么与在 MySQL 中使用传统的主从复制相比，您将可以更轻松地自动扩展数据库。（据报道还有另一种解决方案取得了一些成功，但此时我可能不建议使用分布式文件系统，特别是 GlusterFS，来存储您的数据库——文件系统管理文件锁定和分发，并且每个实例访问需要的数据库 - 这会在您添加更多实例时遇到问题，但可能会在 2 节点数据库集群中取得一些成功）。

因此，一个实际的行动方案可能是：

1. 从 1 个微型实例开始，其中包含您的数据库和应用程序
   • 将您的数据库分离到一个实例，将您的应用程序分离到第二个实例
2. 在您的应用程序实例上设置自动缩放。
3. 添加第二个应用程序节点
4. 添加第二个数据库节点并配置节点之间的复制（如果您选择使用 MySQL 集群或 NoSQL 解决方案，您也应该能够设置自动缩放）。
5. 根据需要一次将一个实例升级到更大的实例大小

（您应该会发现，对于大多数站点，2 个较大的实例足以运行您的数据库，特别是如果您正确实施缓存，但根据需要添加额外的从属设备应该不会太麻烦）。

上述行动方案很好地解决了扩展问题，但在第 4 步之前它确实存在单点故障（即，如果您的数据库节点出现故障，您的应用程序就会出现故障）。一个更困难的设置，但一个更有弹性的设置，会看到你的应用程序和数据库都在同一个节点上，然后使用 MySQL 复制（和 MySQL 代理来处理来自负载均衡器的请求）设置该节点的两个副本 - 你需要自己管理故障转移（使用 Heartbeat/Pacemaker 之类的东西），然后直接转到 4 个节点（2 个数据库，2 个应用程序）。