标签归档:AWS

云服务为什么会是未来?

今天在交流时候有记者问过我,使用云服务主要还是成本的考虑吗?是的。和传统服务相比,云服务实际上没有哪一点是完全不可替代的。而成本恰恰是小团队最关心的一个问题,时间成本、人力成本、以及最直接的机时售价价格,这些问题累积在一起,才是做为初创公司选择云服务的所有理由。

 

英国经济学家杰文斯曾经在《煤矿问题》中指出一个看似互相矛盾的问题:对蒸汽机性能的改进提高了煤炭的能源转化率,用更少的煤可以产生更多的能源了,而能源的价格降低往往又导致了煤矿的消费量增加。这种现象被称为杰文斯悖论,既:对资源的利用率降低了资源的价格,最终会增加资源的使用量。在云计算领域,该悖论也非常的适用,云服务大大改进了计算资源的利用率,改进的方式包括:更简单的获取计算资源的方式,以及将闲置计算资源更好的释放出来。当开关服务器就和开关水龙头一样便捷之后,公司以及个人对服务器资源的需求会大大的增加。

举个切身体会到的例子。曾几何时,公司弄一台线上服务器是如此的困难。早先我们需要首先买一台服务器,然后找个机房托管,签完各种合同,交完押金和钱,将庞大的机器搬到机房里的某个机柜,插好各种线,终于可以接入互联网开始服务了。再然后有了服务器租赁业务,依然会比较麻烦,填完合同之后,大概需要2-3天不等,机器才能准备好。在如今云服务提供的便利之下,5分钟可以开一台服务器,用完即关。

对于传统互联网公司来说,一方面,在计算资源获取困难的时候,一个项目或者一个新计划只能压缩到有服务器的时候才能开展,而根据流量动态调节服务器响应能力变得几乎不可能。另一方面,在计算资源过剩的时候,闲置在那里的服务器资源对于能源的浪费,简直是一件令人发指的事情。有一个听来的真实的笑话是这么说的,老板发现了公司服务器CPU闲置的非常厉害,让手下想办法。某公司手下用脚本检查CPU占用率,如果没满就写一个死循环占满。另一个公司觉得这样太直白了不太好,就暗示开发把代码写的烂一点,以占用更多的CPU让数字看上去好看些。对于大型互联网公司来说,目前每年都有无数的钱财和资源浪费在了闲置服务器上。

如果将传统服务器比作每天早上下山挑水喝,那么云服务就像是自来水入户,打开水龙头,水就流了出来,不用的时候,可以随时关上水龙头。既充分利用了资源,也没有造成资源浪费,把成本降到了最低。将计算能力分割成块然后当成自来水一样出售给大众,这无疑是大势所趋。在未来,任何一个普通学生想起一个复杂的算法,都可以经过简单的操作,然后开启100台服务器进行计算,最后在验证完算法之后关闭。云服务会真正像自来水一样走进千家万户。

有感而发写一点不那么务实的东东。

 

 

用 AWS 构建高性能 Appflood 广告服务

众所周知,广告业务是对服务器的性能考验最为严峻。首先广告业务的访问量十分巨大,动辄每秒成千上万的请求,其次广告业务对于实时性的要求非常之高,在 RTB 环境下要求请求延迟不超过100毫秒,而我们对自己的要求往往是请求延迟不超过20毫秒。

重新从底层搭建所有框架对于创业型公司来说是很不现实的。Key-Value DB、Cache、LoadBalancer、TaskQueue,这一切如果都用开源框架来搭建,无异于一场灾难。从易用性到健壮性,从 Availability 到 Scalability,开源框架往往都不能完整的满足所有。幸好亚马逊提供的 AWS 服务提供了完整的全套的解决方案。我们从中也学到了很多东西。

1. Colocation -> IaaS

早先公司自购的服务器并且用的美国公司的托管服务。后来发现对于创业公司来说,繁复的服务器维护工作简直是一场灾难。在09年左右卖掉了服务器,投靠了 AWS 的怀抱,开始全部用 IaaS 做为服务器平台。

