再跟 Flickr 学习网站运维经验
学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。
现在 Flickr 的数据相比2007年的时候真是有了显著的增长：
- 24 TB 的 MySQL 数据
- 每秒钟 MySQL 有 3.2 万次写操作
- 每秒钟 MySQL 有 12万次读操作
- 图片容量 6 PB
- 每天要用掉 10TB 存储
- 超过 15000 个服务监控点
在 2004 年的时候 ，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。
除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手"裁"掉机器，也会省钱嘛...
Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：
- 使得机器自动构建 (Teach machines to build themselves)
- 使得机器自监控(Teach machines to watch themselves)
- 使得机器自修复(Teach machines to fix themselves)
- 通过流程减少 MTTR (Reduce MTTR by streamlining)
自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。
Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 ... "信息查找"，是国内多数团队交流工具忽视的地方。
最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。
作者: Fenng
- Flickr 的开发者的 Web 应用优化技巧 - 2007年12月26日 12:12
- 探索Google App Engine背后的奥秘(2)--Google的整体架构猜想 - 06月10日 20:26
- 探索Google App Engine背后的奥秘(1)--Google的核心技术 - 06月10日 20:00
- 读书 - 实战Nginx：取代Apache的高性能Web服务器 - 04月24日 00:16
- 读书 - 高性能MySQL（第二版） - 04月15日 20:43
- PC 服务器的 RAS 能力 - 04月11日 20:04
- 多IDC的数据分布设计(二) - 04月11日 20:37
- flickr对javascript干的好事 - 04月03日 19:30
- FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务 - 03月09日 09:57
- Five Minutes程延辉 介绍开心农场架构 - 03月09日 09:48
