利用ElasticSearch和Redis檢索和存儲十億信息

摘要：每隔幾個月，發送、存儲和索引的信息就會翻一番，在過去幾個月HipChat進入了一個指數增加週期。如此多流量的暴增對哪一個初創來講都不輕鬆，這裏咱們看HipChat的解決之道。

本文來自Zuhaib Siddique的一次專訪，Zuhaib是羣聊IM製造商HipChat的生產工程師，下面咱們一塊兒看Tod Hoff的整理。

如下爲譯文：

若是從企業應用的生存率來看，選擇企業團隊信息做爲主要業務，HipChat的起點絕非主流；可是若是從賺錢的角度上看，企業市場的高收益確實值得任何公司追逐，這也正是像JIRA和Confluence這樣的智能工具製造商Atlassian於2012年收購HipChat的緣由。

同時，或許你不知道的是，在Atlassian資源和人脈的幫助下，HipChat已經進入了一個指數增加週期。12億的信息存儲意味着他們如今每隔幾個月的信息發送、存儲和索引量都會翻一番。

如此快速的增加給曾經充足的基礎設施帶來了很大的壓力，HipChat給咱們展現了一個通用的擴展思路。從簡單開始，經歷流量高峯，而後思考如今怎麼辦？使用更大的計算機一般是第一個和最好的答案，他們也是這樣作的。這給了他們一些喘息空間去考慮下一步怎麼作。在AWS上，在某一個拐點以後，你開始走向雲特性，也就是橫向擴展，這就是HipChat所作的事情。

然而HipChat的發展也並未是順風順水，安全性的擔心推進了HipChat的雲（SaaS）版本以外內部部署版本的發展。

即便HipChat沒有谷歌那麼大規模，咱們仍能從中學到好東西，好比他們如何及時索引和搜索十億信息，這也是IRC之類和HipChat之間的關鍵區別。在負載下索引和存儲信息，丟失信息是一個艱鉅的挑戰。

這是HipChat選擇的路，咱們一塊兒展開……

統計

 

• 每秒60條消息
• 12億文檔存儲
• 4TB的EBS RAID
• 在AWS上8個ElasticSearch服務器
• 26個前端代理服務器，是後端應用服務器的一倍
• 18我的
• 0.5TB的搜索數據

 

平臺

 

• 主機：AWS EC2 East上的75個實例所有使用Ubuntu 12.04 LTS 
• 數據庫：目前用於聊天記錄的CouchDB，過渡到ElasticSearch。MySQL-RDS用於其它的一切
• 緩存：Redis
• 搜索：ElasticSearch
• 隊列/Worker 服務器：Gearman（隊列），Curler（Worker）
• 語言：Twisted Python（XMPP Server）和PHP（Web前端）
• 系統配置：開源Chef+Fabric
• 代碼部署：Capistrano
• 監控：Sensu和monit將警告抽送至Pagerduty
• 圖：statsd + Graphite

 

產品

 

• 流量突發。在週末和假期將是安靜的。在高峯負荷期間每秒有幾百個請求。實際上佔用大部分流量的並非聊天信息，而是狀態信息（away、idle、available），人們鏈接/斷開等。所以每秒60條消息彷佛不多，可是它只是一個平均水平。
• 通知中心HipChat，在這裏與團隊合做，並獲得來自工具和其餘系統的全部信息。有助於使每一個人都在消息圈內，特別是遠程辦公。
• 使用HipChat而不是IRC之類，很大的緣由是HipChat存儲和索引每一次對話，以便你之後搜索它們。強調搜索，這個特性的好處是你能夠在任什麼時候候作回溯，瞭解發生了什麼和贊成了什麼。若是在發送一條信息時，你的設備沒法訪問，它也會將消息路由到同一個用戶的多臺設備中，並作臨時消息緩存/重試。
• 更多的用戶帶來更快的增加，他們在各個方面使用產品而帶來的更多預約，也能夠從他們的API集成中看到增加。
• 存儲和搜索信息是系統中主要的可擴展性瓶頸。
• HipChat使用XMPP協議，所以任何XMPP客戶端均可以鏈接到系統中，這點很是有利於採用。他們已經創建了本身的本地客戶端（Window、Linux、Mac、iOS、Android），並帶有相似PDF瀏覽、自定義表情符號、自動用戶註冊等擴展。
• 在之前，將Wiki這樣的工具引入到企業文化是幾乎不可能的。如今，企業級的工具多已在企業落腳，這是爲何？

 

 

