每个网站 1 个 EC2 实例 - 使用 EC2 在 Amazon 云上管理多个网站

Question

首先，一些原始数据取自S. Ostermann 等人，2010 年：

基本实例规格：

+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
|   Name    |  ECUs   | RAM  | Archi |  I/O  | Disk | Cost  |    Reserve    | Reserved Cost |
|           | (Cores) | [GB] | [bit] | Perf. | [GB] | [$/h] | [$/y], [$/3y] | [$/h]         |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
| m1.small  | 1 (1)   | 1.7  | 32    | Med   | 160  | 0.1   | 325, 500      | 0.03          |
| m1.large  | 4 (2)   | 7.5  | 64    | High  | 850  | 0.4   | 1300, 200     | 0.12          |
| m1.xlarge | 8 (4)   | 15   | 64    | High  | 1690 | 0.8   | 2600, 4000    | 0.24          |
| c1.medium | 5 (2)   | 1.7  | 32    | Med   | 350  | 0.2   | 650, 1000     | 0.06          |
| c1.xlarge | 20 (8)  | 7    | 64    | High  | 1690 | 0.8   | 2600, 4000    | 0.24          |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+

基本性能/成本分析：

+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
|    System     | Peak Perf. |   HPL    | STREAM | RandomAc. | Latency | Bandw. | GFLOP/ECU | GFLOPS/$ |
|               | [GFLOPS]   | [GFLOPS] | [GBps] | [MUPs]    | [µs]    | [GBps] |           |          |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
| m1.small      | 4.4        | 1.96     | 3.49   | 11.6      | -       | -      | 1.96      | 19.6     |
| m1.large      | 17.6       | 7.15     | 2.38   | 54.35     | 20.48   | 0.7    | 1.79      | 17.9     |
| m1.xlarge     | 35.2       | 11.38    | 3.47   | 168.64    | 17.87   | 0.92   | 1.42      | 14.2     |
| c1.medium     | 22         | 3.91     | 3.84   | 46.73     | 13.92   | 2.07   | 0.78      | 19.6     |
| c1.xlarge     | 88         | 51.58    | 15.65  | 249.66    | 14.19   | 1.49   | 2.58      | 64.5     |
| 16x m1.small  | 70.4       | 27.8     | 11.95  | 77.83     | 68.24   | 0.1    | 1.74      | 17.4     |
| 16x c1.xlarge | 1408       | 425.82   | 16.38  | 207.06    | 45.2    | 0.75   | 1.33      | 33.3     |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+

实际性能通常低于理论性能的 50%。一组可能值得怀疑的值是 c1.medium 的值，它们与预期结果（例如带宽）不太一致。

对于典型工作负载，EC2 的主要成本是实例成本 - 其他成本（带宽、预置存储等）通常占总成本的 25% 以下。人们并不期望性能能够完美扩展 - 从上面的数据中可以明显看出这一点。特别是在水平扩展方面，似乎随着计算能力的增加，效率会显著下降。

鉴于上述情况，并记住除了原始计算性能之外还有其他因素（例如 I/O 性能、内存等），因此垂直扩展是最经济的方法。

不幸的是，除了场景的经济性之外，还有其他考虑因素。可靠性是关键。对于单个实例，该实例的故障将导致整个设置崩溃。一种可能的解决方案可能是自动扩展（即保持实例数为 1），但是单个实例仍然容易出现给定可用区域中可能出现的问题等。

在某些时候，水平扩展是必要的 - 问题只是何时是理想时间。我可能会建议： - 垂直扩展至少几个实例大小（如果您从 t1.micro 开始，则需要更多） - 将数据库分离到单独的实例（因为它们的扩展方式与您的 Web 服务器不同） - 水平扩展直到您有一点冗余 - 垂直扩展直到达到最大实例大小 - 此后水平扩展（最初可能使用较小的实例）

回到手头的问题 - 每个实例（或每组实例）运行一个网站总是更昂贵。除了固定成本较高（例如每个网站一个负载均衡器，而不是一个负载均衡器）之外，您还无法高效地利用实例（即，一个网站可能会在其他网站大部分处于空闲状态时看到高负载 - 这意味着您有一些实例过载，而其他实例处于空闲状态）。在物流方面，问题可能没有人们想象的那么严重 - 主要问题归结为独立管理一切（您可以使用一些配置管理工具（例如 Puppet/Chef）来避免这种情况，但这通常不是您的设置变得更大之前要采取的步骤）。

另一方面，EC2 实例的限制之一是您只能为给定实例分配一个公共 IP 地址（这对某些 SSL 设置有一定影响）。

当然，您可以生成自己的 AMI - 事实上，这是相当标准的做法。我通常从亚马逊的 Linux AMI因为我发现它是开销最少（资源占用很少，而且速度很快）并且受 AWS 支持最好的（它会定期更新等）——而且我更喜欢 RHEL/CentOS 发行版（Amazon 的 Linux 基于此），而不是另一个流行的选择 Debian/Ubuntu。一旦您自定义了一个实例，您就可以拍摄 EBS 卷的快照并注册一个 AMI——将快照 ID 作为根卷的基础映像传递。理论上，您可以更多地自定义您的操作系统，甚至可以构建自己的发行版（但仍然使用 Amazon 内核）——但是，除非您有非常具体的用例，否则这不太可能特别有益。我个人偏爱运行 Wordpress 的是 Varnish + Nginx + PHP-FPM（以及用于 Wordpress 的 W3TC）——我发现它比典型的 LAMP 堆栈更节省资源。

最后，再次讨论扩展问题。除了上面讨论的问题的基本经济学之外，困难在于让多个实例“看起来”像一个实例。这包括确保每个实例都提供相同的数据、在实例之间进行负载平衡，以及处理 PHP 会话等细节。如果每个站点都在自己的一组实例上运行，那么难度会更大 - 但可能不会太大（因为您希望将功能配置到 AMI 中）。但是，多个实例确实意味着更复杂的系统，需要关注更多的事情。（ServerFault 上有很多关于这个主题的问题，例如这，这，或者这- 如果您需要有关如何扩展特定设置的详细信息，请将其作为另一个问题提出）。

最后一点 - 除非您的设置有特殊需求，让单个站点在其自己的实例/集群上运行（例如，配置/要求有很大不同），否则我倾向于在单个实例/集群上运行多个站点，因为它更容易扩展、更经济、更高效，并且更符合“云计算”（即共享资源）的精神。

参考：

S.Ostermann 等人EC2 云计算服务对科学计算的性能分析，2010 年
A. Iosup 等人，多任务科学计算云计算服务性能分析，2010 年——有关水平扩展的更多详细信息，请参阅表 9。

Answer 1