网站的 EC2 架构设计答案

【问题标题】：EC2 Architecture design for Website网站的 EC2 架构设计
【发布时间】：2013-09-11 23:59:09
【问题描述】：

我有一个即将推出的网站。不完全确定交通会变得多繁忙。

我正在使用 Django+Nginx+Gunicorn+Mysql。将支持 SSL/HTTPS。

作为起点，我正在考虑通过 Elastic Load Balancing 平衡两个微型实例。 MySql 数据库将位于其中一个实例上。如果流量变大，我可能会将静态文件移动到 CDN。微实例充当前端服务器，仅负责生成 HTML/JSON 并提供静态文件。静态文件主要是 CSS/js 和几张图片（不多）。我预计数据库将是读取量大而写入量减少。

问题：

假设流量上升到每天 100k 的页面浏览量，那么 2 个微型实例是否足够？我必须将数据库移动到单独的实例吗？什么实例类型比较好？
如果流量每天只有 1k 页面浏览量怎么办？
在一个微实例上运行多少个 gunicorn 进程？
一般来说，什么类型的指标可以帮助我确定我需要什么样的实例以及需要多少个实例？决定我需要哪种架构的方法是什么？

非常感谢！

【问题讨论】：

标签： django amazon-web-services nginx amazon-ec2 amazon-elb

【解决方案1】：

完全取决于网站计划的动态程度。用户是为服务生成内容还是主要是静态的？如果是前者，您将通过将头像、图像等内容放入 S3 并将其放在 Cloudfront 中获得很多收益。与您的静态文件相同...保持服务器无状态将使您轻松扩展。

在每天 100k 的页面浏览量时，您肯定会在微量设备上遇到困难……您真的应该只在开发环境中使用它们，而不是用来处理像为用户服务这样的事情。我至少会在负载均衡器前面使用一个小实例，这听起来可能很奇怪，但是当事情变得繁忙时，您将能够放入另一个实例，而不必弄乱 Route 53 或可能让您的站点出现故障。无状态的东西现在非常重要，因为用户生成的资产可能只能从一个实例而不是另一个实例引用。

在 1k 页面浏览量时，我仍然会使用一个小的用于 Web 服务，另一个用于 MySQL。如果您单独执行此操作，您可以查看 RDS，这很棒，忘记需要升级版本以及维护、备份等内容。

您还可以一键启动只读副本以达到峰值。还可以查看 Amazon CLI 以帮助自动执行这些任务。如果您时间紧张，Cronjobs 会轻松应对，否则 Opsworks、Cloudformation 和 Auto-Scaling 都可以帮助您解决上述问题。

哦，作为一个比较，我的一个运行 Apache、PHP 和 APC 来为我们的用户服务的应用程序服务器开始与大约 80 个并发用户作斗争。在具有小型 RDS 的小型 EC2 实例上运行（在应用程序服务器走下坡路的同时大约占 15%）

【讨论】：

虽然 80 感觉很少，但请记住，平均页面浏览量大约需要 60 秒，这相当于每天 10 万以上的访问者（当然，对于实际使用模式而言，以 24 小时计时并不完全现实） ) 我指的 Web 应用程序非常大，每个打开的连接的回调频繁，动态内容等，所以我想说你将能够处理更多:)

【解决方案2】：

可能不会。微型实例不是为繁重的生产负载而设计的。他们使用可突发的 CPU 配置文件。它们可以在 2 ECU 上运行几分钟，然后它们被锁定在 0.1-0.2 ECU。我倾向于喜欢 c1.medium，但对你来说可能足够小。
也许，只要它们在白天散开，而不是全部在短时间内。
每个内核 1-2 个。 Micro只有1个核心。
每个应用程序都不同。最好的办法是使用 ab (Apache Bench) 等工具运行您自己的基准测试

【讨论】：

【解决方案3】：

遵循 AWS 最佳实践架构图总是一个好的开始。

http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_web_01.pdf

我强烈建议您将所有文件存储在 Amazon S3 上，并在其前面使用 Route 53 DNS（或任何其他 DNS，如果需要）来分发文件，因为稍后如果您决定使用 CloudFront CDN这将很容易改变。而且，仅提及使用 CloudFront 作为 CDN 只会稍微增加您的成本，而不是很大的事情。

不管场景如何，如果我们谈论的是生产，您绝对应该选择单独的实例，至少 1 个用于 Web 的 EC2 和 1 个用于数据库的 EC2/RDS。

如果您是极客并且喜欢深入了解细节，请创建自己的基础架构并随意使用任何自动化工具（puppet、chef）或不使用。或者，如果您只是想赚取利润，或者拥有稀缺的资源来处理所有事情，您应该尝试 Elastic Beanstalk (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html)

无论如何，要创建自己的基础架构或选择弹性 beantalk，请始终执行压力测试以更好地了解您的容量规划需求。选择初始环境后，使用 apache bench、siege 或任何其他您可能喜欢的工具对其施加压力。

希望这会有所帮助。

【讨论】：

我无法告诉你在 ELB 后面运行的是什么。我不知道是一堆设备还是运行某种 HAProxy 的 EC2 机器集群
TL;DR;这是一种架构最佳实践。假设您有一个 Web 应用程序和一个 iOS 应用程序，并且两者都必须运行某种支付网关集成。如果你把它放到 web 层，你将不得不再次开发它才能在 iOS 上运行。另一方面，如果您从您的 Web 应用程序中获取这段代码并将其转换为某种服务，您可以将其部署为应用程序层中的 REST Web 服务，根据需要多次重复使用它，并隔离 Web应用层，耦合更少，可用性更高。

【解决方案4】：

我建议使用小型实例而不是微型实例，因为微型实例通常在重负载时停止响应，然后需要停止启动。将 s3 用于静态文件，这有助于更快地加载并查看云端。

例如，该区域还有助于处理请求，如果您针对任何特定区域，请创建选择该区域的实例。

在新实例中创建数据库并将 ebs 卷附加到该实例。自动化备份脚本以复制数据库文件并存储在 ebs 中以避免任何问题。此处选择的实例可以是 iops，以实现比标准更快的处理。 Aws 服务提供了很大的灵活性，但您需要运行脚本以根据时间扩展和缩减服务器。

Spot 实例可以在将来提供帮助，因为它们价格便宜，以防您扩大规模。

【讨论】：