• 基於文本通訊已被普遍接受。咱們有短信、IM和Skype的形式，因此如今使用聊天工具是天然的事情。
• 異地工做模式的崛起。團隊愈來愈分散，咱們不能只是坐在一塊兒進行一個講座，一切文檔化的須要意味着組織通訊將有一筆巨大的財富。
• 加強的功能。把像內嵌圖片、GIF動畫等功能作得生動有趣，會吸引更普遍的羣體。

 

 

• HipChat有一個API，這使得它能夠編寫相似IRC bots這樣的工具。例如使用Bitbucket提交——在10:08開發者X提交一些代碼來修復一個漏洞。代碼發送經過HipChat直接鏈接到代碼提交和提交日誌，徹底的自動化。Bitbucket提交會擊中一個web hook，並使用一個addons來張貼信息。Addons幫助編寫bots，轉入你的Bitbucket帳戶。好比我有個人API令牌，我想在每次提交發生時張貼到這個API上，工做原理相似GitHub。
• 在客戶端Adobe Air啓動時，內存泄露會致使宕機，所以將其移動到本地應用上。這是個麻煩，也是機遇。同一個公司中都存在許多跨平臺跨部門的用戶，你須要站在用戶的角度思考。但願用戶在全部的系統中都有很好的體驗，用戶不只僅是技術人員。

 

XMPP服務器架構

 

• HipChat是基於XMPP協議的，XMPP節裏的內容就是消息，多是一行文本或者日誌輸出的長段等等。他們不想談論本身的XMPP架構，因此沒有不少的細節。
• 他們沒有使用第三方的XMPP服務器，而是利用Twisted Python和XMPP庫創建了本身的服務器。這使得能夠建立一個可擴展的後端、用戶管理，並輕鬆的添加功能而不用在其它代碼庫上修改。
• AWS上的RDS用於用戶身份驗證和其它使用事務及SQL的地方。這是一個穩定、成熟的技術。對於內部部署的產品，則使用MariaDB。
• Redis用於緩存。信息，如哪些用戶在哪些房間，狀態信息，誰在線等都是信息。因此，你鏈接的是哪一個XMPP服務器並不重要，XMPP服務器自己並非一個限制。

 

 

• 痛點是Redis（還）沒有集羣，所以使用了高可用性的hot/cold模式，因此，一個從屬節點已經準備就緒。故障轉移從主節點到從屬節點大概須要7分鐘，從屬節點的發佈是手動的，不是自動的。

 

 

• 提升負載能夠發現代理服務器中的弱點所在，也能夠清楚能支撐多少個客戶端。

 

 

• 這是一個真正的問題，正如不丟失信息是一個很大的優點。顯而易見，不丟失信息比低延遲更重要——用戶更願意晚點接收信息，而不是根本沒有信息。
• 使用6個XMPP服務器系統運做良好，然而隨着鏈接點的增長，他們開始看到不可接受的延遲。鏈接不只來自客戶端，還來自bots支持他們的程序設計界面。
• 在第一遍的時候，他們分離出前端服務器和應用服務器。代理服務器處理鏈接，後端應用程序處理的stanza。前端服務器數量由有效收聽客戶數量驅動，而不是由信息發送數量驅動。保持那麼多的鏈接打開，同時提供及時的服務是一個挑戰。
• 修復數據存儲問題以後的計劃是調查如何優化鏈接管理。Twisted的效果很好，可是他們有不少的鏈接，因此必須弄清楚如何更好地處理這些鏈接。

 

存儲架構

 

• 向HipChat發送的消息已達10億條，同時還在不停增加，他們將CouchDB和Lucene對存儲和搜索信息的解決方案推向極限。

 

 

