What Powers Instagram: Hundreds of Instances, Dozens of Technologies(譯文，轉)

標籤：des   Lucene   blog   http   使用   strong   

add by zhj: 對譯文略有修改。原文發表時，Instagram還沒被Facebook收購，讀完只感覺Instagram這三個後台工程師真牛逼。

三個人就可以搞定1400萬註冊使用者。不過，另一方面，我們也看到，這三個人其實使用的都是現成的技術，至少從文章中看不出他

們有什麼技術上的創新，當然就三個人搞創新也難了點，而且如果現有技術能基本上解決問題，對這樣一個小團隊而言，就沒必要

自己開發新技術。最後，對他們願意把方案分享出來表示非常感謝。

英文原文：http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of

譯文：http://www.cnblogs.com/xiekeli/archive/2012/05/23/2514108.html

 

當我們與其他工程師偶遇和交流的時候，有一個問題經常被問及，“你們的技術架構（technology stack）是怎麼樣的”？我們覺得從較高的層次來描述Instagram的所有構成系統是一件有趣的事情；未來你可以期待更深入的描述這些系統。這就是我們的系統，僅僅1年時間，並且我們活了下來，其中有一部分我們一直在修改。一個小型團隊的初創公司，可以在一年多一點時間發展到1400多萬使用者規模。 我們選擇一種技術的核心原則是：

•   盡量保持簡單
•   不重複發明輪子
•   盡量用被驗證的可靠的技術

我們將自頂向下進行介紹：

作業系統 / 主機

我們在亞馬遜的 EC2上跑Ubuntu Linux 11.04 (“Natty Narwhal”)。我們發現之前的版本在EC2上高流量的時候都會出現各種不可預測的問題（ freezing episodes），但11.04已經穩定了。我們只有3名工程師，我們的需求依然在不斷的變化中，因此自受管理的主機不是我們的選擇，也許未來當使用者量空前增長的時候，我們會考慮。

負載平衡

每一個對Instagram 伺服器的訪問都會通過負載平衡伺服器；我們使用2台nginx機 器做DNS輪詢。這種方案的缺點是當其中一台退役時，需要花時間更新DNS。最近，我們轉而使用亞馬遜的彈性負載平衡器，使用3個NGINX 執行個體可以實現調入調出（如果有哪個NGINX健全狀態檢查失敗，則自動剔除）；我們同時在 ELB 層停掉了 SSL , 以緩解nginx的 CPU 壓力。我們使用亞馬遜的Route53作為DNS，他們最近在AWS控制台上為Route53增加了一個很好的GUI工具。

應用伺服器

接下來是應用伺服器用來處理我們的請求。我們在亞馬遜的High-CPU Extra-Large機器上運行了Django ，隨著使用量的增長，我們已經在25台主機上跑Django執行個體了（幸運地，因為是無狀態的，所以非常便於水平擴充）。我們發現我們的個別工作負載是屬於CPU bound而不是memory bound，因此High-CPU Extra-Large類型的執行個體剛好提供了合適的比重（CPU和記憶體）。

我們使用 http://gunicorn.org/ 作為我們的WSGI伺服器；我們曾經使用mod_wsgi 和Apache，但是發現Gunicorn 更容易配置，且對CPU的要求更低。為了 一次在多個執行個體上執行命令（像部署代碼），我們使用Fabric，Fabric最近增加了並行模式，因此部署只需要花費幾秒鐘。

資料存放區

我們大部分資料（使用者資訊，照片的中繼資料、標籤等）儲存在PostgreSQL中；我們 之前已經說了關於如何基於不同的Postgres 執行個體進行切分的。我們的主要分區叢集包含12個uadruple Extra-Large記憶體雲主機（且12個副本在不同的地區）；

我們發現亞馬遜的網路磁碟系統（EBS）每秒的尋道能力不夠，因此，將我們所有工作放到記憶體中就變得尤為重要。為了獲得合理的效能，建立了軟 RAID 以提升 IO 能力，使用的 Mdadm 工具進行 RAID 管理；

