相較於WhatsApp、LINE,2012年3月才剛剛推出的Cubie Messenger,算是後生晚輩,不過,這個由臺灣力可科技所開發的App,目前在全球不重複下載次數已經超過500萬,去年11月還獲得一筆來自美國、日本、臺灣等110萬美元的創投資金挹注。在此同時,美國矽谷新創公司育成機構500 Startup宣布的加速發展專案計畫(Accelerator Program)中,Cubie Messenger也名列其中,成為33個重點發展計畫之一。目前Cubie Messenger正以每個月30%以上的速度快速成長。

力可科技一開始就以全球市場作為目標,所以,Cubie Messenger後端的設計目標,就是要能夠橫向擴充,而且不能有單點失效(Single Point of Failure)的問題,最終則是要部署在Amazon的雲端服務EC2平臺上。基於這樣的需求,Cubie Messenger的後端總共有3個子系統構成,其中包括Message Server、資料庫平臺、外部簡訊服務處理等。資料庫部分,則選擇了分散式資料庫Cassandra。

在力可科技推出Cubie Messenger前,還曾推出線上遊戲平臺,這個服務原本是部署在關聯式資料庫MySQL,但是,當資料量越來越大,寫入的速度也越來越慢,資料量達到2億筆時,伺服器就故障了。為了解決這個問題,力可科技曾經嘗試幫資料庫減肥,並計劃以Auto-table技術來做資料切割,然而,轉換過程中,卻因為資料格式修改,加上大量資料轉換,導致服務中斷宣告失敗。

後來,力可科技決定尋找其他替代方案,而Cassandra這個新興的NoSQL資料庫正好出現了,當時雖然還有CouchDB、MongoDB、Redis、MemcacheDB等其他開源分散式資料庫可供選擇。不過,只有Cassandra能符合力可科技的3大需求,除了能夠因應大量寫入與多臺機器並行的需求之外,Cassandra也是用力可科技開發成員熟悉的Java語言所開發,當遇到問題時,力可科技可以直接檢視資料庫主程式的原始碼,從根本處解決問題。

力可科技技術長陳彥任表示,由於Cassandra是分散式資料庫,而且採取Peer to Peer叢集架構,每臺主機的角色與功能都是相同而獨立的。因為沒有一臺伺服器擁有主權,所以沒有單點失效的問題,也不會因為某一臺主機掛掉就導致資料庫無法運作。

相較於MongoDB與HBase等其他分散式資料庫,Cassandra的資料處理架構,最少只需要建立兩個伺服器節點,就能完成Peer to Peer部署架構,這兩個節點設定完成後,會自己複寫資料、平衡資料庫存取的負載以及分散儲存。不僅較為簡單而且又可以達到高可用性,資料庫管理與維護也相對單純,對於人力有限的力可科技而言,非常適合。

在決定轉換之前,力可科技為了確認Cassandra的穩定性,曾經有一個月時間,採取雙系統並行的做法,而且在正式營運環境,進行兩個階段的資料庫效能驗證。首先,是驗證資料寫入Cassandra的穩定性,例如:是否有資料毀損或是資料持續寫入瓶頸等問題。第二階段,則是驗證資料讀取是否有問題,著重的是資料讀取結果比對,為了不影響營運服務,這個階段仍是由MySQL負責回應使用者需求。此外,由於Cassandra的資料讀取的速度原本就比MySQL慢,是否能夠因應力可科技的營運需求,也是這個階段的驗證指標。

經歷了兩個階段的驗證,Cassandra的確能符合需求之後,力可科技才正式將遊戲平臺所用的資料庫從MySQL轉換到Cassandra。後來,力可科技決定推出Cubie Messenger時,自然一開始就直接使用Cassandra資料庫。

為了保證資料完全寫入,力可科技的Cassandra部署架構,一開始就設定每次寫入資料時,都會同時寫入3臺不同的資料庫主機。這種做法,就算有一臺主機發生故障,另外兩臺還是可以持續運作。在此同時,Cassandra內建的資料複寫功能,會自動修復資料,然後藉由不斷修復的過程,讓資料最後能夠達到一致性要求,這是Cassandra的特性,可允許資料在某一段時間內不一致,而Cubie Messenger的資料特性也可 符合。

 Cassandra應用特性 

 特性1  容易部署、快速擴充與高可用性三效合一

