行業動態 | Instagram: 從Redis到Cassandra成功節省75%的成本

從Redis轉到Cassandra，Instagram在欺詐檢測、消息推送以及消息中心等功能上節省了75%的成本。

 

Instagram是如何部署Cassandra的？隨着業務規模的擴大，Instagram又遇到了哪些挑戰，而且如何解決這些問題呢？本文將經過對Instagram的兩位工程師的採訪，爲你揭曉答案。

 

本篇文章的部分素材寫於2014年，其中的提到的某些硬件配置可能略微過期，但對如今的應用場景仍有借鑑意義，故而仍決定翻譯並分享。

---

 

「使用Cassandra讓咱們的成本削減至以前花銷的大約四分之一。不只如此，Cassandra解放了咱們——由於咱們只需將數據丟入集羣便可，它有很強的伸縮性，而且咱們能夠隨時按需添加節點。」

——Instagram軟件架構工程師Rick Branson

 

Instagram是一個自由分享照片的APP，用戶能夠用它拍照、添加濾鏡，並將照片分享至像是Facebook和Twitter一類的社交網絡。上億的Instagram用戶用這款APP拍攝並編輯他們的照片和視頻，並將這些創做與全世界分享。

 

 

01 經過使用Cassandra削減成本

 

最初咱們的Cassandra集羣部署是爲了存儲與安全和網站完整性(site integrity)相關的審計信息的。具體一些來講，包括了反垃圾信息、識別不良用戶以及其餘相似的事情。這些偏偏是Cassandra的強項。

 

原來這些功能都是由Redis來提供的。可是隨着數據量迅速增加，將數據存在內存再也不是一個有效率的方法。咱們有很是高的寫入比例，而讀取比例則至關低——這也正符合了Cassandra的那些很是突出閃耀的點。因此最終把這部分數據轉移到Cassandra，這對咱們來講幾乎是不假思索的事情。

 

咱們從一個擁有三個節點的集羣開始，用於這個用例的集羣后來逐步擴大到十二個節點。這就是咱們獲取主要的應用程序後臺信息的途徑。

 

02 欺詐檢測、消息推送以及消息中心

 

對於上面提到的第一個後端用例，咱們移除了Redis的主從複製設置，由於它實在是耗資巨大。咱們再也不把全部的東西用一個很是之大的實例存在內存裏，而是把這些都放到了硬盤裏。

 

使用Cassandra讓咱們的成本削減至以前花銷的大約四分之一。不只如此，Cassandra解放了咱們——由於咱們只需將數據丟入集羣便可，它有很強的伸縮性，而且咱們能夠隨時按需添加節點。

 

當你從一個不分片的設置轉向一個分片的設置時，你會感到很痛苦。可是轉向Cassandra意味着你基本無需額外操心，由於你不用經歷拆分數據這個痛苦的過程。

 

最近咱們決定將另外一個更爲關鍵的用例移植到Cassandra上來。咱們花了時間讓團隊中的每一個人瞭解Cassandra、閱讀文檔、學習如何有效率地運行和維護Cassandra。

 

咱們選擇將Cassandra用在咱們的App中被稱爲「消息中心(inboxes)」或消息推送(newsfeed)的部分。基本上來講，它負責推送全部和指定用戶相關的動態——你能夠看到有沒有人給你的照片點贊、有沒有人關注你、你有沒有朋友也在使用Instagram，或者收取評論等等。

 

咱們決定將這部分數據也從以前用的Redis轉移到Cassandra的緣由，一樣是由於咱們遇到了內存限制的問題。

 

對於這個「收件箱」的用例，這些推送信息其實已經被拆分了。以前使用Redis時，咱們的集羣有32個節點，其中16個是主節點，16個是用於failover的從節點——另外固然，咱們必須得認真檢查全部的分片。

 

咱們注意到咱們的空間已經不夠用了，雖然CPU沒有被消耗多少（Redis在CPU層面來講很是有效率）——可是顯然，當你的內存告急的時候，你根本無能爲力。

 

最終，在這個用例上使用Cassandra集羣是一個更具備成本效益且運維更容易的方案，由於你其實並不須要內存數據庫級別的性能。持久性(durability)是另外一個Redis不能提供有效支持的主要因素，在此就很少作展開了。

 