順便提一下，我們發現vmtouch用來管理記憶體資料是個極好的工具，尤其是在容錯移轉時，從一台機器到另一台機器，甚至沒有活動的記憶體概要檔案的情況。這裡是指令碼，用來解析運行於一台機器上的vmtouch 輸出並列印出相應vmtouch命令，在另一台機器上執行，用於匹配他當前的記憶體狀態；

我們所有的PostgreSQL執行個體都是運行於主-備模式，基於流複製，並且我們使用EBS快照經常備份我們的系統。為了保證我們的快照的一致性（原始靈感來源於ec2-consistent-snapshot）我們使用XFS作為我們的檔案系統，通過XFS，當進行快照時，我們可以凍結&解凍RAID陣列。為了進行流複製，我們最愛的工具是repmgr 。

對於從我們的應用伺服器串連到資料，我們很早就使用了Pgbouncer做 串連池，此舉對效能有巨大的影響。我們發現Christophe Pettus的部落格 有大量的關於Django、PostgreSQL 和Pgbouncer 秘訣的資源。

照片直接儲存在Amazon S3，當前已經儲存了幾T的照片資料。我們使用亞馬遜的CloudFront 作為我們的CDN，這加快了全世界使用者的照片載入時間（像日本，我們第二最受歡迎的國家）

我們也廣泛的使用了Redis ； 我們的main feed、activity feed、sessions系統（這裡是我們的Django session backend），和其他 相關係統 都使用了Redis。 因為所有的Redis資料都需要放在記憶體中，因此我們最後使用了幾個Quadruple Extra-Large Memory雲主機用於跑Redis。我們的Redis也是運行於主-備模式，並且經 常將DB儲存到磁碟，最後使用EBS快照備份這些資料（我們發現在主機上進行匯出太費勁了）。由於Redis 允許寫入備份，使得線上容錯移轉非常方便，轉移到一台新的Redis 機器，而不需要停機。

對於我們的geo-search API，我們一直使用PostgreSQL了很多個月，不過後來遷移到了Apache Solr.他有一套簡單的JSON介面，這樣我們的應用程式相關的，只是另一套API而已。

最後，和任何現代Web服務一樣，我們使用了Memcached 做緩衝，並且當前已經使用了6個Memcached 執行個體，我們使用pylibmc & libmemcached進行串連。亞馬遜最近發布了一個彈性快取服務，但是它並不比運行我們自己的執行個體便宜，因此我們還沒有切換上去；

任務隊列&推播通知

當一個使用者決定分享一張Instagram 的照片到Twitter 或Facebook，或者是當我們需要通知一個 即時訂閱者有一張新的照片貼出，我們將這個任務推到 Gearman， 一個任務隊列系統。通過任務隊列非同步執行意味著媒體上傳可以很快完成（即發一條instagram很快），而“重擔”可以在後台運行。我們大約有200個消費者（都用Python寫的），它們消費隊列中的任務。我們的feed fan-out也使用了Gearman，這樣posting就會響應新使用者，因為他有很多followers。

對於訊息推送，我們找到的最划算的方案是https://github.com/samuraisam/pyapns，一個開源的Twisted 服務，已經為我們處理了超過10億條通知，並且絕對可靠。

監視

對於100多個執行個體，監控變得非常重要。我們使用Munin進行圖形化度量，如果有什麼超出了正常範圍，那會提醒我們。我們基於 Python-Munin,也寫了很多Munin 外掛程式。用於圖形化度量非系統級的東西（例如，每分鐘的簽入人數，每條照片發布數等）我們使用Pingdom作為外部監控服務，PagerDuty 用於處理通知和事件。

對於Python錯誤報表，我們使用Sentry，它是由Disqus的工程師們寫的，是一個極好的開源的Django app。在任何時間，我們可以即時的查看系統發生了什麼錯誤。

是你嗎？

如果你對我們系統的這篇描述感興趣，或者你正躍躍欲試的想告訴我們關於系統你有什麼不同的見解，我們都靜候佳音。We’re looking for a DevOps person to join us and help us tame our EC2 instance herd.