Instagram 架構分析筆記
Instagram 團隊上個月才迎來第 7 名員工，是的，7個人的團隊。用戶數量超過 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 還偉大。
--EOF--
文章出處：http://www.dbanotes.net/arch/instagram.html