1. 互联网应用服务扩展的一点经验-- 以FreeWheel 核心系统演化为例 王迪 Di Wang dwang@freewheel.tv MSN: wangdieda@hotmail.com

2. 议程 我们的主要工作 FreeWheel MRM系统架构 过去三年的服务扩展实践 应用服务扩展实践 数据扩展实践 运营原则 关于FreeWheel

4. 为什么做这件事—why? 广告是在线视频的主要盈利方式 版权保护是视频行业的核心问题 （尤其在美国） 传统媒体商拥有优质内容和广告资源，缺少传播渠道 – 供给 视频网站拥有流量，需要内容吸引用户，以广告盈利 – 需求 FW作为独立第三方应用服务有效调剂需求与供给，提供客观测量，可为用户挖掘更多视频广告价值。 美国视频广告市场价值10亿美元 来源: IAB Internet Advertising Report 2009 国内视频广告市场价值14亿人民币 来源: iResearch 2010.04 Summit

5. 产品服务Monetization Rights Management – MRM Syndication Video Economy TV Everywhere

6. 产品应用示例

7. 如何实现？——互联网广告服务系统组成 Web前端——B2B应用, Ruby on Rails 后台核心系统 广告服务器: 高性能/高可靠 分布集群，C++/Python/Lua 日志收集处理分析ETL: 高吞吐量/及时, C++/Python 预测系统: 高吞吐量/运算密集/支持多并发, Erlang/C++ 视频播放整合 Flash SDK Silverlight SDK Javascript SDK iPhone/iPad app …

8. FreeWheel MRM系统整体架构

9. 需求难点分析 商业模式决定设计方案： 互联网服务的规模经济和沉淀成本 流量价值高于扩展成本才有意义，运营成本往往占一半以上！ 云计算 vs自运营的选择 B2B与B2C的不同： Web UI访问较少，后台服务压力较大 商业逻辑复杂：亿级用户访问，数百万video/page，数十万广告创意，数万内容公司，数千家视频网站的广告选择匹配。 服务的高可靠性：99.99% uptime，<300ms latency 峰值比预留：5:1 Peak to Mean. 数据驱动为中心：完整性，实时性，多用户隔离，可扩展 商业客户议价能力强，需大量服务支持工具。

10. 我们的一些经验和原则 应用服务扩展 无状态应用服务器 复制与多层次Cache 数据仓库扩展 De-normalization/Pivot Roll up/Data Availability Benchmarking与查询优化 Split-Loading/Sharding 运营原则 50% 运行负载上限 & N+1 Data Center 监控与响应 多阶段部署

11. 无状态广告服务器 Embed Lighttpd: 消除fastcgi进程间网络通信，方便部署。 交易状态相关信息编码URL，消除服务器间通信依赖。 例如： http://bd0dc.v.fwmrm.net/ad/l/1?last=1&metr=127&s=b004&t=12736523773101485&adid=145307&arid=0&reid=70701&auid=&cn=defaultImpression&et=i&_cc=145307,70701,,,1273652377,1&tpos=0&iw=&uxnw=&uxss=&uxct=&init=0&cr= s – 服务器ID t – 交易GUID adid – 广告ID

12. 无状态应用服务器 (Case Demo) 服务器间信息交换，通过定时反馈同步 应用服务重启/运行不依赖于其他应用程序 Load Balancer Ads1 Ads2 AdsN ……. Log Log Log Feedback Backend

13. 复制与多层次Cache 广告服务器的核心功能：将OLTP中用户预定的广告定位条件与当前视频请求做最佳匹配。 满足性能和高可用要求，实现了四点cache机制： Pusher Regular Push Quick Push Memcache Dot Server

14. Regular Push Why 分离数据库变动对广告服务器的影响，减少直接数据库访问 What 每个数据中心一台Slave，运行一个Pusher，Pull from DB，预处理和数据准备， “mmap” structured memory dump。 Read DB->Prep Data->Dump Repo->Sync Repo-> Reload Repo->Switch Gen/Sync twice per hour，2.9 G/Dump Master->Slave读写分离复制需要注意的方面 避免Master“长”写锁block Slave读锁 减少用trigger和procedure实现业务逻辑

15. Quick Push Why 部分服务数据对时效性要求高，要求更新小于半小时。 What Pusher 单独生成只包含时效敏感数据的小mmap, 每隔15分钟生成并同步到各服务器一次， 400 Mb/Dump。 需要调度与正常Push错峰带宽使用

16. Memcache Why 为响应实时直播视频信息快速上传同步和广告服务的要求 What 收到服务请求，内存查找 If 命中，请求返回 Else 查找memcache If cache命中，请求返回；同时item添加到内存中 Else if cache正在被创建，返回。 Else cache内容缺失，返回；启动异步OLTP查找 If DB命中，item同时添加到cache和内存中 Else DB缺失，item placeholder添加到cache中，设置过期