• 認爲Redis將會是故障點，而Couch/Lucene會足夠好。沒有作合適的容量計劃和查看信息增加率。增加速度比他們想象的更快，不該該集中那麼多精力在Redis上，而應該專一於數據存儲。
• 當時他們相信經過增長容量來擴展，向上移動到愈來愈大的亞馬遜實例。他們發現一點，隨着不斷地增加，他們利用這種方法只能再工做兩個月。因此，他們不得不採用其餘的辦法。
• Couch/Lucene超過一年沒有更新，它不能作分類。這是採用其餘辦法的另外一個緣由。

 

 

• 在亞馬遜上大約10億消息的一半是一個臨界點。用一個專用的服務器和200G的RAM，他們以前的架構可能仍能工做，但在有限資源的雲上就不能工做了。
• 他們想留在亞馬遜。

 

 

• 喜歡AWS的靈活性，性能的添加只須要經過租用實例完成。
• 亞馬遜的片狀。不要把你全部的雞蛋都放到一個籃子裏，若是一個節點出現故障，你必需要處理它，不然一些用戶將會失去流量。
• 使用動態模型。能夠快速關閉一個實例，並帶來新的實例。雲原生類型的東西。能夠隨時關閉節點。關閉一個Redis主節點，能夠在5分鐘內恢復。目前美國東岸分割4個可用地區，可是尚未多區域。
• EBS只讓你擁有1TB的數據。在遇到以前，他們並不知道這個限制。使用Couch時他們遇到了EBS磁盤大小限制。HipChat的數據是0.5TB。爲了壓縮，Couch必須將數據複製到有雙倍容量的壓縮文件中。2TB的RAID在週末壓縮過程當中遇到了限制，不想使用RAID解決方案。

 

 

• 不選擇亞馬遜的DynamoDB，由於他們建立了一個HipChat服務器，在防火牆後面的託管服務。

 

 

• HipChat服務器驅動技術堆棧的決定。私人版是創建在本身主機上的解決方案。某些客戶不能使用雲/SaaS解決方案，好比銀行和金融機構，國家安全局已經嚇壞了國際客戶，所以聘請了兩名工程師建立產品的安裝版本。
• Redis集羣能夠自託管，也能夠像ElasticSearch那樣工做在AWS上。在內部部署版本中他們使用MariaDB，而不是RDS。
• 不能考慮一個完整的SaaS解決方案，由於那會是一個鎖定。

 

 

• 如今過渡到ElasticSearch

 

 

• 移動到ElasticSearch做爲他們的存儲和搜索後端，由於它能夠儲存他們的全部數據，它是高度可用的，它能夠經過簡單增長更多的節進行擴展，它是多用戶的，它能夠經過分區和複製透明的處理節點損失，而且它創建在Lucene之上。
• 並不真的須要一個MapReduce功能。看着BigCouch和Riak的搜索（表現通常），但ES在GET上的表現是至關不錯的。喜歡壞了就扔，省去了故障檢測。 ES HA已令他們在系統的堅固性上感到很是有信心。
• Lucene的兼容是一個巨大的勝利，由於全部的查詢都已經兼容Lucene，所以它是一個天然的遷移路徑。
• 客戶數據是至關多樣的，從聊天記錄到圖像響應類型的差異也隨處可見，他們須要可以快速地直接從12億文檔中查詢數據。
• 此舉正變得愈來愈廣泛，HipChat也使用ElasticSearch做爲他們的key-value存儲，減小須要數據庫系統的數量，從而下降總體的複雜性。既然性能和響應時間都不錯，那徹底沒有不用的理由。 10ms到100ms的響應時間。在沒有任何緩存的狀況下，某些領域仍然超過Couch。那爲何還要用多個工具？
• 使用ES，一個節點故障不會引發任何人的注意。在它再平衡時你會獲得CPU使用率太高的警報，可是系統仍然運行。
• 用8個ES去處理流量的增加。
• 基於Java的產品JVM調整可能很是棘手。

 

 

