如果仔细查看图表,您会发现峰值总是持续很短的时间-足够的时间让所有者编写的自动监视系统正常终止这些系统。此外,您偶尔会发现价格在飙升后立即跌至0。这是因为该数据中心中的所有系统都按需使用,没有可用的现货定价系统,价格实际上为零。
当您的竞价型实例标记为终止时,指示该消息的消息将在系统上的http://169.254.169.254/latest/meta-data/spot/termination-time的本地元数据uri上可用。它将持续3分钟。在大多数情况下,有足够的时间来自动处理终止。仅在需要花费几分钟时间才能正常终止的部署中,才需要以高于需求价的价格竞标。
如果无法在3分钟内将系统设计为正常终止,归档数据等,则可以将出价提高到高于需求价格的水平,从而节省时间。该系统甚至可以设计为主动监视当前现货价格,并在价格结束之前进行交换。但是在那些时候,您需要做出一个业务决策,以决定这段时间里优雅终止的价值是多少。
为了保持系统状态而在4-5个小时内每小时支付$ 100是愚蠢的。但是,如果您的系统需要30分钟才能正常终止所有流程,则您可以做出业务决策,以决定丢失任何数据或降低水平扩展服务的价值。一个电子商务站点每小时的净利润为10,000美元,一定可以支付1000美元来保持两个现场实例在15到30分钟内运行,同时启动需求系统和归档数据。
基于Web的应用程序可以使用Elastic Load Balancer帮助自动解决终止问题。一个聪明的实现者将放置一组脚本来处理警报。他们可以维持2个负载均衡的低成本按需实例,然后通过竞价型实例使用多达六种中等成本的系统来维持高性能,并花费少于同容量的单个按需系统。
让其中3个人支付最高$ 100 /小时的费用,其中3个人仅支付最高按需价格的一半。随着AWS终止实例,ELB将自动进行调整。只需200美元,就可以让自动系统最多调动一个小时。