云计算技术是否会使摩尔定律失效?

译文
云计算
长远角度来看,这些云服务供应商到底能否利用虚拟化基础设施带来积极而且持续的价格削减成效?或者说这仅仅只是一场巨头们的角力游戏,根本不适用于那些规模较AWS、微软Azure以及谷歌云平台为小的其它云服务供应商?

[[138142]]

时至今日,各大超大规模服务供应商正凭借着手中的硬件与软件工程技术相互竞争,旨在以高于摩尔定律所规定的速度削减基础设施中的计算与存储组件使用成本,从而令自家系统在残酷的市场当中脱颖而出。而超越摩尔定律的一部分动机在于,此类服务供应商的主要运营成本恰恰来源于此,而任何一点点提升都会给业绩带来巨大的推动。不过对于像谷歌以及微软这样的技术巨头而言(后者目前正凭借着其Azure公有云向市场王者Amazon Web Services发起冲击),计算与存储容量在使用成本上的一路走低则意味着他们能够进一步削减服务方案价格,从而打击AWS的市场优势并夺取其固有份额。

那么从长远角度来看,这些云服务供应商到底能否利用虚拟化基础设施带来积极而且持续的价格削减成效?或者说这仅仅只是一场巨头们的角力游戏,根本不适用于那些规模较AWS、微软Azure以及谷歌云平台为小的其它云服务供应商?

从谷歌角度来看,其过去一年当中所做的一切都是为了尽可能降低其计算与存储资源的使用成本,此外亦在尽可能践行其对于自家公有云方案作出的价格下调承诺。这位希望能够在云计算市场上进一步拓展自身占有率的搜索引擎巨头同时也为各类计算实例推出了与Amazon的精确实例相仿的方案选项——名为Preemptible VM——旨在保持现有低价举措之外(例如按分钟计费以及为按需实例的长期使用提供价格优惠),进一步把价格控制在更低水平。(谷歌公司目前并不提供预留实例服务,而微软亦不具备此类选项,但后者允许企业客户在许可协议当中以批发价采购Azure云资源。)

谷歌Compute Engine基础设施云当中的预定虚拟机计费方式为我们带来了几项启示。首先,谷歌公司在自有数据中心之内拥有充足的备用容量,这意味着在其内部工作负载不必占用这些系统时,谷歌能够将其拿出来供云服务客户偶尔使用——否则这部分基础设施将只会无意义地空转而没办法带来任何收益。(正如曾经效力于微软、且目前继续在AWS从事同样的基础设施运营工作的James Hamilton所言,我们能做的最愚蠢的决定就是关闭某台服务器。相反,比较明智的方法是给它找点活干,毕竟对于已经购置进来的设备来说,只要不用就是种浪费。)

除此之外,Compute Engine当中所存在的精确实例也证明谷歌公司拥有足够庞大且多元化程度较高的客户群体,他们对于计算实例有着各自不同的需求,而且从客户角度出发、其足以通过有序方式将过剩产能消耗掉。对于云服务供应商来说,除非其对于当前客户的实际资源需求量了然于胸,特别是利用并发工作负载而非向系统中添加新负载以提高处理任务完成效率,否则根本没办法提供精确这类云基础设施计费方案并借此降低整体计算成本。当然,大家可以非常直观地了解到精确计费机制的吸引力所在,因为它允许客户将本来毫无用处的闲置容量充分利用起来,同时帮助云服务供应商免除对基础设施容量作出进一步拓展所带来的额外成本。随着客户不断在实践当中了解到如何针对自己的工作负载选择按需、预留与精确实例,他们也将能够帮助服务供应商提高现有服务器及存储集群的使用效率。

对于云服务的相关各方来说,这无疑都将是一种三赢的积极局面。

正如谷歌公司在去年三月发动云服务价格战时所解释的那样,由于其Compute Engine实例的价格削减幅度已经超过32%,因此云方案的费率变动算是在一定程度上符合了摩尔定律所作出的设想。谷歌公司认为这才是云服务供应商应该拿出的成果,而客户自然也乐于享受这样的良好收效。

