用 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 以内。

 

用 AWS 构建高性能 Appflood 广告服务》上有6条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注