【问题标题】:Architecture Decision for Amazon EC: Small Instances or Large?Amazon EC 的架构决策:小型实例还是大型实例?
【发布时间】:2010-09-13 10:40:16
【问题描述】:

我正准备在 Amazon 的 EC2 上启动我们公司的网站,并且有一个相当简单的架构问题:我应该为 Web/应用程序层使用一组小型实例,还是使用一组大型实例?

我意识到这是一个相当广泛的问题。因此,添加一些澄清细节:

  • 我们的应用程序是一个面向公众的电子商务系统。除了典型的动态网站之外,不会发生大量计算
  • 我们的应用是用 ASP.NET MVC 编写的
  • 数据库位于单独的服务器上

我希望做出一个考虑到这些非常不同的实例类型的性能和成本的决定。有什么想法吗?

【问题讨论】:

  • 您好 Chessaurus,因为这不是直接与编程相关的,更多的是部署问题,因此在 serverfault.com 上可能更合适。我已投票将问题迁移到...

标签: cloud amazon-ec2


【解决方案1】:

这个问题很难回答,因为问题不应该是“我应该在什么实例类型上构建我的网站?”而是“我应该如何扩展我的网站?”。

EC2 背后的概念是您可以流畅地扩展网站,而无需重新配置您的应用程序。在负载均衡器后面拥有一个由小型实例组成的大型集群将使您拥有更高的可靠性和更均匀的负载,尽管您可以使用较少数量的大型服务器来实现相同的目标(虽然性能很好,但可能不会给您带来很多好处)因项目规模而产生的收益)。

严格来说,前端网络服务器不应该是强大的。我在 Linode 每月通过一个 20 美元/月的盒子推动 500 万次点击(尽管我已经推动了超过 1500 万次点击,完全没有问题)。我可以在我的架构上进行更多投资吗?当然,我可以通过添加更多镜像盒来增加冗余,我可以通过在更多数据中心添加盒子来提高性能,我可以通过添加更多内存和 CPU 来扩大我拥有的盒子。

我的意思是,如果您有大盒子并且没有充分使用它们,那么您就是在浪费资源。如果您有小盒子并打开和关闭它们以适应您的需求,那么您就可以更好地利用您的资源。

至于您指定的架构,您似乎希望在负载平衡器后面获得一些(小型)前端 Web 服务器在线。从小处着手,并在您的站点需要时启动更多。至于您的数据库,我建议使用更大的中档实例。确保您的数据被推送到 EBS 而不是实例存储本身。添加您复制到的辅助从数据库服务器(为了冗余)也可能是值得的。

关键是要非常仔细地监控您的资源。在服务器上花费大量资金似乎很合理,但为未使用的 EC2 实例付费是不明智的。

希望这会有所帮助!

【讨论】:

  • 谢谢——这实际上很有帮助。我确信我不需要大型实例附带的额外 RAM。 EC2 实例的真正通配符是小型实例的网络和磁盘 IO 显然较慢。不过,亚马逊没有任何指标来衡量多少慢了。
  • 我认为额外的延迟是微不足道的。我想这是因为每个物理服务器有更多较小的实例(较大的实例每个物理服务器的实例密度较低),因此必须完成更多的流量和路由。
【解决方案2】:

最好的答案是做一些负载测试,看看什么可以根据你的应用程序给你带来更好的性能/$。

EC2 的优点在于您可以在几个小时内快速设置一个测试环境,然后试一试。

一旦您的应用程序投入生产,根据监控您的实际利用率和使用情况配置文件,根据需要更改实例大小应该不是什么大问题。

【讨论】:

  • 很好的答案。我的 2 美分:从一个小实例开始,如果性能不够,则转移到高 CPU 实例。使用 EBS 启动的实例并为您的实例创建一个 AMI,以在不同的架构上快速克隆和测试。根据我的经验,对于 CPU 繁重的应用程序,大型实例比高 CPU 实例慢 2 倍,但以 2 倍的价格提供 4 倍的 RAM 增加。因此,您可以根据您的应用程序架构来调用它。我们将从单个大型实例迁移到 2 个负载均衡的中型实例,从而提高冗余和吞吐量。
【解决方案3】:

我认为您正在呼唤 EC2 的一大优势...节省您的资金并在小型实例上运行应用程序。如果您发现没有足够的能力,只能故障转移到更大的实例。

【讨论】:

    猜你喜欢
    • 2011-05-31
    • 2012-02-25
    • 2011-05-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多