• 要使用ES，必須有堆空間容量計劃。
• 測試緩存。ES能夠緩存過濾結果，這是很是快速的，可是你須要很大的堆空間。雖然8個主機擁有22G的內存，但還會隨着緩存的打開被耗盡。因此若是不須要就關閉緩存。
• 緩存有問題，由於它會遇到內存不足的錯誤而後失敗。集羣會在幾分鐘內恢復，只有少數用戶會注意到這個問題。

• 由於網絡的不可靠，Amazon的故障轉移也可能存在問題。在集羣中可能會引發錯誤的選舉發生。

 

 

• 使用ElasticSearch會遇到這些問題。本來有6個ES節點做爲主節點選舉運行，一個節點可能會耗盡內存或者遇到一個GC暫停並在網絡中丟失。那麼其餘人就不會看到這個主節點，進行選舉，並宣佈本身是主節點。他們選舉架構中的缺陷是他們不須要法定人數。所以就會出現Split Brain問題，從而引發不少問題。
• 解決方案是在專用的節點上運行ElasticSearch主節點，那麼須要作的事情就是成爲主節點，從而避免了後續問題。主節點處理分片的分配是完成，誰是主要的，而且完成複製分片分佈圖。實現再平衡要容易的多，由於主節點能夠性能優良的處理全部的再平衡。能夠查詢任何節點，並會作內部路由。

 

 

• 使用月索引，每月是一個單獨的索引。每一個初級索引有8個分片，而後有兩個副本。若是一個節點丟失，系統仍能工做。
• 不要把RDS移動到ES中。須要使用SQL的數據通常儲存在RDS/MariaDB中，典型的是用戶管理數據。
• 在Redis集羣被釋放以前，Redis中大量的緩存是主/從設置。有一個Redis統計服務器，處於離線狀態。Redis歷史緩存的最後75條消息，用於防止在第一次加載對話時不間斷的訪問數據庫。也有內部狀態或快速數據的狀態，好比登入用戶數量。

 

常規

 

• Gearman用於異步工做，好比iOS的推送和傳遞電子郵件。
• AWS West用於災難恢復，一切都會備份到AWS West。
• Chef用於全部配置。ElasticSearch有一個很好的Chef手冊，輕鬆上手。像Chef，由於你能夠開始寫Ruby代碼而不是使用Puppet風格的DSL，它也有一個很好的活躍的社羣。
• 收購經驗。他們如今已經進入公司的核心資產和人才，但Atlassian不干擾工做，之因此相信，是有緣由的。能夠在內部要求，例如，如何擴大ElasticSearch ，當別人在Atlassian須要幫助時，他們能夠加入幫忙的隊伍。良好的總體體驗。
• 扁平的團隊結構。仍然是一個小團隊，目前大約有18人。兩我的在DEVOPS，少數平臺，IOS、Android的開發人員在服務器端，一個Web開發工程師（在法國）。
• Capistrano用於部署全部的主機。
• Sensu用於監控應用程序。讓你無需監視堆空間ElasticSearch節點，而後在沒有任何通知的狀況下解決OOM問題。目前堆的使用率爲75％，這正是他們想要的狀態。
• Bamboo用於持續集成。
• 客戶端版本還不正規，開發者驅動，有一個臨時區域進行測試。
• 集團標誌。能夠控制哪些羣體獲得了一個功能、測試特性能及緩慢釋放特性，除此以外還能幫助控制主機的負載。
• 功能標誌。有利於ElasticSearch部署過程當中的保護。例如，若是他們發現一個漏洞，他們能夠關閉一個功能，並回去找Couch。用戶不會注意到差異。在Couch和ElasticSearch之間的過渡階段，他們都有應用複製到兩個存儲。
• 新的API版本將使用Oauth，所以，開發人員可使用HipChat API在本身的服務器上部署。有客戶使用本身的服務器是一個更具擴展性的模式。

 

將來

 

• 將來幾個月將會達到20億條消息，估計ElasticSearch能夠處理大約20億條消息。不肯定如何處理負載的預期增加。預計要到Amazon West以得到數據心更多的的可用性和可能在不一樣的數據中心投入更多的用戶。
• AWS自動擴展能力
• 移動到語音，私人一對一視頻、音頻聊天、基本的會議
• 未來可能使用RabbitMQ來傳遞消息
• 與Confluence更大的集成。使用HipChat聊天，而後使用Confluence頁面來捕捉細節。

 

