了解Instagram背后的技术

  刚被 Facebook 以 10 亿美金收购的著名手机照片分享应用 Instagram 最近吸引了无数人的眼球,Android 版本登陆 Google Play 不到一个月下载量就突破 1000 万,总用户数即将超过 5000 万。Instagram 联合创始人 Mike Krieger 说他们用了 8 周时间打造了最初的 Instagram,但现在的系统肯定已经今非昔比。Instagram 技术团队曾发表过一篇文章,介绍了 Instagram 背后的技术,日前 Mike Krieger 在名为 Scaling Instagram 的演讲里,又介绍了更多细节,让人们能了解到 5 名技术人员是如何支撑起整个系统的。

  一张照片上传的过程是这样的:

  1. 采用同步的方式写入媒体数据库
  2. 如果照片上有地理位置标签,则以异步的方式将照片提交给 Solr 进行索引
  3. 将照片的 ID 加入每个关注者的列表里,该列表保存在 Redis 之中
  4. 在显示 Feed 时,选取一小部分照片 ID,在 Memcached 里进行查询

  在设计系统时,Instagram 的设计哲学是简单、为最小化运维负担进行优化并监控一切内容;其核心原则是保持简单,不要重复发明轮子,尽可能使用经过验证、稳定可靠的技术。

  由于只有 5 名技术人员(其中仅2.5名后端工程师),精力有限,选择 Amazon 的云服务是个不错的选择。目前他们使用了超过 100 个EC2实例用于提供各种服务,运行的操作系统是 Ubuntu 11.04,之前的一些版本在高流量时表现不够稳定。在负载均衡方面,他们使用 Amazon 的Elastic Load Balancer实现负载均衡,后端运行了 3 个 Nginx 实例,SSL 只到 ELB 上为止,降低了 Nginx 上的 CPU 负载。DNS 和 CDN 分别由 Amazon 的Route 53CloudFront提供,所有的照片都存放在S3上,目前已经有几 TB 的规模了。

  用于处理请求的应用服务器运行于Amazon High-CPU Extra-Large Instance之上,由于他们的请求更多是 CPU 密集型的,因此这能更好地平衡 CPU 与内存。采用的开发框架是 Django,WSGI 服务器是 Gunicorn,通过 Fabric 在所有机器上进行并行部署,一次部署仅需几秒钟。

  大多数数据都存放在 PostgreSQL 里,主分片集群运行于 12 个High-Memory Quadruple Extra-Large Instance(68.4GB 内存)上,另有 12 个位于不同可用区里的副本,通过 repmgr 以 Streaming Replication 的方式进行同步。由于Elastic Block Store的磁盘 IOPS 不高,因此需要将正在使用的数据都加载到内存里,vmtouch 能帮助管理内存中的数据。他们在 EBS 上使用 mdadm 实现了软件 Raid,以此提升写吞吐量;数据库的文件系统用的是 XFS,在从库获取快照时,会先冻结 RAID 阵列,保证快照的一致性。

  应用程序在连接数据库时,由 Pgbouncer 建立连接池。目前,Instagram 的数据按照用户 ID 进行分片,某些分片可能会超出物理节点的容量上限,为此他们将数据分成了很多个逻辑分片,映射到少数几个物理节点之上;当一个节点被填满之后,可以将某些逻辑分片移到别的节点上,以缓解该节点的压力。随着数据量的增长,以后他们也会进行垂直分区,Django DB Router 能让一切轻松不少。

  Instagram 也大量使用 Redis 来存放复杂的对象(对象的大小做了一定的限制),用于主 Feed、活动 Feed、会话系统及其他相关系统。因为要将 Redis 的所有数据都放在内存里,此处同样也用了High-Memory Quadruple Extra-Large Instance,并对数据做了分片。当 Redis 实例的请求达到 4 万/秒后,它渐渐成为了瓶颈,于是 Redis 也做了主从复制,副本的数据会经常导出到磁盘上,通过 EBS 快照进行备份。

  除了 Redis,他们还使用 Memcached 来做缓存,目前运行了 6 个实例,应用服务器通过 pylibmc 和 libmemcached 进行连接。虽然 Amazon 提供了 Elastic Cache 服务,但该服务的价格并不便宜,相比之下,还是运行自己的 Memcached 实例比较划算。异步任务队列使用的是 Gearman,目前有大约 200 个工作进程来处理各种任务,比如把照片分享到 Twitter 和 Facebook,通知用户有新照片等等。Pyapns 已经处理了十亿的推送通知,非常稳定,他们还自己开发了基于 Node.js 的 node2dm,用于向 Android 设备发送推送通知。

  监控方面,Instagram 使用 Munin 以图形化的方式呈现整个系统的运行状况,还通过 Python-Munin 定制了一些插件,用来显示业务数据;网络守护进程 Stated 可以实时收集数据并做汇总;Dogslow 会监控进程,一旦发现运行时间过长的进程,便会保存该进程的快照,以便后续分析,比如响应时间超过1.5秒的请求,通常都是卡在 Memcached 的 set ()和 get_many ()方法上。对于 Python 的错误,只要登上 Sentry 就能实时获取错误信息。

  HighScalability 上还根据整理 Mike Krieger 的演讲整理了一些值得借鉴的经验,比如:

  • 找那些你熟悉的技术和工具,在简单的使用场景里先做一些尝试
  • 不要使用两个工具来处理同样的任务
  • 事先准备降级方案,以便在需要时降低负载
  • 不要过度优化,或者希望能事先知道站点要扩展,对于一个初创的社交站点而言,没什么扩展性问题是解决不了的
  • 如果一个办法不行,赶快换下一个

  如果您想进一步了解 Instagram 背后的技术细节,可以访问其技术团队的博客。

你可能感兴趣的:(Instagram)