Cassandra的執行環境只需要建立兩個伺服器節點,並且在設定檔中指定這兩個節點溝通的IP網址,當資料庫啟動之後,這兩個節點就會自己複寫資料、平衡資料庫存取的負載以及分散儲存。陳彥任表示,因為每一臺伺服器節點的角色與功能,都是對等而且獨立的,沒有主從關係,且有複寫機制,所以具備高可用性,沒有單點失效的問題。

除此之外,即使需要新增一個節點或是有一個節點的資料庫發生故障,都只需要重新設定參數,開啟後就能立刻加入運作,成為運作節點的一環。一般情況下,不論是新增節點或是減少節點,大約只需要10分鐘時間。

陳彥任表示,依據力可科技的部署規畫,目前每新增一個節點,等於擴大20萬人同時上線的服務承載能量,也就是每秒1千多萬筆的資料存取需求,而這個過程,只需要10分鐘就能完成所有部署動作,也就是從空機到節點設定完成後,自己複寫資料、重新平衡資料庫存取負載,啟動分散儲存機制等作業程序,都能在10分鐘內完成,然後加入運作,整個過程,不僅簡單而且又可以達到高可用性。

對於力可科技而言,由於人力有限,只有1~2人負責做資料庫管理,而Cassandra的架構設計簡單,不論是資料庫維護與管理,甚至是要立即擴充,都能輕鬆因應。

 特性2  資料寫入效能佳,能承載百萬用戶存取量

相較於其他NoSQL分散式資料庫,Cassandra的資料寫入效能,就算沒有名列第一,至少也是前三大之列,陳彥任認為,這是Cassandra的優勢之一,也是Key-value儲存結構的共有特性,相對適合使用者動輒數百萬起跳的網路服務。

以Cassandra來說,由於資料儲存結構是Key-value,所以,每一筆資料可以簡化到只有兩個欄位,也就是Key欄位與Value欄位,每一個Key對映一個Value欄位。對於某個Key,Value可以是任意的資料類型,而且可以由多個欄(Colum Family)組成。讀取資料的方式,也只有設定值、取出值、刪除值等簡單操作。

在Key-value結構中,沒有關聯式資料庫的欄位架構(Schema),也沒有關聯式資料庫慣用的資料結合(Join)與交易功能(Transaction),所以,資料列的設計必須把所有查詢需求都涵蓋進來,然後以Key-value的結構儲存,後續才能透過Key來查詢,換句話說,就是原本在關聯式資料庫Where的條件,都必須轉換成Cassandra的Key。否則就必須建立反向索引(Value- key)機制,才能對Value進行查詢。

由於Key-value結構沒有關聯式資料庫的欄位架構(Schema),只要建立另一群Key值,就等於建立了另一個資料表,每一群資料之間沒有關聯,所以,可以任意切割與擴充,是Cassandra能夠快速擴充的原因之一。

 特性3  循序寫入資料,不怕低速硬碟的I/O瓶頸

因為Cassandra是以Append的方式來寫入資料,不論新增資料或是修改資料,每一筆資料寫入硬碟時,都是採取循序寫入模式,並且保留所有Log紀錄,當資料出現不一致的情況,Cassandra會去比對寫入硬碟中的Log檔,並藉此保證資料能夠完全寫入,即使資料庫硬碟是比較低階的規格,也不會影響到資料寫入的效能。

這個特性對於資料庫佈署在AWS平臺非常重要,陳彥任表示,因為AWS通常是用比較低階的硬碟,有時候甚至是用網路硬碟,Cassandra針對低轉速硬碟資料寫入最佳化的特性,大幅改善以往資料庫硬碟I/O效能瓶頸的問題。

 特性4  資料一致性程度可彈性調整以提高效能

相較於其他NoSQL資料庫,例如MongoDB與HBase等強調資料一致性的架構,Cassandra雖然強調最終一致性,但依舊有調整彈性,使用者可依需求來取捨CAP,並且決定放寬資料處理的條件,也就是對資料一致性(Consistency)、可用性(Availability)、分區容錯性(Partition Tolerance)的取捨,並藉此達到資料一致性或最終一致性。

陳彥任表示,分散式資料庫大多是從資料一致性、可用性、分區容錯性這三個面向擇其一。Cassandra的設計,則保留了兩種選擇彈性,也就是CP(資料一致性與分區容錯性)或AP(可靠性與分區容錯性),讓使用者可以根據需求來決定,哪些資料要用採取強一致性或弱一致性(最終一致性)。

