应用程序部署容器大小与数量

时间:2016-07-23 20:22:36

标签: amazon-web-services meteor server containers galaxy

我正在学习如何在galaxy上部署流星应用程序,我对所有这些容器内容感到困惑。

我试图了解何时通过增加容器大小而不是添加更多容器来扩展应用程序会更好。

如果我有轻量级的聊天室网站,例如。如果我可以添加更多小容器,为什么我需要升级容器大小。到底是不是处理能力的总和才重要?

2 x 0.5 containers = 1 x 1 container

任何一种方式的成本都是一样的。

此外,如果用户在一个容器中使用应用程序时修改数据库,那么在其他容器上运行的应用程序的其他实例是否需要一段时间才能注意到更改?如果不同容器上的用户在一起聊天,那将是一个问题吗?你会如何避免它?

我能理解这一点的唯一方法是: 缺乏CPU和RAM,或者处理并行请求的能力都会产生扩展需求。 如果应用程序收到太多流量,您将获得更多容器。 如果应用程序使用过多的CPU和RAM,您将获得更大的容器。

但是应用程序如何变得太大而无法容纳在一个容器中?应用程序使用的CPU和RAM不会与使用该应用程序实例的用户数量相关。难道你不能通过添加更多容器并分散用户并以这种方式减少CPU和RAM使用来解决问题。

为什么你需要获得更多容器来处理更多请求。更大的容器不会处理更多请求吗?

1 个答案:

答案 0 :(得分:2)

你问的问题太宽泛了,无法回答。在您的情况下,如果有效实施,增加容器大小(或垂直缩放)和添加更多容器(或水平缩放)的策略都将起作用。

但更喜欢水平缩放是最好的选择。当您启动一个容器集群时,它们会在AWS Elastic Loadbalancer后面运行,如果您启用了粘性会话,聊天室就不会出现任何问题。

阅读本文

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html

这也很安静。

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch_alarm_autoscaling.html

https://aws.amazon.com/blogs/compute/powering-your-amazon-ecs-clusters-with-spot-fleet/

然后是数据库的问题,我假设您将为您的应用程序使用父数据库,因此所有容器将从同一个数据库读取,因此不必担心从一个容器应用的更改并看到从其他容器应用的更改如果适当的数据库优化到位,则不存在任何问题。