amazon-web-services - 多个 t2.micro 优于单个 t2.small 或 t2.medium

Question

我阅读了 EC2 的文档:instance types , pricing , FAQ , burstable performance还有this关于CPU积分。我什至询问了以下 AWS 支持，但答案并不明确。

事实是，根据文档(虽然不太清楚)和 AWS 支持，所有 3 种实例类型在突发时具有相同的性能，即某种类型的 CPU 核心 100% 使用率。

这就是我的思考过程。假设 t2.micro 的 RAM 足够并且软件可以水平扩展。拥有 2 个 t2.micro 与 1 个 t2.small 的成本相同，假设负载在它们之间平均分配(可能通过 AWS LB)，它们将使用相同数量的总 CPU 并消耗相同数量的 CPU 积分。如果他们回落到基线性能，情况也是一样的。

但是，当它们爆发时，2 t2.micro 可以实现 t2.small 性能的两倍(同样，成本相同)。相同的概念适用于 t2.medium。此外，使用较小的实例可以实现更严格的自动(或手动)扩展，从而节省资金。

所以我的问题是，鉴于 RAM 和水平缩放不是问题，为什么要使用 t2.micro 以外的其他产品。

编辑:经过一些回复后，这里有一些关于它们的注释:

• 我询问了 AWS 支持，据说 t2.medium 的每个 vCPU 都可以实现 50% 的“全核”。这意味着我所说的同样适用于 t2.medium(如果他们所说的是正确的)。
• T2.micro 实例可用于生产。根据技术和实现情况，单个实例可以处理超过 400 RPS。我知道，this guy 也是如此。 .
• 它们确实需要仔细检查以确保积分不会降低，但我不认为这是不使用它们的理由。

Answer 1

您的分析似乎是正确的。

虽然处理器类型没有明确记录，但我通常会看到我的 t2.micro 实例配备一个 Intel Xeon E5-2670 v2 (Ivy Bridge) 核心，而我的 t2.medium 实例则配备两个核心。

只要剩余合理数量的 CPU 积分，微型计算机和小型计算机确实应该具有相同的突发性能。我说“一个合理的数字”是因为记录显示性能在 15 分钟窗口内缓慢下降，而不是像 t1.micro 那样急剧下降。

随着你的升级，关于这三个类别的所有内容(除了核心，微型还是小型)都会乘以二:基线、每小时获得的学分和学分上限。可以说，就短期突发性能(具有两个核心)而言，该介质非常接近于两个小型处理器，但话又说回来，正如您所指出的，这也正是两个微型处理器所具有的功能。如果内存不是问题，并且流量适当突发，那么您的分析是明智的。

虽然 t1 类几乎完全不适合生产环境，但 t2 类却并非如此。他们是天壤之别。

如果您的代码在内存方面紧凑且高效，并且您的工作负载适合基于 CPU 信用的模型，那么我同意您对 t2.micro 所代表的卓越值(value)的分析。

当然，这是一个巨大的“如果”。然而，我的网络中有一些系统完全适合这个模型——它们的内存几乎完全在启动时分配，它们的负载相对较轻，但在一天的过程中变化很大。只要您的信用余额没有耗尽，我认为这种方法没有什么问题。