EC2上的许多小实例或更少的大实例

Xya*_*and 5 amazon-ec2 amazon-web-services

我有一个在EC2实例(c3.large)上运行的计算/ IO重型后端服务(图像处理).由于我需要扩展此服务,我考虑分配数十个c3.large实例或更少的较大c3实例.定价似乎是每计算能力的线性.

为什么我会在更弱的实例上选择更少的强实例?(反之亦然)

其他一些要求和信息:

  • 扩展以满足峰值要求
  • 任务是单线程的.每个实例可以运行多个任务.
  • 内存签名低
  • 磁盘使用率非常低
  • 获取图像的潜在高网络使用率(非常快速的计算)

Mic*_*bot 2

按需价格在每个实例系列中确实是相当线性的,因此,如果您的工作负载在多个类上运行得同样好(即没有单个任务需要特别大量的内存),那么可能不会有显着差异...网络 I/O 容量以及内存和 ECU ……以及未被充分重视的临时存储空间(不会产生基于 I/O 的费用)也得以扩展。

然而,现货市场的价格并不那么线性。

我的内部系统收集现货市场定价历史记录(可在控制台中和通过 API 获取),该历史记录确定了历史上保持给定实例在给定可用区域中以给定正常运行时间百分比运行所需的最低出价。当然,历史数据并不能预测未来的性能,并且 c3 系列仍然非常新......但在现货市场上,存在对较小实例的需求推高运营成本的情况 - 至少基于同等水平计算能力,尽管有时甚至以原始价格计算——也比更大的实例要强……所以这可能是一个值得考虑的选择。

现货市场对每个实例类 + 可用区都有一个最低基准价格(可能实际上是区域,尽管价格是单独跟踪的),并且这些基准在实例系列内似乎是线性的,正如您所期望的......但市场价格会发生变化随着需求的增加,导致了我提到的倒置。另请注意,给定实例类的 EC2 Classic 和 VPC 价格也会单独跟踪,因为每个平台内的备用容量大概是物理主机的单独集合。

另请注意,如果您采用此方法,您应该调查所有实例类,而不仅仅是那些明显适合您的工作负载的实例类。有一些极其有利的定价条件等待被发现,特别是在更大、更旧的实例类别上……而且这些定价条件似乎随着时间的推移通常会更加稳定,不过,这些都是基于过去表现的观察结果。