力可科技導入Cassandra開源資料庫 10分鐘能擴充20萬人用量

相較於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％的速度持續成長中。

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