17. Ad Request come in. Look up video from RAM. 3". Video in mem, return response 3. Video not it mem, redirect to /ax/ interface Async look up video from cache. 5,6: Query memcached for Video. the result might be: a).NULL, b). Hit but data is loading by some adserver c). Hit and data available 7". Return response. 7. if cache missing, then return. 8. Set Video with status = loading 9. Invoke a thread fetch video from oltp DB. 10, 11. Query video and ge result from DB 12,13. Set Video with status = available and data in both cache and mem.

18. Dot Server Why Adserver高可用性保护方案以应对突发峰值和Bug down机. 触发Down机的bug往往会中断全部应用服务器 What 服务器内维持一个待服务请求队列, 当排队请求超过阈值 或由某用户请求触发特定Bug，导致机群相继Down机 后续请求转到一个无逻辑的Server Farm，并返回一个cache的无广告标准输出. 最大可能避免对外服务失效

19. 无状态日志处理 日志处理设计的主要考虑因素: 减少日志体积，容易扩展，避免自己定义格式和写Parser Text Log -> Binary log by Google Protocol buffer 用较少的机器达到较高吞吐量：理想情况下接近磁盘I/O 日志收集分区，一个Node只处理固定一组广告服务器日志 尽量减少日志中需要交换处理的内容 MapReduce由Hadoop/Java 转C++ Aggregation由Python转C++ 重处理：中断后，容易从头开始，避免人工接续处理 无状态设计的关键： 日志条目自身应包含交易所有现场和Callback的必要信息 不变的Meta Data通过Pusher从OLTP中提取

21. 现成Parser

23. Normalization 优点： Fact 表精简，数据无冗余 缺点： 当业务逻辑复杂时，查询可能变得很复杂，需多次Join。 当需要按照某个dimension ID做Group by时不能有效利用fact表索引，尤其当Fact表数据量较大时，性能难以接受。

24. De-Normalization 优点： Star Schema，将复杂逻辑放到外部程序，而使得SQL逻辑简单，fact表不增加行，查询性能较好。 标准BI工具建模容易。 缺点： Fact表增加了冗余列和存储（查询性能主要与行数相关）

25. Pivot 优点： 通过转秩(Pivot)，使原来分布在fact表中相同Key组合的多行数据合并到一行，减少了行数，使SQL更加简单，提高查询性能。在大数据量时收益明显。 缺点： fact表单条记录增加了列；需开发程序完成转秩。

26. Long tail roll up & Data Availability 一个简单的计算: 100,000 video X 100 site X 100 Country X 1,000 Ad = 1,000,000,000,000 行/天，Impossible! 互联网视频的访问热度呈现典型“长尾”分布 5%的热门视频占有50%的流量 在所有视频上统计所有维度/粒度的指标，ROI太低 Long Tail Roll up 对单日小于某一阈值流量的video在DB中roll up成一个item 创建Long tail表单独对长尾视频做粗粒度统计 Data Availability 对不需要某些粒度指标的客户不统计相关维度 产品功能设计需谨慎，一旦发布很难收回，从而带来维护负担

27. Benchmarking与查询优化 自动Benchmark所有查询 使用Production数据 自动check out SQL运行 提取MySQL Slow Query log测量值，多次测量平均 月度评审，选择top slow query优化 查询优化 Schema设计应尽量让SQL简单，复杂逻辑放到应用程序 正确建立和使用必要的索引 InnoDB buffer设置，70%机器内存 参考：《高性能MySQL》(第二版) http://www.mysqlperformanceblog.com/

28. Benchmarking (Case Demo) Internal Benchmark Tool Benchmark Report w queries run longer than 10 min

29. Partition and Sharding 做完上述优化以后的选择 Table Partition: 选择event_date作为Key 以Partition为单位增、删数据仓库表，几乎不用Update Sharding的收益: 容易为新客户扩展 限制错误影响范围 客户数据相对隔离，更容易添加新DB 避免单点故障 可并行Load数据，提高发布效率 Sharding的代价： 增加硬件、架构和监控的复杂性

30. DB Volume Increase Trendline Before Sharding 29

32. Impossible to do migration and reprocess!

33. Hard to scale!30

34. Sharding Architecture 31 Client Facing End Shard 2 Shard 3 Shard 1 Huge DB

35. 基于Sharding下的ETL流程演示 32 Client Facing End 服务中 X X X X X X 脱离服务 加载数据.. ETL

36. 运营原则——50% 上限 & N+1 Data Center 所有子系统做容量扩展规划时，预估上限以50%负载（经验值）为限。 Adserver为峰值预留50%容量，e.g突发新闻，世界杯决赛 后台日志处理在用户要求的数据发布时间50%内完成，有机会应对意外出错重做一遍。 业务量上涨导致系统平均负载>50%，扩容的信号！ N+1 Data Center 数据中心不同地理位置分布 备用ISP，备用CDN 保证一个DC由于意外服务中断，其他N个可正常负载服务。

37. 监控与响应 监控分类： 应用服务Check Live 服务异常警报：错误，延时等 数据库Master-Slave同步 Cache有效性：Quick Push 端到端数据一致性检验：模拟用户行为 Slow Query日报 当日业务运营情况日报 响应： 优先级: P1/P2/P3 7x24 On-Call Rotation