说实话初期 AWS 的虚拟 Instance 很不好用。做为第一批吃螃蟹的用户来说,体验过各种奇葩的问题,比如 Instance 失去响应,Reboot失效等等。经过询问 AWS 工程师,给出的结论一般是:Linux内核问题、底层硬件坏了,或者就是他们也不知道原因。

不过虚拟 Instance 的好处也非常明显,就是开关很便捷。如果真的坏了而且也找不到原因就再开一台吧。AWS可以靠低价的Instance数量取胜。

2. Key-Value -> DynamoDB

公司早期我们就是Key-Value的狂热热爱者。在试用过Tokyo Tyrant,MongoDB,Riak等等服务之后,最后我们还是采用了 AWS 的 DynamoDB。Key-Value看似美好,但是其背后的维护人力成本也非常之高。在数据快速增长的时候,在节点出现意外的时候,在磁盘满了需要更换节点的时候,往往都是灾难发生的时候。虽然标榜具有很高的 Availability,但是往往需要开大量的冗余节点支撑,平时在不用的时候浪费很多的钱。在个别节点崩溃之后,剩余节点的负载又往往高居不下,很难调节。

最后我们试用了 DynamoDB,到目前为止感觉良好。无需自己考虑节点问题,无需考虑存储空间不够。唯一的问题可能就是无法做 Replica。当然这一问题也有其他办法可以解决。

3. TaskQueue -> SQS

对于读写分离的线上业务来说,TaskQueue 服务一般是必不可少的。早期我们自己搭建的TaskQueue Service,后台采用 Redis 做存储,也尝试过较为成熟的 RabbitMQ 等开源方案。一个经常遇到的比较严重的问题就是,存储满了怎么办。

相信所有 TaskQueue 系统最怕的就是存储满了怎么办,无论你的存储是在很大的内存里,还是在磁盘上,如果 Worker 不工作总会有满了的时候。突发流量增加导致后端 Worker 处理不过来,或者因为 Worker 的代码异常导致处理速度过慢。一般的 TaskQueue 系统遇到这种情况往往就是崩溃掉,丢失 Queue 里的所有任务。

对于 Queue 系统还有一样需要考虑的就是并发性。如果流量增长过快,需要考虑的是要增加更多 Queue Master节点,以及更多的 Worker 来处理。这些问题都需要大量人力来维护。

随后我们还是投靠了 SQS 服务。Master 的所有问题都交给了 AWS 来解决。偶尔遇上线上故障也会有积累几千万个任务的时候,但是不需要考虑存储和Master节点的可用性,一切都很平稳,数据也没有丢失过。使用 Autoscaling 也可以很好的实时增加 Worker 数量,保证任务处理可以跟得上。

唯一的缺点就是 SQS 的时序性稍差。当然这一点也可以在应用层加以处理,避免时序错乱问题。

4. OnDemand -> Spot

AWS 的 Instance 有 OnDemand 和 Spot 两种类别。区别在于 OnDemand 比较贵,Spot很便宜但是可能随时被关掉。然而实际上给一个很好的bid price,Spot是可以开很久很久的。通过做好现成的 AMI,然后用 Spot 方式动态启动服务器,可以将各个时段不均匀的访问导致的开销降到最低。比如定时在访问量最大的时候多开几台,然后在大家睡觉的时候再关掉。不管是什么服务器能提供多好的 Availability 和 Scalability,它的最关键的分母还是 Cost。使劲花钱用最豪华的配置搭一个稳定服务,只是看上去很美,所有人都会。而 Spot 可以让我们用最好的性价比,搭出优良的在线服务来。

最后

总之,AWS 使我们从后端的海量运维工作和底层框架搭建工作中解脱了出来,让我们有更多的精力处理上层业务逻辑和算法。另外,充分利用 Spot Instance 也使得我们的服务器成本非常的低廉。目前我们有 5台c1.xlarge做为广告服务的前端处理Web请求,5台m1.xlarge做为广告服务的Worker。除掉静态请求统统走 CDN CloudFront 之外,动态请求的平均响应延迟是 13毫秒,日均访问量是亿量级。服务器负载都在 <1 以内。