Instagram 团队上个月才迎来第7名员工,是的,7个人的团队。作为iPhone上最火爆的图片类工具,instagram用户数量已经超过1400万,图片数量超过1.5亿张。不得不说,这真他妈是个业界奇迹。
几天前,只有三个人的Instagram工程师团队发布了一篇文章:What Powers Instagram: Hundreds of Instances, Dozens of Technologies,披露了Instagram架构的一些信息,足够勾起大多数人的好奇心。读罢做点笔记,各种线索还是有一定参考价值的。能打开原文的建议直接读原文。
Instagram开发团队奉行的三个核心原则:
- Keep it very simple (极简主义)
- Don't re-invent the wheel (不重复发明轮子)
- Go with proven and solid technologies when you can(能用就用靠谱的技术)
OS/主机
操作系统的选择,在Amazon EC2上跑Ubuntu Linux 11.04 (Natty Narwhal),这个版本经过验证在EC2上够稳定。因为只有三名工程师,只有三名工程师,所以自己部署机器到IDC是不靠谱的事情。幸好有亚马逊。
负载均衡
此前曾用过两台Nginx做DNS轮询承载前端请求,这样做会有副作用,现在已经迁移到Amazon的ELB(Elastic Load Balancer),起了三个Nginx实例,在ELB层停掉了SSL ,以缓解CPU压力。DNS服务使用Amazon
Route53服务。
应用服务器
启用了25个Django实例,运行在High-CPU Extra-Large类型的服务器实例上,之所以用High-CPU Extra-Large实例是因为应用请求是CPU密集型而非IO密集型。
使用 Gunicorn 作为WSGI服务器。过去曾用过Apache下的mod_wsgi模块,不过发现Gunicorn更容易配置并且节省CPU资源。使用 Fabric 加速部署。
数据存储
用户信息、图片元数据、标签等大部分数据存储在PostgreSQL中。主要的Shard数据库集群有12个节点。
实践中发现Amazon的网络磁盘系统单位时间内寻道能力不行,所以有必要将数据尽量放到内存中。创建了软RAID以提升IO能力,使用的 Mdadm 工具进行RAID管理。
管理内存中的数据,vmtouch 这个小工具值得推荐。
PostgreSQL设置为Master-Replica方式,流复制模式。利用EBS的快照进行数据库备份。使用XFS文件系统,以便和快照服务充分配合。使用 repmgr 这个小工具做PostgreSQL复制管理器器。
连接池管理,用了 Pgbouncer。Christophe
Pettus 的文章包含了不少 PostgreSQL 数据库的信息。
TB级别的海量图片存储在Amazon S3上,CDN采用的也是Amazon的服务,CloudFront。
Instagram也是Redis的重度用户,Feed以及Session信息都用Redis处理,Redis也是以Master-Replica方式部署。在Replica节点上进行数据备份。
使用了Apache Solr承担Geo-search API的工作,Solr简单的JSON接口也不错。
缓存使用了6个Memcached实例,库使用pylibmc和libmemcached。亚马逊也提供缓存服务-Elastic Cache service,Instagram也有尝试,不过不便宜。
任务队列/发布通知
队列服务使用 Gearman ,通知系统则使用 pyapns 来实现。
监控
前面提及的服务器实例数量加起来,的确有100多个,有效的监控是相当有必要的。使用Munin作为主要监控工具,也写了不少定制插件,外部监控用 Pingdom 的服务。通知服务使用 PagerDuty。
对于Python的错误报告,使用Disqus团队开源的 Sentry 来处理。
几个感想
0)轻装上阵说起来容易,做起来非常难。这也是Instagram团队目前最令人着迷的地方;
1)Python社区已经足够成熟,各个环节上都已经有不错的解决方案了。
2)如果要问我最大的一个感慨,我要说:Amazon真是一家伟大的公司,甚至比Google还伟大。