03 Instagram的部署方案

 

咱們已經對Cassandra的可靠性和可用性有至關的體會了。Cassandra的工做負載與以前很是不一樣：咱們在一些SSD盤上運行Cassandra，這使咱們可以利用全部的很是好的亮點功能，包括虛擬節點(vnode)、分級壓實(leveled compaction)等等。Cassandra是一個很是成功的項目，咱們只花了幾天就完成了整個系統遷移。

 

這裏有一些關於咱們的集羣的詳細信息：這個由亞馬遜AWS EC2的hi1.4xlarge實例組成的集羣擁有12個節點，咱們在其中一共存儲了大約1.2TB的數據。峯值時，咱們每秒向着這個集羣大約寫入2萬條數據，而且每秒大約讀取1萬5千條數據。

 

Cassandra可以勝任這樣的工做，這讓咱們印象很是深入。這讓咱們無需再尋尋覓覓，無需再嘗試別的解決方案，這對咱們來講真的是一個很是棒的經歷。咱們從咱們第一次的部署實施中學到了不少，這些知識也被咱們應用於最近的部署實施中。

 

每一次用戶使用Instagram，他們都在從一個擁有12個節點的Cassandra集羣中獲取數據——這讓人感到很是興奮。

 

時光倒流回2010年，Instagram如今存在Apache Cassandra上的全部數據，在那時還被存在一個位於美國的數據中心。隨着公司的擴張，他們後來添加了第二個數據中心，同最早的數據中心一塊兒支持服務。隨後沒過多久，他們又添加了第三個數據中心。每一次他們添加一個新的數據中心，他們都得增長數據複製。

 

回到今天，現在的Instagram有十億的日活用戶，來自全世界各地。在爲這些用戶提供服務的同時還要保持高性能，Instagram須要一個合適的數據存儲策略。

 

「爲了可以支持增加的工做負載，咱們對於硬件資源的擴充需求變得愈來愈明確。說到底，這意味着在更多的國家要有更多的數據中心。」

——Facebook工程師Andrew Whang

 

很是肯定的是，Instagram在美國之外的其餘國家添加了更多數據中心，可是咱們意識到咱們的數據複製策略(replication strategy)在大規模擴張時成了短板。

 

當咱們向多個國家擴張時，咱們遇到了如下兩個挑戰：

• 太多副本：有3個數據中心的時候Instagram有3個副本；有5個數據中心的時候Instagram就有5個副本。這個問題會隨着時間的推移愈來愈嚴重。
• 性能降低：QUORUM要求收到兩個相近的副本節點的確認信息。隨着時間的推移，QUORUM就會要求收到三個副本節點的確認信息。而當它們來自不一樣的洲，這些副本節點離彼此的距離至關遙遠。故而這個次優的配置有損性能。

 

爲了解決這些問題，Instagram決定再也不處處複製數據，而是在數據生成的地區就近儲存。這樣，咱們能夠構建一個更快且更有效率的網絡，並能爲本地數據的存取提供更好的性能。畢竟，大多數用戶在大多數時間都在同一個地理區域使用Instagram。

將美國的數據存儲在美國的數據中心，將歐洲的數據存儲在歐洲的數據中心——這樣，公司就可以實現最佳性能。

 

Instagram還用了一個Facebook開發的叫作Akkio的工具來管理大規模的本地數據，從而提供更強的用戶體驗。

 

04 深刻挖掘Cassandra文檔

 

若是有人問我，我會建議深刻理解Cassandra這個系統而且閱讀全部的Cassandra文檔，尤爲是那些在DataStax網站上的。這些文檔最棒的是，我注意到其中會有不少額外的關於內核的信息，透徹地理解這些很重要。

 

不管你用什麼數據庫或是數據存儲，你都須要深刻地理解文檔，以便你可以按照合理的方式來使用這些系統。人們常常遇到這樣的狀況：他們沒有作好前期功課，就很快地或者錯誤地決定採用某種解決方案，結果把本身逼到了死角。

 

尤爲對於數據存儲來講，採用正確的解決方案真的很是重要，由於數據存儲應該是你的應用棧中最穩定可靠的部分。

 

點擊這裏查看原博客