38. 示例：应用服务Check Live日报 示例：数据一致性监控报警

39. 多阶段部署 正式上线前Staging部署 一个按比例构建的模拟生产环境，包括所有类型应用服务 拓扑结构与生产环境相同 使用生产环境的数据库数据和真实用户请求采用模拟 可充当集成测试环境 生产环境分阶段部署 降低因升级造成服务中断的风险 将集群分组，分批分时升级 兼容性挑战 Rollback计划

40. 关于测试的一点话题 以自动化回归测试为核心 并未使用TDD单元测试 坚持Local测试->集成测试->回归测试->Staging 每次升级发布前的测试检查清单 New Feature Function Test UI/Core/VI Integration Test Regression Case Suite Memory Leak Check Performance Test Compatible Test Post Release Live Check

41. 关于测试（回归测试系统 Demo）

42. 系统演化路线图 第一阶段：2007年12月 – 2008年6月 目标：上线，验证服务可用性 扩展工作：Push/Quick Push，监控，日志处理架构 集群规模：20台广告服务器，4ETL, 4 预测，3 OLTP, 1 OLAP. 业务量：日均几万至几十万次访问，日志量<1G/天 第二阶段：2008年6月--2009年9月 目标：扩展服务客户，数据仓库调优 扩展方面的主要工作：memcache，Binarylog，数据仓库Denormalize/Pivot/Partition/Benchmarking 集群规模：+20 广告服务器，+2 MemcacheD，+2ETL, +2预测，+1 OLAP。 业务量：日均几百万次访问，日志量约10G/天

43. 当前运营情况 第三阶段：2009年10月--至今 目标：支持大客户，运营友好 扩展工作：DB Sharding，Dot Server, 多阶段部署 集群规模： 广告服务器：60台，日均服务视频广告请求5000万次，广告投放量约1亿次，5%负载。 后台日志处理：8台，日均4小时处理日志200G，20%负载 预测系统：6台，日均4小时模拟500万请求，20%负载 数据仓库：日新增约1000万条记录~10G存储，1T/Shard

44. 2009.5-2010.3间流量增长20倍! 服务流量趋势和可用性 Service Level Agreement (SLA) >= 99.99%

45. 关于分布式系统和Web服务扩展相关链接 Blogs NatiShalom's Blog: Discussions about middleware and distributed technologieshttp://natishalom.typepad.com/nati_shaloms_blog/ All Things Distributed: Werner Vogels' weblog on building scalable and robust distributed systems.http://www.allthingsdistributed.com/ High Scalability: Building bigger, faster, more reliable websiteshttp://highscalability.com/ ProductionScale: Information Technology, Scalability, Technology Operations, and Cloud Computinghttp://www.productionscale.com/ iamcal.comhttp://www.iamcal.com/ (the "talks" section is particularly interesting) Kitchen Soap: Thoughts on capacity planning and web operationshttp://www.kitchensoap.com/ MySQL Performance Blog: Everything about MySQL Performancehttp://www.mysqlperformanceblog.com/

46. Presentations Scalable Internet Architectureshttp://www.slideshare.net/shiflett/scalable-internet-architectures How to build the Webhttp://www.slideshare.net/simon/how-to-build-the-web Netlog: What we learned about scalability & high availabilityhttp://www.slideshare.net/folke/netlog-what-we-learned-about-scalability-high-availability-430211 Database Sharding at Netloghttp://www.slideshare.net/oemebamo/database-sharding-at-netlog-presentation MySQL 2007 Techn At Digg V3http://www.slideshare.net/epee/mysql-2007-tech-at-digg-v3 Flickr and PHPhttp://www.slideshare.net/coolpics/flickr-44054 Scalable Web Architectures: Common Patterns and Approacheshttp://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches How to scale your web apphttp://www.slideshare.net/Georgio_1999/how-to-scale-your-web-app Google Cluster Innardshttp://www.slideshare.net/ultradvorka/google-cluster-innards Sharding Architectureshttp://www.slideshare.net/guest0e6d5e/sharding-architectures

47. 关于FreeWhel FreeWheel是目前全美领先的互联网数字视频广告管理和增值服务提供商，创始人团队由前DoubleClick高管组成，在美国网络广告界拥有多年市场、产品、技术和管理方面的资深经验。 公司创立于2007年，由Battery Ventures和Foundation Venture投资，并于2010年3月完成第三轮1680万美元注资，引入迪斯尼Steamboat Venture和特纳广播公司（Turner）作为战略投资人。 公司专注于为大型媒体公司和互联网视频网站提供视频广告管理系统与增值服务，现有客户包括ESPN,华纳, CBS, Discovery, CNBC, CNN.com, NBA.com, ESPN.com, MLB.com, Veoh.com, Vevo.com等，月度广告业务服务量约20亿次，并仍在快速增长。 FreeWheel目前在硅谷、纽约和北京设有机构，其中北京研发中心担负全部的产品研发工作，包括核心广告系统、Web应用以及视频设备整合等。

48. FreeWheel北京工程师团队

49. 谢谢大家！ Q&A