What Powers Instagram: Hundreds of Instances, Dozens of Technologies(译文，转)

add by zhj:

对译文略有修改。原文发表时，Instagram还没被Facebook收购，读完只感觉Instagram这三个后台工程师真牛逼。

三个人就可以搞定1400万注册用户。不过，另一方面，我们也看到，这三个人其实使用的都是现成的技术，至少从文章中看不出他

们有什么技术上的创新，当然就三个人搞创新也难了点，而且如果现有技术能基本上解决问题，对这样一个小团队而言，就没必要

自己开发新技术。最后，对他们愿意把方案分享出来表示非常感谢。

该文章写的比较早了，所以有些技术已经进行了更新，比如到2013年时，Instagram已经不再使用gearman，而改为Celery+Rabbitmq，参见

他们在PyCon 2013上的演讲PPT，messaging-at-scale-at-instagram。

英文原文：http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of

译文：http://www.cnblogs.com/xiekeli/archive/2012/05/23/2514108.html

当我们与其他工程师偶遇和交流的时候，有一个问题经常被问及，“你们的技术架构（technology stack）是怎么样的”？我们觉得从较高的层次来描述Instagram的所有构成系统是一件有趣的事情；未来你可以期待更深入的描述这些系统。这就是我们的系统，仅仅1年时间，并且我们活了下来，其中有一部分我们一直在修改。一个小型团队的初创公司，可以在一年多一点时间发展到1400多万用户规模。我们选择一种技术的核心原则是：

尽量保持简单
不重复发明轮子
尽量用被验证的可靠的技术

我们将自顶向下进行介绍：

操作系统 / 主机

我们在亚马逊的 EC2上跑Ubuntu Linux 11.04 (“Natty Narwhal”)。我们发现之前的版本在EC2上高流量的时候都会出现各种不可预测的问题（ freezing episodes），但11.04已经稳定了。我们只有3名工程师，我们的需求依然在不断的变化中，因此自托管主机不是我们的选择，也许未来当用户量空前增长的时候，我们会考虑。

负载均衡

每一个对Instagram 服务器的访问都会通过负载均衡服务器；我们使用2台nginx机器做DNS轮询。这种方案的缺点是当其中一台退役时，需要花时间更新DNS。最近，我们转而使用亚马逊的弹性负载均衡器，使用3个NGINX 实例可以实现调入调出（如果有哪个NGINX健康检查失败，则自动剔除）；我们同时在 ELB 层停掉了 SSL , 以缓解nginx的 CPU 压力。我们使用亚马逊的Route53作为DNS，他们最近在AWS控制台上为Route53增加了一个很好的GUI工具。

应用服务器

接下来是应用服务器用来处理我们的请求。我们在亚马逊的High-CPU Extra-Large机器上运行了Django ，随着使用量的增长，我们已经在25台主机上跑Django实例了（幸运地，因为是无状态的，所以非常便于水平扩展）。我们发现我们的特定工作负载是属于CPU bound而不是memory bound，因此High-CPU Extra-Large类型的实例刚好提供了合适的比重（CPU和内存）。

我们使用 http://gunicorn.org/ 作为我们的WSGI服务器；我们曾经使用mod_wsgi 和Apache，但是发现Gunicorn 更容易配置，且对CPU的要求更低。为了一次在多个实例上执行命令（像部署代码），我们使用Fabric，Fabric最近增加了并行模式，因此部署只需要花费几秒钟。

数据存储

我们大部分数据（用户信息，照片的元数据、标签等）存储在PostgreSQL中；我们之前已经说了关于如何基于不同的Postgres 实例进行切分的。我们的主要分片集群包含12个Quadruple Extra-Large内存云主机（每个都有副本，且主副在不同区域）；

我们发现亚马逊的网络磁盘系统（EBS）每秒的寻道能力不够，因此，将我们所有工作集放在内存中就变得尤为重要。为了获得合理的性能，创建了软 RAID 以提升 IO 能力，使用的 Mdadm 工具进行 RAID 管理；

