我将扩展一个可供 100,000 名用户使用的应用程序。该应用程序托管在 NodeJS 中。我已经为我的应用程序创建了 docker 镜像，并且还使用了 AWS ALB 等。我的应用程序很小，我主要关心的是访问该应用程序的用户数量。该应用程序仅占用 600mb 内存（最大值）用于容器。因此，我使用了 8 个 t2.small（2GB RAM 机器）实例，并在每个实例中托管 3 个容器（即 8 X 3 = 24 个容器（每个容器 3 个））。使用此架构，我可以将其扩展到最多 5000 名用户。我可以将其水平扩展到最多 100,000 名用户，但我担心的是，如果我选择 m4.large 而不是我选择的 t2.small 机器会怎样。
因为除了使用 8 台 t2.small 机器（8 X 2GB = 16GB）之外，我们还可以使用 2 台 m4.large 机器（2 X 8GB = 16GB）。并且还可以在其中托管 24 个容器。
我选择 t2.small 实例的原因是 vCPU 值。t2.small 和 m4.large 都有 2 个 vCPU。因此，如果我们使用 2 台 m4.large 机器，这 24 个容器将有 4 个 vCPU。但如果我们使用 8 个 t2.small 实例，我们将为这 24 个容器获得 16 个 vCPU。
但是，我还需要考虑其他因素吗？如能提供任何建议，我将不胜感激。
答案1
m 类型的实例是内存优化的，如果不需要内存，m 实例可能不是正确的选择。这在很大程度上取决于您的应用程序和负载下的资源要求。
一个因素是成本和动态扩展，这取决于具体情况。如果您需要高可用性，则至少需要两个实例。考虑到您的 2 x m4 场景，这意味着您在任何时间点都拥有 100% 负载运行所需的资源。通常，应用程序有高峰时间和只需要一小部分资源的时间。选择 8 x t2 意味着您可以将资源缩减到所需资源的 25%，同时保持高可用性。所有这些考虑都会对成本产生影响。
建议：
- 确定基线用户量（最小配置）。
- 将其除以所需的高可用性因子（例如二）。
- 将典型用户请求抽样到负载测试（例如 jmeter）中，设计负载测试密度以满足计算值
- 启动可以满足需求的不同实例类型（不要在这些测试中使用负载均衡器）
- 在运行负载测试期间监视它们（例如 CPU、内存），以确定哪种类型最适合您的应用程序
- 相应地设计自动缩放（使用负载测试的经验作为缩放触发器的起点）
- 根据需求行为（用户）进行过度供应
- 如果需要，可以在高峰时段之前预先扩大规模