EC2 服务器，大量的微型实例还是更少的大型实例？

Question

我想知道哪个更好，在 EC2 上托管一个具有许多微型实例的站点，或者更少的大型实例，例如 m1.large。所有这些都将作为负载平衡器坐在一个或几个更大的实例后面。我就说一下我的理解，有错的可以补充或者指正

选择微实例的主要原因是成本。一个微型实例平均以 0.02 美元/小时的价格提供大约 0.35 个 ECU，而一个小型实例以 0.085 美元的价格提供 1 个 ECU。如果您计算 $/ECU/小时，微型实例的计算结果为 0.057 美元/ECU/小时，而对于小型实例，则为 0.085 美元/ECU/小时。所以对于同样的平均计算能力，选择 100 个微实例会比 35 个小实例便宜。

微型实例的主要问题是性能波动更大，但我不确定当您有很多实例时这是否会减少问题。

那么有没有人有过这样的设置的经验，并看到了优点和缺点？请让我知道，因为我正在尝试选择哪种方式，谢谢！

PS：一篇关于该主题的文章，http://huanliu.wordpress.com/2010/09/10/amazon-ec2-micro-instances-deeper-dive/

Answer 1

小心微型实例，它们可能会咬你。我们在微实例上都有测试环境。由于它们只是功能测试环境，因此可以顺利运行。然而，我们碰巧更新了一些应用程序（嗯，Jetty 7.5.3），这些应用程序已知会导致 CPU 使用率升高。这使得这些实例变得无用，因为亚马逊将可用 CPU 限制为 2%。

此外，微型实例由 EBS 支持。对于像 Cassandra or the likes 所需的高 IO 操作，EBS 不建议使用（超过实例存储）。

如果您想省钱并且您的软件是architected to handle interruptions，您可以选择现场实例。他们通常 cost less than on-demand ones.

如果所有这些对你来说都不是问题，我会说，微实例是要走的路！ :)

• Basics questions about micro instances performance
• CPU pattern for micro
• Stolen CPU on micro

Answer 2

我想说：取决于您的应用将拥有什么样的架构以及它需要有多可靠：

• AWS 负载均衡器不提供即时（也许实时是一个更好的词？） 与故障转移概念不同的自动缩放。它适用于 不时进行健康检查，并且延迟很小，因为它 通过 http 请求完成（如果您选择 https，则开销更大）。
• 如果您根据体系结构选择更多实例，则会出现更多故障点。为避免这种情况，您的应用需要在实例之间保持异步。
• 如果您选择更多，则必须对您的应用程序进行更多基准测试和测试 实例，以确保这些突发事件不会对您的应用产生太大影响。

这是我的观点，这将是有经验的人之间非常愉快的讨论。