力可科技的策略,是以強一致性為主,只有少數服務採取最終一致性做法,例如:搜尋用戶朋友關係的服務,就稍微放鬆資料一致性要求,力可科技的做法是每次只對兩臺主機查詢,然後比對查詢結果,如果結果不一致,才會對第三臺主機進行查詢,這種做法能讓效能與一致性的取捨達到最佳平衡。

 特色5  能跨資料中心自動備份,資料備份策略更彈性

同一筆資料寫入兩個不同的資料中心時,完全不需要另外開發程式,只需要在新增資料時,設定這個資料的複寫條件,例如:要複寫到哪一個資料中心、需要複寫多少數量等,Cassandra就會根據設定自動完成,即使網路頻寬不穩或是資料不一致,最終仍會經由複寫修復到一致。資料備份策略更加靈活,可以選擇備份在本機端的其他的節點或是備份到遠端的資料中心。

目前力可科技的Cassandra平臺,主要部署在Amazon EC2位於日本與新加坡的資料中心,其中,日本資料中心總共有6個伺服器節點,每3個節點為一組,兩組叢集之間互做備份,另外再以新加坡資料中心作異地備援。

 

 Cassandra秘技大公開 

 秘技1  用反向索引解決資料關聯問題

由於Cassandra是分散式資料庫,沒有資料結合(Join)與交易功能(Transaction)的功能,所以,針對某些應用必須另外建立反向索引機制來做資料關聯確認。例如:帳號註冊服務,可能就會有兩個人註冊同一帳號的情況,為了避免兩筆資料同時寫入,必須另外用反向索引來做檢查,換句話說,就是另外建立一個以帳號ID作為Key的資料表,當一筆新增帳號資料寫入時,也會同時寫入這個反向表來做確認。陳彥任表示,這種做法雖然無法100%完全避免資料同時寫入,但至少能過濾掉9成以上。這是Cassandra的限制,也是Cassandra使用者必須妥協的地方。

不過,Cassandra也開始提供簡單的關連式資料庫的索引功能,基於效能考量,現階段只有支援部分資料特性,例如:年齡這類資料量小,而且變化性低的資料。即使是這樣,這個新功能已經可以減少許多反向索引程式開發的工程。

 秘技2  改用本機端硬碟解決Cassandra雲端部署問題

因為Cassandra的資料架構是Key-value,一般而言,只要增加伺服器數量,就能提升資料庫效能,而且可以持續做線性增長。力可科技曾經有一次,因為流量在無法預期的情況下瞬間爆增,資料庫硬碟I/O吞吐量大,加上記憶體容量不足,然而,從資料庫效能監控系統的數據來看,硬碟資源還有二分之一,但就是無法即時調整到最佳化,使得資料庫效能大受影響。

當時,為了解決這個問題,力可科技不斷添加伺服器節點,以更大的硬體空間來換取解決問題的時間,先把服務撐住,再想辦法找出根本原因,由於Cassandra快速擴充的特性,使得這個策略立即奏效。過程中,伺服器數量從6臺開始,不斷倍數增加,最終追加到24臺。

陳彥任表示,幸好,資料庫的設計架構,原本就是橫向擴充,加上Cassandra平臺的規畫,是部署在AWS的雲端服務,所以每一次及時擴充,大約只需要一個下午時間完成參數設定,就能正式啟用新的伺服器節點,而資料庫效能也得到明顯改善。

力可科技把服務穩住後,經過多次調整架構,終於找出問題的關鍵,陳彥任推估,由於AWS的預設硬碟,是網路硬碟,而且又是在虛擬化環境執行,無法預期資源共享狀態的變化,導致系統效能時好時壞,非常不穩定,當流量暴增時,甚至會影響到所有的伺服器節點,最慢的時候,就連光碟機都還比它快。

後來,力可科技決定重新調整Cassandra的配置,一方面改用虛擬機器內的本機端硬碟(Local Disk)來取代網路硬碟,另一方面,則搭配使用保證硬碟I/O吞吐量的服務,本機端硬碟雖然快而且穩定,但是,只要虛擬機器故障,資料就會全部消失,所以,力可科技還將Cassandra部署到不同的資料中心,利用Cassandra能自動異地備援的機制來避免資料遺失,最終,才讓Cassandra的效能趨於穩定,目前伺服器的數量又回到6臺,服務承載量仍以30%的速度持續成長中。


相關報導請參考「開源資料庫的新價值」


Advertisement

更多 iThome相關內容