Tag Archives: 云服务

[得到大学课程作业] 如何设计云服务的计费策略?

  不仅游戏,所有提供虚拟产品的场合都需要应用“造物者”思维模型,制衡各方利益,引导体系演进。我曾负责设计过一个复杂云服务产品的计费策略,深有体会。

  简单介绍一下,这个云服务主要用于对上千张表、上P的数据进行复杂的计算。典型的一次计算任务,往往占用上万节点几十个小时,说耗费的存储、计算和下载流量成本超过几十万元。麻烦在于,系统不是独占的,往往有上百个用户的不同计算任务混在一起。

  如何计费?常规思路往往从技术实现角度拆分,把一次计算任务占用的进程、内存,以及中间IO交换的数字都拿出来,分摊到对应的CPU、内存、网络设备和磁盘的折旧成本去。然后再加上一定的利润率。

  然而,想深一点的话,这种计费策略并不好:

  1> 从用户角度看:“运行时间”这个变量用户失去控制。海量数据的分布式计算有特殊之处:很可能第一次运行用10分钟,重跑一下,调度到另一个节点,就用了12分钟。相同的计算任务,有时收1块,有时收1.2块,用户疯掉了。

  2> 从平台角度看:如果技术团队优化了底层系统,把计算速度加快1倍,收入就少了50%。这会让平台方丧失优化动力。

  于是退回原点,先定义什么是好的计费策略:

  1. 基于统计,简单可解释:基于统计;尽量简化;输入参数用户可控;

  2. 可预期,可重复:实际运行前就能算出花费;同样的任务重跑,价格不变;

  3. 正引导性:各个角色做好事(优化自己的代码)不受惩罚,最好获得奖励。

  一个例子是手机话费:两个人面对面手机通话,与一个在城南一个在城北通话,实际成本肯定不一样。如果运营商按照通信链路经过了几个路由器、几次转发来计费,用户就晕倒了。所以手机计费策略采用阶梯的、区域的、分时的模型,符合上面3条原则。

  最终的计费模型主要由“输入数据量 * 复杂度”组成,其中“复杂度”是一个简单的阶梯表,完全取决于用户计算作业的难易程度。(更多参考 http://wangleheng.com/2014/07/odps_meter_money/

  几乎同时,谷歌公司推出了同类产品Google BigQuery,计费方案和我们几乎一样。他们甚至在官网上贴了一篇BLOG,详细描述了计量计费模型的“设计哲学”。大家彼此完全独立思考,得出的方法论和最终模型却殊途同归,这很有趣。

  总而言之,无论是复杂云服务、电子商务平台……都需要谨慎设计利益策略:尽可能简化规则,保证统计公平性,对“好事”建立正反馈。必要时,不妨参考经典电信服务的计量计费策略。

Google投资基因组数据服务

  这两天生化和生物信息领域的人很兴奋,因为Google对DNAnexus的投资。

  DNAnexus刚刚在A轮融资中获得1500万美元投资,投资方包括Google Ventures。除了资金,Google还将利用自身基础设施,如Google Cloud Storage,对DNAnexus提供技术支持。美国政府因为预算吃紧即将关闭NCBI,所以DNAnexus的DNA数据云服务今后有望成为生物科研的基础。

  回顾一下:

  十年前人类基因组计划完成,多国科学家利用了几亿美元,花费数年才完成了一个人的DNA测序;

  六年前,中国第一个商用案例,某位匿名亿万富翁花了一千万RMB给自己测序;

  四年前,Google联合创始人之一在自己妻子创立的23andMe公司内接受基因测序,被预测出帕金森症高危,因此大笔捐助研究这种疾病的基金会,此时23andMe已推出了免费测序服务(当然你要接受自己的DNA隐私被出售,以及随之而来的各种医疗服务的恐惧营销);

  而到了今年夏天,在55BBS孕宝亲子版上,北京的孕妇们开始热烈讨论购买华大基因的DNA测序服务以进行唐氏儿筛查。1500元的推广价当然还高于成本,但按照目前基因测序技术的发展速度(大大超过了摩尔定律),其成本很快就会降到普通人可以接受的范围,成为普通医院的标配。

每个基因组(人)的测序成本 - 来自NHGRI

  随着测序技术的进步,如何对接近10T的基因深度测序原始数据进行分析就成了问题。总不能让每个病人都拿着10T的硬盘到医院的集群上现算吧。云服务是合乎逻辑的方式。所以生物信息领域的人,等待Google等互联网巨头的进入,已经有好几年了。

  一直在期待领域Killer Application的出现,也一直在讨论“云计算+生物”的技术细节,让暴风雨来得更猛烈些吧。