AWS EC2 上的多站点

Question

我正在开发一款旨在完全运行 Amazon Web Services 的多站点应用。由于其特性，它将出现显著的流量高峰，随后是长时间的低流量，因此必须具备扩展 EC2 实例的能力。

到目前为止我想到的结构是：

                                _____________________
                                Elastic Load Balancer
                                _____________________
                                          |
                                          V
                                _____________________
                          []   []   []   []   []   []   []
                                   Autoscaling EC2
                                With Dynamic Virtual
                                        Hosts
                                Global Business Logic
                                _____________________
                                /         |          \
                               /          |           \
                       Amazon RDS         S3        Site Views?
                      One Per Site       for      
                                     static files

现在我有两个问题：

1. 我应该将特定于站点的“视图”或“主题”文件保存在哪里？S3 的速度是否足以处理这些文件？或者每次我需要调整特定站点的主题时，我是否真的应该创建新的 AMI？
2. 配置文件。由于每个站点都连接到单独的数据库，因此每个站点都需要自己的配置文件。同样，我是否应该将这些存储在 S3 上，并且所有 EC2 实例都会不时检查 S3 以获取更新的配置？

我觉得其中缺少了一些我不知道的环节。我最常看到的是人们建议您创建一个新的 AMI，然后关闭当前实例并用新实例替换它们。这似乎是一个沉重的负担，尤其是在多站点结构中，这些更改可能只针对单个站点。是否有处理此类代码更改的首选方法？

Answer 1

1. 我正在考虑使用的一种技术是构建自定义 AMI，在启动时会下载必要的数据来引导自身。对于你的情况，你可以将你的网站保留在 S3 上并在启动时下载文件。如果你使用云初始化对于 Ubuntu 或其他发行版的类似版本，您可以非常轻松地编写站点安装脚本。我相信它只在第一次启动时运行，因此节点的滚动终止应该可以让站点保持最新版本。在这种情况下，您不必不断更新 AMI。

2. 如果您没有设置配置管理系统，那么将一个包含您需要的配置的文件保存在 S3 上就足够了。随着您的成长，Chef 或 Puppet 可能会更好，但它们需要一些时间来学习。此文件可以以相同的方式加载，也可以使用 Fabric 或 Capistrano 等工具触发。

Fabric 和 Capistrano 可以帮助您触发较小的更新。如果您重复使用 CloudInit 脚本，则无需编写两次代码。Fabric 和 Capistrano 都可以轻松地与 AWS API 集成，以允许动态查询正在运行的节点，因此您不必维护不断变化的服务器列表。

最近推出了一款用于制作 AMI 的工具，名为打包机对你也有帮助。在第一次尝试中，我能够在开始本教程后 30 分钟内创建一个新的 AMI。它还可以帮助为多个区域创建 AMI。