如何缩放1服务器Rails应用程序

Question

我有一个rails应用程序运行在一个VPS上，它使用客运、apache和MySQL。我用以下简单的设置将其移到Amazon：

网络服务器> MySQL

让我说，我预计每天的用户数量会大幅增加，并希望开始使用多个实例在Amazon上扩展这一功能。新手从哪里开始这个旅程？我是否只是从我的产品配置的web服务器创建一个AMI，并让ASG在需要时启动这些？

我知道AWS会根据负载的需要增加使用自动缩放组的实例的数量，但是我是否需要在我的Rails应用程序中构建任何不同的架构，才能在多个接口上大规模运行呢？

Answer 1

水平缩放的问题在于它实际上取决于应用程序。没有什么“加水”的方法可以做到。

但是，在一开始，您可以遵循一些通用的菜谱：

1. 将MySQL服务器解压缩到单独的实例中，该实例能够容纳较高的负载。然后根据需要创建尽可能多的连接到MySQL数据库的工作者(即app)实例。您可以在MySQL服务器满溢请求之前继续这样做，并且无法再跟上负载。
2. 完成步骤1后，可以添加MySQL副本并设置主-从复制。这将给您留下一个MySQL集群，其中一个服务器可以接受写操作，而所有其他服务器都是只读的。设置好后，将应用程序更改为将SELECT的副本发送到只读副本，并将/DELETE/UPDATE的副本插入到可写的主服务器。这种方法是基于这样一个事实，即大多数应用程序进行读取的频率要比写入高得多。这对你来说是不可能的，但如果是的话，它会让你保持很长的漂浮时间。就在您饱和MySQL主服务器的写入性能之前。
3. 一旦从第2步压缩了所有内容，就可以继续并分割数据。现在，这越来越依赖于您的应用程序。但我会提供一个盲目的例子，以传达这一想法。比方说，您有一个以用户为中心的应用程序(例如，一个私人相册，没有共享功能)，而且每个用户都有一个名称。在这种情况下，您可以创建两个完全独立的集群，其中第一个集群将为名为and的用户服务，第二个集群将服务于具有N的集群。它本质上使负载减少了两倍，但使整个体系结构变得复杂。

虽然是通用的，但这些菜谱可以帮助您构建一个相当可靠的应用程序，每天可以为数百万用户提供服务，然后才能提出更多奇异的缩放方法。

希望这能有所帮助！