AWS自动扩展现有实例

Question

这个问题有一个概念和实践部分。

从概念上讲，我想知道使用自动缩放功能是否等同于简单地将计算能力提高一倍于添加实例的数量？

实际上......这是如何运作的？我有一个正在运行的实例，它的数据库位于由多个EBS卷组成的LVM上，与所有网站数据类似。从实例上的负载来看，我需要升级到更强大的实例或引入此自动缩放。它是正在运行的服务器的副本吗？如果是这样，数据库（等）如何保持一致？

我已经阅读了AWS文档，但仍然没有得到图片 - 我可以设置一个自动缩放组，这可能会清除我的疑虑，但我非常谨慎地使用生产服务器执行此操作。

欢迎任何朝着正确方向的推动。

Answer 1

通常，如果您的解决方案也使用数据库，并且解决方案中有多台计算机，则数据库通常不在任何计算机上，而是单独托管，每个工作计算机指向同一个数据库 - 如果您是在AWS平台上，DynamoDB或RDS都是很好的解决方案。

理论上，对于某些应用程序，升级单个机器的大小将提供与添加几个较小机器相同的功能，但增加单个机器的大小，而通常这些最初要做的最简单的事情，不应该被认为是自动缩放并且有其自身的缺点。以下是一些需要考虑的事项：

• 使用多台机器而不是一台大机器可以提供一些容错功能。一台或多台机器可能会停机，如果您的解决方案设计得当，新机器将会启动以替换它们。
• 增加单个机器解决方案的大小意味着您可能付出的代价太高了。如果您将单台机器的大小设置得足以处理峰值工作负载，这意味着在其他时间（可能大部分时间），您需要支付比您需要的更大的机器。如果您正确设置自动扩展解决方案，则会有更多机器响应不断增长的需求而上线，然后在需求减少时终止 - 您只需在需要时支付所需的功率。
• 当您的解决方案以这种方式设计时，您需要将所有工作机器视为ephermal - 可能随时消失，因此您需要以不同方式构建解决方案。除了使用托管数据库（如在DynamoDB或AWS RDS上），您也不应该在自动扩展组中的计算机上存储任何数据，这些数据也不会存在于其他地方。例如，如果您的应用程序的一部分允许用户上传图像，则不会将它们存储在实例上，而是将它们存储在S3中。同样适用于任何其他新数据。

您需要能够在ASG中的任何机器上随时“拔插”，而不会丢失数据。

最终，正确设置的自动缩放解决方案可能会为您提供更好的服务，但毫无疑问，只需“购买更大的机器”就更简单了，您花在运行更大机器上的额外资金可能会被时间抵消并且您不必花费重新构建解决方案以在自动扩展环境中正确运行。您的解决方案的独特要求将最终决定哪种方法更好。