我管理的网站本质上只是一个由 WordPress 提供支持的新闻/博客。该网站的平均用户数在 8-15 之间。但我们偶尔会发布我们领域的新闻，届时会有 1.5-5,000 人在线。直到今天，我们一直通过 VPS 托管该网站Dreamhost。我们转向了 AWS/EC2，因为我认为它的可扩展性会很好。
我备份了整个服务器，启动了一个 EC2 实例（t2.micro 正在运行Bitnami 推出的适用于 AWS 的 WordPress)，为其创建了一个存储驱动器，为其提供了一个弹性 IP，迁移并恢复了我们所有的数据（使用 UpdraftPlus）。然后我很高兴服务器运行正常，关闭了我们之前的服务器，并创建了一个指向 AWS 实例 IP 的 DNS 记录。
但是，今天我们遇到了一个问题，CPU 的使用率被限制在 100%，而 CPU 积分仍然可用。我以为可用的 CPU 积分会扩展服务器，这样它就不会被限制在 100% 的使用率。我想我误解了。所以我认为我需要设置一个自动扩展组。所以我从已经设置的实例创建了一个 AMI，创建了一个启动配置，并创建了一个负载均衡器。然后，我将自动扩展组设置为具有 1 个所需实例、1 个最小实例和 5 个最大实例，如果 CPU => 85% 则启动一个实例，如果 CPU =< 35% 则关闭一个实例。
我以为这样就好了，但我在设置完成后遇到了一个问题。它终止了我之前设置的实例，并使我的整个网站瘫痪。然后我惊慌失措地四处奔波，直到我意识到它没有删除存储，于是我启动了另一个实例并附加了该驱动器。
我这里漏掉了什么吗？如何设置 AWS/EC2 来处理使用完全相同数据/网站的几千名用户，并始终保持其运行，而不是终止我的原始实例？
任何帮助将不胜感激。
答案1
多读一些有关 AWS 的内容并在生产之外进行练习是个好主意。有很多指南，AWS 本身也提供了很好的信息，这并不难。在生产站点上工作之前，你应该在另一个 VPC 或区域中进行测试。
t2.micro 仅限于一个核心，无论 CPU 积分如何。自动扩展需要时间才能启动，具体取决于警报/监控间隔。您可以将现有实例添加到 elb，但我倾向于设置它，添加它们，然后让它添加自己的实例并停止原始实例。
自动扩展组、“黄金”AMI 和 RDS 将是简单的选择。但是，您最终可能会得到不同的 Wordpress 版本，因此这需要更多思考。您可以在 Web 服务器级别设置缓存，Nginx 非常出色，可以大大减少您的负载 - 至少减少一个数量级。
我有一个教程可能对你有用这里。它不会进入自动缩放功能，因为我自己并不需要它，但设置起来很简单 - 我已经做过很多次了。
答案2
当您开始使用 Auto Scaling 时，您需要习惯一个事实：EC2 实例将启动，EC2 实例将终止。即使 Min = Max = 1，您的实例也可能随时终止并被替换。不要认为这是一件坏事，只要习惯它并坚持下去即可。从长远来看，这是一件非常好的事情。
要开始 Auto Scaling，您需要将数据库从 Auto Scaled 实例中移出。数据可能位于另一个 EC2 实例上，也可能位于 RDS 实例上。这无关紧要。但它不应该位于正在启动和终止的 EC2 实例上。这主要有两个原因：
- 如前所述，您的单个 EC2 实例可能会被终止和替换，或者
- 您最终可能会得到 2 个或更多需要访问同一组数据的 EC2 实例。
从 EC2 实例中获取数据后，您将设置一个“主”EC2 实例。此“主”实例将是您通过 SSH（或 RDP）从代码/版本角度更新 WordPress 站点的 EC2 实例。它将在其生命周期的 99% 时间内处于停止状态。它的唯一目的是在您更新 WordPress 站点的版本或代码时生成新的 AMI 映像。您：
- 启动它
- 登录并更新您的网站
- 停止实例
- 创建 AMI
- 使用新的 AMI 更新您的 Auto Scaling 组
- 滚动终止您现有的 Auto Scaling EC2 实例，它们将被新 AMI 中的全新 EC2 实例替换。请注意，在此期间，可能会有 EC2 实例运行您网站的不同版本。
如果可以的话，我建议如下：
- 为您的 Auto Scaling 组使用多个可用区，并且
- 至少有 2 个实例，而不是 1 个。
这样，您就不会因为一个 EC2 实例发生故障而导致整个站点瘫痪。
还有其他方法可以处理自动缩放、更新等。但对于初学者来说，上述框架相当容易理解。