全球分布式云聯(lián)盟力求打造分布式云計算旗艦級技術盛會,本次大會共設有分布式云報告會、邊緣計算論壇、Serverless云原生論壇、分布式數(shù)據(jù)庫論壇、分布式存儲論壇,跨境SD-WAN咨詢會等六大論壇,圍繞分布式云、分布式算力、Serverless、云原生、HTAP、IPFS等技術與實踐展開。聯(lián)合阿里云、騰訊云、百度云、金山云等全棧技術引領者與全球分布式云聯(lián)盟攜手打造這場技術饕餮盛宴。
01?Serverless數(shù)據(jù)庫特點
計算服務的演進也是類似,從前自建機房,需要維護機房設備;后來可以在云上直接購買虛擬機,部署業(yè)務,負責服務的擴縮容;現(xiàn)在的函數(shù)計算,從CI/CD到服務部署,擴縮容,全部自動完成,客戶可以更專注于業(yè)務代碼。
狹義的serverless分為FaaS和BaaS,基本特點是無需運維、以API方式提供服務、按實際使用計費、無使用無費用等。
舉個例子,用戶瀏覽網(wǎng)頁,可能涉及CDN資源。如果是靜態(tài)內(nèi)容,從對象存儲下載照片、視頻;如果是動態(tài)內(nèi)容,則觸發(fā)一個函數(shù)計算,云函數(shù)將從云數(shù)據(jù)庫獲取相應的資源,生成用戶所需的動態(tài)內(nèi)容。其中,云函數(shù)為FaaS,對象存儲和云數(shù)據(jù)庫則為BaaS。
傳統(tǒng)的云數(shù)據(jù)庫會提供多種內(nèi)存/CPU規(guī)格給用戶購買。即使無法時刻用滿負載,用戶也需要為選中的規(guī)格付費。如果要將數(shù)據(jù)庫serverless化,需要滿足以下三大特性:
第二、按照實際使用的資源付費。
第三、不使用不計費。如果沒有訪問,不應該收費。
圖左側(cè)是目前的主流架構—單體冗余架構(一主多從),是現(xiàn)在大部分客戶使用的架構。這類架構存在擴展性問題,實例的升降級和讀擴展,都通過數(shù)據(jù)搬遷實現(xiàn),隨著數(shù)據(jù)量的增長,遷移耗時越來越長。
為了解決這個問題,業(yè)界趨勢是采用存算分離架構,衍生出兩類,一類是ShareNothing架構,計算和存儲均支持水平擴展,擴展能力非常強。不過,也存在一些缺點,其中最大的問題是SQL兼容性,解決之道在于持續(xù)構建和完善自己的生態(tài),讓用戶更好的接受提供的用法;
另一類則是ShareStorage架構,共享存儲架構并沒有改變查詢引擎和ACI這些基礎特性,可以做到100%的兼容性。當然它也有缺點,目前計算節(jié)點沒有提供寫擴展能力,這個也是未來演進的方向。
隨后,李志陽又關注到了Serverless數(shù)據(jù)庫的用戶群,主要面向中長尾用戶,他們對擴展性的訴求并不強,更多關注使用的便利性,兼容性是最重要一點。
因此,騰訊云優(yōu)先選擇了基于共享存儲架構的數(shù)據(jù)庫產(chǎn)品TDSQL-C提供Serverless服務。
在計算層使用了騰訊維護的MySQL內(nèi)核分支-TXSQL,復用它的bugfix和新特性;存儲側(cè)則選擇了在騰訊內(nèi)部有十幾年歷史的云硬盤CBS,把CBS的核心存儲和硬盤邏輯進行剖離,打造了統(tǒng)一存儲平臺-HiSTOR。
作為存儲底座,已適配了云硬盤CBS、云分布式文件系統(tǒng)CFS和數(shù)據(jù)庫TDSQL-C等多款產(chǎn)品,提供副本同步、故障自動遷移、數(shù)據(jù)校驗等一系列完善的數(shù)據(jù)安全保障能力,這正是TDSQL-C產(chǎn)品能夠穩(wěn)定運行數(shù)年的重要基石。
另外,它還提供豐富的特性:備份/回檔速度,支持以MB為粒度并發(fā),速度達到GB/s;除了高性能的SSD,還有混存和EC版本,應對歸檔類的業(yè)務,提供更低成本的存儲。
除了上述兩個關鍵組件,我們還在計算側(cè)實現(xiàn)了物理復制,將innodb的redo日志準實時同步到備機,主從延時非常低(小于1毫秒);相比傳統(tǒng)數(shù)據(jù)庫先寫日志后異步刷臟,TDSQL-C只寫日志到存儲,存儲側(cè)通過dbstore模塊將日志轉(zhuǎn)化數(shù)據(jù)。日志下沉的優(yōu)點很多,這里不做贅述。
由于騰訊云是國內(nèi)首家提供Serverless數(shù)據(jù)庫的廠家,李志陽主要對比了國外AWS的同類產(chǎn)品Aurora Serverless,并分析如何實現(xiàn)serverless數(shù)據(jù)庫的三大特性。
一、自動擴縮容
上圖右側(cè)有一個共享的虛擬機池,規(guī)格不盡相同。Aurora Serverless的擴容策略是從1核2G到4核8G逐步遞增規(guī)格。例如需要從1核2G擴大到2核4G,則從池子里面找到2核4G的虛擬機,將對應的數(shù)據(jù)盤掛載到虛擬機,并將訪問切到該虛擬機,即可完成自動擴容。
有2個問題:1、假設用戶訪問本身需要4核8G,Aurora Serverless仍需要從1核2G開始逐步增加到4核8G,擴容耗時偏長;2、由于選擇新的虛擬機擴容,會導致BP失效,訪問將經(jīng)歷一次冷啟動過程。
二、按使用量計費
實現(xiàn)比較簡單,秒級粒度統(tǒng)計正在使用的規(guī)格,按照該規(guī)格計費。
三、不使用不計費
如果實例超過一段時間沒有訪問,則關閉計算節(jié)點。由于有數(shù)據(jù)庫代理節(jié)點作為接入層,如果用戶再有訪問請求,會先到達數(shù)據(jù)庫代理節(jié)點。
此時,代理節(jié)點按照上面提到的方法,從共享池里面找到對應的虛擬機提供服務。對用戶而言,原有連接不受到影響,只是感覺到一次卡頓。缺點是引入了代理節(jié)點,用戶需要為此付費;另外,恢復時長需要30秒,耗時也比較長。
擴容時BP失效導致的問題
上圖為總體架構,核心模塊為中控節(jié)點(svls scheduler)。
中控節(jié)點接收計算層采集的內(nèi)存/CPU/訪問情況等監(jiān)控數(shù)據(jù),根據(jù)策略決定是否擴縮容,啟停實例,以及按照計費規(guī)則上報云控制臺計費。
相對Aurora Serverless的區(qū)別在于暫停的應對,TDSQL-C Serverless有faker模塊,暫停計算節(jié)點時會把四層的vip:vport綁定到faker端口,用戶請求過來后,識別為有效的MySQL協(xié)議,則通知中控模塊將實例重新拉起。其優(yōu)點在于用戶不需要為代理節(jié)點付費。
隨后,李志陽詳細解釋了TDSQL-C Serverless如何滿足serverless數(shù)據(jù)庫的三大特性。
一、?自動擴縮容:
目標是做到秒級的擴縮容,并且期間對用戶是平滑的,無感知的。
以上圖為例子,用戶在購買時選擇最小規(guī)格為1核2G,最大規(guī)格為2核4G。左邊為Aurora Serverless,矩形的縱坐標是CPU,橫坐標為內(nèi)存。
初始為1核2G,當業(yè)務訪問過來,把CPU用滿了,持續(xù)一段時間才擴容到2核4G;而右側(cè)的TDSQL-C Serverless,初始就給用戶提供最大CPU規(guī)格,內(nèi)存則從最小規(guī)格開始。假設用戶使用的CPU超過1核,并持續(xù)一段時間,將把內(nèi)存從2G擴到4G。
可以看出,TDSQL-C Serverless的CPU資源不會受限,可以在設置的最大規(guī)格內(nèi)任意使用。優(yōu)點是用戶性能不受限,引入的缺點是可能整機出現(xiàn)滿負載。
由于TDSQL-C采用存算分離架構,一旦監(jiān)控到整機資源超過閾值,就進行快速遷移。遷移其實就是在另外一臺相對空閑的機器重新拉起實例,秒級完成。在資源負載上可以精準控制。
另外,現(xiàn)在云數(shù)據(jù)庫整機利用率偏低?;谶@兩點,TDSQL-C Serverless可以很好應對。
二、?按使用量計費:
我們定義了一個算力單元CCU(TDSQL-C Compute Unit)=max{CPU,MEM/2,最小規(guī)格}。其中,MEM/2的含義是,由于我們定義的規(guī)格CPU/內(nèi)存比都是1/2,內(nèi)存除以2相當于把內(nèi)存換算成CPU。
整體還是以CPU決定整個算力。我們通過計算每個小時CCU平均值給用戶計費。
舉例說,假設用戶選擇最小最大規(guī)格為0.25核-4核,從圖中可以看到,業(yè)務高峰過來,一開始就能用到3核,右側(cè)CCU也會按照3核計費,能夠很好的應對業(yè)務負載。
三、?不使用無計費:
自動啟停的邏輯比較簡單,只要10分鐘(用戶可配)內(nèi)監(jiān)測到?jīng)]有訪問就回收掉計算節(jié)點,訪問回來就把節(jié)點重新拉起。
最核心的點是怎么做到快速恢復,之前提過TDSQL-C是日志下沉的,存儲側(cè)接收到日志之后會源源不斷的回放,數(shù)據(jù)庫計算節(jié)點在啟動的過程中,不需要像傳統(tǒng)數(shù)據(jù)庫那樣加載到日志然后重放,所以啟動相對比較簡單和快速。
具體來說,VDL表示已經(jīng)持久化的日志點。在運行階段會不斷異步持久化VDL(last-vdl)。Recovery階段,首先獲取last-vdl(checkpoint點),然后廣播所有相關的小表獲取大于等于last-vdl的所有日志段,最后通過敗者樹找到最后連續(xù)的日志點作為VDL。整個過程都是并行化的,而且沒有數(shù)據(jù)重放,耗時小于100毫秒。
另外,我們還對MySQL啟動過程做了多處并行化處理,目前可以2秒內(nèi)恢復實例。
同時,為了進一步降低用戶的存儲成本,如果很長時間沒有訪問,將數(shù)據(jù)轉(zhuǎn)存到對象存儲COS,屆時用戶只需要付COS的費用即可。最后,歡迎大家多多使用TDSQL-C Serverless!