[Architecture]Instagram
# 设计哲学
简单、为最小化运维负担进行优化并监控一切内容;
# 核心原则
保持简单,不要重复发明轮子,尽可能使用经过验证、稳定可靠的技术
# Instagram的workflow
- 采用同步的方式写入媒体数据库
- 如果照片上有地理位置标签,则以异步的方式将照片提交给 Solr 进行索引
- 将照片的 ID 加入每个关注者的列表里,该列表保存在 Redis 之中
- 在显示 Feed 时,选取一小部分照片 ID,在 Memcached 里进行查询
# General
- Extensive Unit-tests and functional tests
- Keep it DRY
- Loose coupling using nifications/signals
- Do most of our work in Python, drop to C when necessary
- Frequent code reviews, pull requests to keep things in "shared brain"
- Extensive monitoring
# Architecture
- Amazon Web Service
- AWS EC2:Ubuntu 11.04
- Load Balance: Amazon Elastic Load Balancer;
后端运行3 个 Nginx 实例,SSL 只到 ELB 上为止,降低了 Nginx 上的 CPU 负载。
- DNS/CDN: Amazon Route 53 / CloudFront
- Pictore Storage: AWS S3
- DB: PostgreSQL
# Application Server
- AWS EC2: Amazon High-CPU Extra-Large Instance
- Web Framework: Django
- WSGI 服务器: Gunicorn
- 并行部署: Fabric
# Redis & Memcached
大量使用 Redis 来存放复杂的对象(对象的大小做了一定的限制),用于主 Feed、活动 Feed、会话系统及其他相关系统。因为要将 Redis 的所有数据都放在内存里,此处同样也用了High-Memory Quadruple Extra-Large Instance,并对数据做了分片。当 Redis 实例的请求达到 4 万/秒后,它渐渐成为了瓶颈,于是 Redis 也做了主从复制,副本的数据会经常导出到磁盘上,通过 EBS 快照进行备份。
除了 Redis,他们还使用 Memcached 来做缓存,目前运行了 6 个实例,应用服务器通过 pylibmc 和 libmemcached 进行连接。虽然 Amazon 提供了 Elastic Cache 服务,但该服务的价格并不便宜,相比之下,还是运行自己的 Memcached 实例比较划算.
# Task Queue
异步任务队列使用的是 Gearman,目前有大约 200 个工作进程来处理各种任务,比如把照片分享到 Twitter 和 Facebook,通知用户有新照片等等。
# 推送通知
Pyapns 已经处理了十亿的推送通知,非常稳定,他们还自己开发了基于 Node.js 的 node2dm,用于向 Android 设备发送推送通知;
# Monitoring
- Munin 与 Python-Munin 图形化方式显示系统状态;
- 网络守护进程 Stated 可以实时收集数据并做汇总
- Dogslow 会监控进程,一旦发现运行时间过长的进程,便会保存该进程的快照,以便后续分析;比如响应时间超过1.5秒的请求,通常都是卡在 Memcached 的 set ()和 get_many ()方法上。
- 对于 Python 的错误,只要登上 Sentry 就能实时获取错误信息
# References
[Instagram Engineering] (http://instagram-engineering.tumblr.com/rss)
[了解Instagram背后的技术] (http://www.cnblogs.com/piaoger/admin/EditPosts.aspx?postid=2520969)