Image via CrunchBase
学习了一下 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 团队的精彩。
–EOF–