顺便提一下，我们发现vmtouch用来管理内存数据是个极好的工具，尤其是在故障转移时，从一台机器到另一台机器，甚至没有活动的内存概要文件的情况。这里是脚本，用来解析运行于一台机器上的vmtouch 输出并打印出相应vmtouch命令，在另一台机器上执行，用于匹配他当前的内存状态；

我们所有的PostgreSQL实例都是运行于主-备模式，基于流复制，并且我们使用EBS快照经常备份我们的系统。为了保证我们的快照的一致性（原始灵感来源于ec2-consistent-snapshot）我们使用XFS作为我们的文件系统，通过XFS，当进行快照时，我们可以冻结&解冻RAID阵列。为了进行流复制，我们最爱的工具是repmgr 。

对于从我们的应用服务器连接到数据，我们很早就使用了Pgbouncer做连接池，此举对性能有巨大的影响。我们发现Christophe Pettus的博客有大量的关于Django、PostgreSQL 和Pgbouncer 秘诀的资源。

照片直接存储在Amazon S3，当前已经存储了几T的照片数据。我们使用亚马逊的CloudFront 作为我们的CDN，这加快了全世界用户的照片加载时间（像日本，我们第二最受欢迎的国家）

我们也广泛的使用了Redis ；我们的main feed、activity feed、sessions系统（这里是我们的Django session backend），和其他相关系统都使用了Redis。因为所有的Redis数据都需要放在内存中，因此我们最后使用了几个Quadruple Extra-Large Memory云主机用于跑Redis。我们的Redis也是运行于主-备模式，并且经常将DB保存到磁盘，最后使用EBS快照备份这些数据（我们发现在主机上进行导出太费劲了）。由于Redis 允许写入备份，使得在线故障转移非常方便，转移到一台新的Redis 机器，而不需要停机。

对于我们的geo-search API，我们一直使用PostgreSQL了很多个月，不过后来迁移到了Apache Solr.他有一套简单的JSON接口，这样我们的应用程序相关的，只是另一套API而已。

最后，和任何现代Web服务一样，我们使用了Memcached 做缓存，并且当前已经使用了6个Memcached 实例，我们使用pylibmc & libmemcached进行连接。亚马逊最近发布了一个弹性缓存服务，但是它并不比运行我们自己的实例便宜，因此我们还没有切换上去；

任务队列&推送通知

当一个用户决定分享一张Instagram 的照片到Twitter 或Facebook，或者是当我们需要通知一个实时订阅者有一张新的照片贴出，我们将这个任务推到 Gearman，一个任务队列系统。通过任务队列异步执行意味着媒体上传可以很快完成（即发一条instagram很快），而“重担”可以在后台运行。我们大约有200个消费者（都用Python写的），它们消费队列中的任务。我们的feed fan-out也使用了Gearman，这样posting就会响应新用户，因为他有很多followers。

对于消息推送，我们找到的最划算的方案是https://github.com/samuraisam/pyapns，一个开源的Twisted 服务，已经为我们处理了超过10亿条通知，并且绝对可靠。

监视

对于100多个实例，监控变得非常重要。我们使用Munin进行图形化度量，如果有什么超出了正常范围，那会提醒我们。我们基于 Python-Munin,也写了很多Munin 插件。用于图形化度量非系统级的东西（例如，每分钟的签入人数，每条照片发布数等）我们使用Pingdom作为外部监控服务，PagerDuty 用于处理通知和事件。

对于Python错误报告，我们使用Sentry，它是由Disqus的工程师们写的，是一个极好的开源的Django app。在任何时间，我们可以实时的查看系统发生了什么错误。

是你吗？

如果你对我们系统的这篇描述感兴趣，或者你正跃跃欲试的想告诉我们关于系统你有什么不同的见解，我们都静候佳音。We’re looking for a DevOps person to join us and help us tame our EC2 instance herd.

巴特西