根据这位搜索引擎巨头以及全球四大公有云服务商之一麾下技术基础设施团队高级副总裁Urs Hölzle给出的计算结果,云基础设施使用价格每年的下调比例可能会在6%到8%之间,与此同时整套系统的使用成本则会以20%到30%的幅度逐年增加。因此来看,系统在制造与维护方面必然会出现一定程度的错位,这是因为随着时间推移用户需要负担的成本会越来越高。不过谷歌公司却并不为此所动,其制定出的努力方向仍是尽可能让云服务使用成本遵循摩尔定律的变化曲线。除了自然递进的云服务价格下调之外,用户还能够在持续使用所购买的Cloud Platform资源时享受到自动优惠折扣。具体而言,客户能够以分钟为单位而非像过去那样以小时为单位进行资源使用计费——这是谷歌公司率先推出了新型计费机制——而本周谷歌方面公布的价格下调公告指出,精确实例计费将把谷歌云的使用成本压缩到***的低点。(大家应该会注意到,谷歌公司并没有在去年三月针对Compute Engine推出精确实例计费机制。毫无疑问,谷歌当时已经有能力拿出这套方案,但也许他们是希望能够把这种主动性保留到2015年,因为这时其客户群体的规模必然会更加庞大。)

在超大规模环境下,情况与典型的企业内部数据中心往往会有所区别。容量规划不再是一项针对各自企业所设定的精准科学,而对于需要处理大量自身业务(包括各类需要运行在成千上万个节点上的应用程序,再加上总数超过百万的节点总量)以及将数万乃至数十万客户顺利承载在自家Cloud Platform之上的谷歌公司来说,制定容量规划显然会更加轻松。微软与Amazon双方在过去接受媒体采访时都曾经提到,容量规划对于他们来说并不是什么大问题——尽管这听起来确实有些难以置信。面对数量庞大的用户以及跨越多个时区的可观基础设施布局,就连负载峰值与低谷也开始得到有效缓和,而客户群体的发展速度也更具可预测性。斥资购置基础设施容量当然是件需要重视的大事,因此各云服务供应商也会建立起理想的供应链,从而利用来自多家供应商的定制化设备添加进来以满足客户对资源容量的需求。

超大规模公有云运营商会以整车运价采购系统组件——跟字面意思差不多,设备确实是一车车被运进基础设施所在位置的——而归功于对系统方案本身的精确定制外加以独立组件为单位向供应商及系统制造商下达订单,云服务供应商往往能够获得极为低廉的产品购置成本,从而保证自身容量成本呈现出逐年递减的势头。由Facebook公司发起的开放计算项目正是希望将超大规模所蕴含的优势从大型服务供应厂商转移至更多其它企业当中,不过到目前为止,这套方案基本还仅仅停留在理论层面——因为绝大多数企业所需要的设备总量仅为数十或者数百台,而非像公共服务供应商那样需要数千甚至数万台。当然,企业仍然能够通过从戴尔、惠普、Supermicro乃至广达电脑等厂商处购置半定制化设备而享受到开放计算项目带来的一定回报。

#p#

云服务的价格能够压缩到怎样的水平?

目前对于IT部门而言,这场激烈的云服务价格战仅仅存在于三大***云服务供应商之间——这是因为其它几十家供应商在云容量规模方面根本达不到这三家巨头的水平或者说高度。谷歌、微软以及AWS各自拥有着超过一百万台设备。而且根据AWS公司所给出的一部分自有数据中心数据,其基础设施内的设备数量很可能在140万台到560万台之间,而且我们认为其设备数量超过300万台的可能性非常高。Gartner公司在去年发布的报告中则预测称,AWS旗下的设备总数应该在240万台左右。Gartner方面同时指出,AWS的整体服务器数量达到了其后十四家云服务供应商设备总和的五倍。Rackspace Hosting与IBM SoftLayer各自拥有着规模较小的云服务体系。根据Rackspace公司发布的财报显示,截至今年三月底该公司拥有11万4105台设备,而SoftLayer在2014年一月时的设备总量已经超过了10万台,而且根据IBM方面的说法其每年约以2万台的速度递增。因此截至目前,蓝色巨人的基础设施规模应该在12万5千台左右。换句话来说,一旦我们将视线投向AWS、谷歌以及微软之外的云服务供应商,其现有基础设施的规模、或者说服务器整体数量会出现快速跳水。