經驗教訓

1. 企業應用程序是搖錢樹。賣入一個企業是很痛苦的，銷售週期長意味着太多的不肯定性。可是若是你成功賣出，那就會得到豐厚的利潤，因此你應該考慮企業市場。時代在變，企業卻多是滯後的，可是他們仍然採用新工具和新的作事方式，這其中就有機會。

2. 隱私在產品給企業推銷時變得愈來愈重要，它會直接影響到產品的選擇與否。HipChat正在作他們產品的備用版本，以使那些不相信公共網絡的客戶滿意。對於一個程序員來講，雲做爲一個平臺很是有意義。對於一個企業來講，雲能夠是魔鬼。這意味着你必須作出靈活的技術堆棧選擇。若是你在服務上100%依靠AWS，那你的系統移動到另外一個數據中心將變得幾乎不可能。這對Netfix也許並不重要，可是若是你想賣入企業市場，它就很重要了。

3. 縱向擴展以得到喘息的空間。當你等待弄清楚架構中下一步要作什麼的時候，能夠花不多的錢去縱向擴展，給本身幾個月的喘息之機。

4. 選擇不會失敗的。HipChat作出了不會丟失用戶聊天記錄優先級，因此他們的架構將這個優先級反映給保存聊天記錄到磁盤，在宕掉後系統恢復時會從新加載。

5. 進入本地。你的客戶在許多不一樣的平臺上，一個本地的應用將會提供最好的體驗。對於一個初創公司，那是不少的資源，太多了。因此，賣給擁有更多資源的公司在某種程度上是說得通的，這樣你能夠創建更好的產品。

6. 功能和羣組標誌作出更好地發佈慣例。若是你能夠選擇哪些組看到一個功能，若是你能在生產和測試中關閉功能，那麼你就不用擔憂發佈新的構建項目了。

7. 選擇你真正自信的技術。ElasticSearch應對增加的橫向擴展能力讓HipChat很放心，一樣也會有一個很好的用戶體驗，這纔是最重要的。

8. 成爲該流程的一部分，你變得更有價值，難以消除。HipChat做爲人和工具之間的自然契合點，也是來編寫實現各類有用工做流bots的自然點。這使得HipChat在企業中有發揮的平臺，它使原本不可建造的功能得以實現。若是你能作到一樣的事情，那麼你們都會很須要你。

9. AWS須要在總線上存在一個單獨的節點，這個要求看起來有點荒謬，可是在雲環境下卻很是重要，由於機器可用信息在第三方目的源中並不可見。若是着眼機架就會發現它常常有一個單獨存在的總線插槽，若是其餘插槽可用，他就會知道。這樣，你就沒必要去猜想。在雲中，軟件採用基於原始TCP的鏈接技術和心跳，去猜想另外一個節點是否發生故障，從而致使Split Brain問題及啓用備庫時產生數據丟失。這須要時間去演變，到達徹底可靠還須要邁一大步。

10. 產品決策驅動堆棧的決定，HipChat服務器驅動技術堆棧的決定：Redis集羣能夠自託管；不選擇亞馬遜的DynamoDB，是由於HipChat在防火牆的後面建立一個託管服務。

11. 你須要打開視野。你須要容量規劃，即便是在雲中。除非你的架構從一開始就徹底是原生雲，不然任何架構都會有負荷的拐點，在拐點他們的架構將再也不可以處理負載。看看增加速度，項目出來了。會打破什麼？你將會作什麼？並且不要再犯一樣的錯誤。HipChat將如何處理40億條消息？當下還沒法知曉。

12. 瞭解系統的限制。EBS有1TB的存儲限制，這是很大的限制，但若是你的存儲已接近那個限制，就須要有一個計劃了。一樣，若是你的數據庫，例如Couch，在壓縮階段要使用雙倍的磁盤空間，那將會影響你的系統限制。

13. 這個世界會令你大吃一驚。六個月前HipChat認爲Redis將會是最弱的環節，但如今它依舊很強壯，而Couch和EBS纔是最薄弱的環節。