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