而这一点非常关键,至少就目前来说大部分云服务仍然立足于裸机设备,而这也是单一应用程序、集群化应用程序节点或者虚拟机管理程序的托管基础——而且至少与软件容器机制相比,这种方式的日常成本显然要高得多。所有这些裸机设备都能够在不同时段实现共享,但却无法在同一时间范围内被并行使用。而这就令我们很难提高资源利用率,这意味着云服务供应商几乎无法利用多种工作负载及客户需求对裸机设备成本进行摊薄。

正是考虑到裸机服务器节点的上术局限,如今OpenStack项目才将其作为Ironic方案的一大关键性发展方向。任何能够在裸机之上实现应用程序部署提速的机制都将有效改进资源使用效率。而且如果容器能够将更多处理任务囊括在同一台设备之上,那么即使不打算借此取代服务器虚拟化方案,这也足以将资源利用率推向新的水平。这种裸机配置加软件容器的技术组合在很多情况下甚至有能力取代管理程序与虚拟机在云环境当中的地位,而这自然也有助于云服务供应商完成对摩尔定律的遵循。在大多数情况下,容器将运行在虚拟机基础之上,而这在提高安全水平以及工作负载管理能力的同时,当然也会浪费掉一部分设备性能、从而削弱摩尔定律的理论收益。

从客户的角度出发,谷歌公司对其Cloud Platform作出的价格持续下调承诺确实非常美好,而这也许意味着谷歌拥有出色的先见之明。下面我们来看谷歌公司自2013年11月***推出其Compute Engine基础设施云服务之后,到底有没有践行自己的降价承诺:

没有哪家云服务供应商愿意把钱浪费在不必要的基础设施容量购置上,而谷歌公司在过去十八个月当中已经将其Compute Engine容量使用费降低了50%的作法并不代表其会在未来十八个月中继续保持这一降价趋势。另外,这自然也不代表所有类型的计算与存储容量都能获得同样的价格下调幅度。事实上,Compute Engine的价格下调速度在一年之前基本保持平稳,但不同类型的实例有着不同程度的成本变动曲线。微型实例的降价幅度约为30%,而标准实例的价格降幅仅为20%,负载强度较高的存储实例价格降幅约在15%,而高CPU使用率实例的价格下调空间只有可怜的5%。

以上图表当中所示的典型价格曲线指的是全部客户在使用Compute Engine时为特定实例类型所支付的平均使用成本,这似乎意味着大部分客户都已经享受到了谷歌公司所提供的长期使用折扣——这项政策会自动应用至Compute Engine上的按需实例当中。随着按需实例使用周期的不断延长,从第二个月起用户所需支付的实例价格开始不断降低。如果大家每个月使用某实例的时长比例仅在25%甚至更低,那么我们需要为其支付全额使用费; 但在这一比例提升至每月50%时,各位则可以享受到10%的计费折扣。(计费机制并非以周为单位而是以小时为单位,不过我们选择以周计算来简化显示效果。)

当然,谷歌公司的想法是尽可能早且尽可能持久地帮助Cloud Platform完成所需容量规划及调度。而且预订虚拟机实例则属于另一种达成这项目标的工具。在这种情况下,容量需求可能不像供应流程那样易于预测,或者使用量相对而言较为混乱。(只有云服务供应商能够了解资源容量的分配情况,他们甚至会向华尔街等主要客户发出警告,表示过去的性能水平并不能作为未来性能的保证。)在预订虚拟机实例的帮助下,所有此类实例都将以beta形式存在于各Cloud Platform区域当中,而谷歌公司直接将所有实例类型的价格削减70%; 当然,使用此类新型实例时需要注意一点,即谷歌可以在任何时间将其关闭,而且运行在其上的工作负载最长不能超过24小时,而且用户无法以实时迁移方式将其中的虚拟机负载转移到按需实例当中。这类实例最典型的适用情况就是应用程序需要以分布式方式运行,且能够在任何时候遭遇节点丢失时继续正常运行。举例来说,大家可以将其视为在Hadoop与MapReduce领域非常常见的三重数据存储负载。大家也可以将应用程序的一部分片段运行在按需实例当中,另一部分则交由预订实例负责。当然,大家应该将此作为对现有按需实例方案的补充,而非以廉价方式获取资源容量的办法。

摩尔定律的缺陷所在

需要注意的是,谷歌公司去年曾经表示其定价机制将遵循摩尔定律,这种说法的实质恐怕并不是持续提高资源容量规模、而是尽可能从单位容量当中获取更理想的使用效率并由此降低成本。这几乎必然意味着谷歌公司不可能在定价方面采取更具侵略性的下调幅度,除非其需要以价格为手段向AWS以及Azure施加压力。除此之外,这也意味随着摩尔定律曲线对计算、内存以及其它存储资源成本的压缩,谷歌云服务的价格亦必须同步下降。

而这正是问题所在。随着容量使用成本的不断降低以及价格的同步削减,云服务的运营利润亦将愈发少得可怜。有鉴于此,云服务供应商将需要通过规模化求盈利,从而保证自身拥有健康的营收数字与利润额度。为了切实提升年度收益增幅,云服务供应商将不得不确保自身业务扩展速度高于摩尔定律设定的价格降幅。

所以真正的问题在于:公有云到底能否持续实现营收增长,例如在长期角度实现同比40%以上的年均增幅,同时仍然为谷歌、微软以及Amazon等服务供应商带来符合预期的利润水平?从短期角度来看——例如在过去九年当中,AWS一直处于稳定的发展态势,但在接下来的五到六年中摩尔定律很可能在计算领域遭遇某些物理局限——这一目标似乎并不难实现。

不过就当前的状况分析,摩尔定律的推进脚步已经开始逐渐放缓——除非能有新兴技术成果出现并扭转这一切,否则未来计算、存储与网络资源容量的成本下降幅度将愈发有限。而各云服务供应商也将因此而很难在进一步下调价格的同时保障利润水平。不过无论是否出现新兴技术、也不管各供应商到底是否面临着生存压力,云计算领域的这场价格战仍将继续存在——更具体地讲,他们不仅要舍弃利润,更需要做好白忙甚至亏损的心理准备来尽可能保证业务规模增长。这种状况原先在PC及服务器领域也曾经出现过,而且我们有理由相信这种状况在有着众多技术巨头加入的云业务领域亦将存在、甚至呈现出更为可观的实际规模。

原文标题:Can Cloud Pricing Stay On Moore’s Law Curves?

 

责任编辑:Ophira 来源: 51CTO
相关推荐

2012-05-17 13:38:17

2015-05-13 09:58:23

摩尔定律

2009-04-13 10:47:19

IBM计算机摩尔定律

2010-05-05 09:46:03

NVIDIA摩尔定律

2009-05-25 10:02:47

SanDisk摩尔定律失效

2010-05-04 12:42:46

英特尔

2009-03-10 11:14:59

2022-12-30 13:35:48

2018-12-27 09:39:30

存储

2009-06-17 09:16:55

摩尔定律失效

2012-11-12 09:56:40

ARM服务器微服务器

2010-03-22 14:43:54

摩尔定律

2011-05-19 09:06:51

2013-01-09 10:07:37

摩尔定律处理器ARM

2009-10-15 11:16:06

摩尔定律计算机速度

2010-02-01 10:30:09

摩尔定律“电子自转”

2013-05-14 09:12:01

Intel摩尔定律工艺制程

2023-07-04 07:57:08

Chiplet技术

2020-07-09 14:44:07

AI芯片检验期
点赞
收藏

51CTO技术栈公众号