1. 前言

Gartner預(yù)測到2023年，全球3/4的數(shù)據(jù)庫都會跑在云上，云原生數(shù)據(jù)庫最大的優(yōu)勢之一便是天然擁有云計算的彈性能力，數(shù)據(jù)庫可以像水、電、煤一樣隨取隨用，而Autosaling能力便是彈性的極致體現(xiàn)。數(shù)據(jù)庫的Autoscaling能力是指數(shù)據(jù)庫處于業(yè)務(wù)高峰期時，自動擴容增加實例資源；在業(yè)務(wù)負(fù)載回落時，自動釋放資源以降低成本。

業(yè)界的云廠商AWS與Azure在其部分云數(shù)據(jù)庫上實現(xiàn)了Autoscaling能力，阿里云數(shù)據(jù)庫同樣實現(xiàn)了其特有的Autosaling能力，該能力由數(shù)據(jù)庫內(nèi)核、管控及DAS（數(shù)據(jù)庫自治服務(wù)）團(tuán)隊共同構(gòu)建，內(nèi)核及管控團(tuán)隊提供了數(shù)據(jù)庫Autoscaling的基礎(chǔ)能力，DAS則負(fù)責(zé)性能數(shù)據(jù)的監(jiān)測、Scaling決策算法的實現(xiàn)及Scaling結(jié)果的呈現(xiàn)。DAS（Database Autonomy Service）是一種基于機器學(xué)習(xí)和專家經(jīng)驗實現(xiàn)數(shù)據(jù)庫自感知、自修復(fù)、自優(yōu)化、自運維及自安全的云服務(wù)，幫助用戶消除數(shù)據(jù)庫管理的復(fù)雜性及人工操作引發(fā)的服務(wù)故障，有效保障數(shù)據(jù)庫服務(wù)的穩(wěn)定、安全及高效。其解決方案架構(gòu)如圖1.所示，Autoscaling/Serverless能力在其中屬于“自運維”的部分。

圖1. DAS的解決方案架構(gòu)

2. Autosaling的工作流程

數(shù)據(jù)庫Autoscaling整體的工作流程可定義為如圖2.所示的三個階段，即“When：何時觸發(fā)Scaling”、“How：采取哪種方式Scaling”及“What：Scaling到哪個規(guī)格”。

何時觸發(fā)Scaling即確定數(shù)據(jù)庫實例的擴容與回縮的時機，通常的做法是通過觀測數(shù)據(jù)庫實例的性能指標(biāo)，在實例的負(fù)載高峰期執(zhí)行擴容操作、在負(fù)載回落時執(zhí)行回縮操作，這是常見的Reative被動式觸發(fā)方式，除此之外我們還實現(xiàn)了基于預(yù)測的Proactive主動式觸發(fā)方式。關(guān)于觸發(fā)時機在2.1章節(jié)會進(jìn)行詳細(xì)的介紹。
Scaling的方式通常有ScaleOut（水平擴縮容）與ScaleUp（垂直擴縮容）兩種形式。以分布式數(shù)據(jù)庫PolarDB為例，ScaleOut的實現(xiàn)形式是增加只讀節(jié)點的數(shù)量，例如由2個只讀節(jié)點增加至4個只讀節(jié)點，該方式主要適用于實例負(fù)載以讀流量占主導(dǎo)的情形；ScaleUp的實現(xiàn)形式是升級實例的CPU與內(nèi)存規(guī)格，如由2核4GB升級至8核16GB，該方式主要適用于實例負(fù)載以寫流量占主導(dǎo)的情形。關(guān)于Scaling方式在2.2章節(jié)會進(jìn)行詳細(xì)的介紹。
在擴容方式確定后需要選擇合適的規(guī)格，來使實例的負(fù)載降至合理的水位。例如對于ScaleOut方式，需要確定增加多少個實例節(jié)點；對于ScaleUp方式，需要確定升級實例的CPU核數(shù)與內(nèi)存，以確定升級至哪種實例規(guī)格。關(guān)于擴容規(guī)格的選擇在2.3章節(jié)會進(jìn)行詳細(xì)的介紹。

圖2. Autoscaling的工作流程圖示

2.1 Autoscaling的觸發(fā)時機

2.1.1 Reactive被動式觸發(fā)（基于觀察）

基于觀察的Reactive被動式觸發(fā)是當(dāng)前Autoscaling主要的實現(xiàn)形式，由用戶為不同的實例設(shè)置不同的擴、縮容觸發(fā)條件。對于計算性能擴容，用戶可以通過設(shè)置觸發(fā)CPU閾值、觀測窗口長度、規(guī)格上限、只讀節(jié)點數(shù)量上限及靜默期等選項來配置符合業(yè)務(wù)負(fù)載的觸發(fā)條件；對于存儲空間擴容，用戶可以通過設(shè)置空間的擴容觸發(fā)閾值及擴容上限來滿足實例業(yè)務(wù)的增長，并避免磁盤資源的浪費。被動式觸發(fā)的配置選項在3.2章節(jié)會進(jìn)行詳細(xì)的展示。

Reactive被動式觸發(fā)的優(yōu)點是實現(xiàn)相對容易、用戶接受度高，但如圖3.所示，被動式觸發(fā)也存在其缺點，通常Scaling操作在達(dá)到用戶配置的觀測條件后才會真正執(zhí)行，而Scaling操作的執(zhí)行也需要一定的時間，在這段時間內(nèi)用戶的實例可能已經(jīng)處于高負(fù)載較長時間，這會在一定程度上影響用戶業(yè)務(wù)的穩(wěn)定性。

圖4. 主動式觸發(fā)的擴容資源對比圖示

我們同樣在RDS-MySQL的存儲空間擴容里實現(xiàn)了基于預(yù)測的方式，基于實例過去一段時間的磁盤使用量指標(biāo)，使用機器學(xué)習(xí)算法預(yù)測出實例在接下來的一段時間內(nèi)存儲空間會達(dá)到的最大值，并會根據(jù)該預(yù)測值進(jìn)行擴容容量的選擇，可以避免實例空間快速增長帶來的影響。

圖5. 基于磁盤使用量趨勢的預(yù)測

2.2 Autoscaling的方式?jīng)Q策

DAS的Autoscaling方式有ScaleOut與ScaleUp兩種，在給出Scaling方案的同時也會結(jié)合Workload全局決策分析模塊給出更多的診斷建議（如SQL自動限流、SQL索引建議等等）。如圖6.所示是Scaling方式的決策示意圖，該示意圖以PolarDB數(shù)據(jù)庫作為示例。PolarDB數(shù)據(jù)庫采用的是計算存儲分離的一寫多讀的分布式集群架構(gòu)，一個集群包含一個主節(jié)點和多個只讀節(jié)點，主節(jié)點處理讀寫請求，只讀節(jié)點僅處理讀請求。圖6.所示的“性能數(shù)據(jù)監(jiān)測模塊”會不斷的監(jiān)測集群的各項性能指標(biāo)，并判斷當(dāng)前時刻的實例負(fù)載是否滿足2.1章節(jié)所述的Autoscaling觸發(fā)條件，當(dāng)滿足觸發(fā)條件時，會進(jìn)入到圖6.中的Workload分析模塊，該模塊會對實例當(dāng)前的Workload進(jìn)行分析，通過實例的會話數(shù)量、QPS、CPU使用率、鎖等指標(biāo)來判斷實例處于高負(fù)載的原因，若判斷實例是由于死鎖、大量慢SQL或大事務(wù)等原因?qū)е碌母哓?fù)載，則在推薦Autoscaling建議的同時也會推出SQL限流或SQL優(yōu)化建議，使實例迅速故障自愈以降低風(fēng)險。

在Autoscaling方式的決策生成模塊，會判斷采取何種Scaling方式更有效。以PolarDB數(shù)據(jù)庫為例，該模塊會通過實例的性能指標(biāo)以及實例的主庫保護(hù)、事務(wù)拆分、系統(tǒng)語句、聚合函數(shù)或自定義集群等特征來判斷集群當(dāng)前的負(fù)載分布，若判斷實例當(dāng)前以讀流量占主導(dǎo)，則會執(zhí)行ScaleOut操作增加集群的只讀節(jié)點數(shù)量；若判斷實例當(dāng)前以寫流量占主導(dǎo)，則會執(zhí)行ScaleUp操作來升級集群的規(guī)格。ScaleOut與ScaleUp決策的選擇是一個很復(fù)雜的問題，除了考慮實例當(dāng)前的負(fù)載分布外，還需要考慮到用戶設(shè)置的擴容規(guī)格上限及只讀節(jié)點數(shù)量上限，為此我們也引入了一個效果追蹤與決策反饋模塊，在每次決策判斷時，會分析該實例歷史上的擴容方式及擴容效果，以此來對當(dāng)前的Scaling方式選擇算法進(jìn)行一定的調(diào)整。

圖6. PolarDB的Scaling方式?jīng)Q策示意圖

2.3 Autoscaling的規(guī)格選擇

2.3.1 ScaleUp決策算法

ScaleUp決策算法是指當(dāng)確定對數(shù)據(jù)庫實例執(zhí)行ScaleUp操作時，根據(jù)實例的workload負(fù)載及實例元數(shù)據(jù)等信息，為當(dāng)前實例選擇合適的規(guī)格參數(shù)，以使實例當(dāng)前的workload達(dá)到給定的約束。最開始DAS Autoscaling的ScaleUp決策算法基于規(guī)則實現(xiàn)，以PolarDB數(shù)據(jù)庫為例，PolarDB集群當(dāng)前有8種實例規(guī)格，采用基于規(guī)則的決策算法在前期足夠用；但同時我們也探索了基于機器學(xué)習(xí)/深度學(xué)習(xí)的分類模型，因為隨著數(shù)據(jù)庫技術(shù)最終迭代至Serverless狀態(tài)，數(shù)據(jù)庫的可用規(guī)格數(shù)量會非常龐大，分類算法在這種場景下會有很大的用武之地。如圖7.及圖8.所示，我們當(dāng)前實現(xiàn)了基于性能數(shù)據(jù)的數(shù)據(jù)庫規(guī)格離線訓(xùn)練模型及實時推薦模型，通過對自定義CPU使用率的范圍標(biāo)注，參考DAS之前落地的AutoTune自動調(diào)參算法，在標(biāo)注數(shù)據(jù)集進(jìn)行模型分類，并通過實現(xiàn)的proxy流量轉(zhuǎn)發(fā)工具進(jìn)行驗證，當(dāng)前的分類算法已經(jīng)取得了超過80%的準(zhǔn)確率。

圖7. 基于性能數(shù)據(jù)的數(shù)據(jù)庫規(guī)格ScaleUp模型離線訓(xùn)練示意圖

圖8. 基于性能數(shù)據(jù)的數(shù)據(jù)庫規(guī)格ScaleUp實時推薦方法示意圖

2.3.2 ScaleOut決策算法

ScaleOut決策算法與ScaleUp決策算法的思路類似，本質(zhì)問題是確定增加多少個只讀節(jié)點，能使實例當(dāng)前的workload負(fù)載降至合理的水位。在ScaleOut決策算法里，我們同樣實現(xiàn)了基于規(guī)則的與基于分類的算法，分類算法的思想與2.3.1章節(jié)里描述的基本類似，基于規(guī)則的算法思想則如圖9.所示，首先我們需要確定與讀流量最相關(guān)的指標(biāo)，這里選取的是com_select、qps及rows_read指標(biāo)，s_i表示第i個節(jié)點讀相關(guān)指標(biāo)的表征值，c_i表示第i個節(jié)點的目標(biāo)約束表征值（通常使用CPU使用率、RT等直接反應(yīng)業(yè)務(wù)性能的指標(biāo)），f指目標(biāo)函數(shù)，算法的目標(biāo)便是確定增加多少個只讀節(jié)點X，能使整個集群的負(fù)載降至f函數(shù)確定的范圍。該計算方法明確且有效，算法上線后，以變配后集群的CPU負(fù)載是否降至合理水位作為評估條件，算法的準(zhǔn)確率達(dá)到了85%以上，在確定采取ScaleOut變配方式后，ScaleOut決策算法新增的只讀節(jié)點基本都能處于“恰好飽和”的工作負(fù)載，能夠有效的提升數(shù)據(jù)庫實例的吞吐。

圖9. 基于性能數(shù)據(jù)的數(shù)據(jù)庫節(jié)點數(shù)量ScaleOut推薦算法示意圖

3. 落地

3.1 實現(xiàn)架構(gòu)

Autoscaling能力集成在DAS服務(wù)里，整個服務(wù)涉及異常檢測、全局決策、Autoscaling服務(wù)、底層管控執(zhí)行多個模塊，如圖10.所示是DAS Autoscaling的服務(wù)能力架構(gòu)。異常檢測模塊是DAS所有診斷優(yōu)化服務(wù)（Autoscaling、SQL限流、SQL優(yōu)化、空間優(yōu)化等）的入口，該模塊會7*24小時對監(jiān)控指標(biāo)、SQL、鎖、日志及運維事件等進(jìn)行實時檢測，并會基于AI的算法對其中的趨勢如Spike、Seasonaliy、Trend及Meanshift等進(jìn)行預(yù)測及分析；DAS的全局決策模塊會根據(jù)實例當(dāng)前的workload負(fù)載給出最佳的診斷建議；當(dāng)由全局決策模塊確定執(zhí)行Autoscaling操作時，則會進(jìn)入到第2章節(jié)介紹的Autoscaling工作流程，最終通過數(shù)據(jù)庫底層的管控服務(wù)來實現(xiàn)實例的擴、縮容。

圖10. DAS及AutoScaling的服務(wù)能力架構(gòu)

3.2 產(chǎn)品方案

本章節(jié)將介紹Autoscaling功能在DAS里的開啟方式。如圖11.所示是DAS的阿里云官網(wǎng)產(chǎn)品首頁，在該界面可以看到DAS提供的所有功能，如“實例監(jiān)控”、“請求分析”、“智能壓測”等等，點擊“實例監(jiān)控”選項可以查看用戶接入的所有數(shù)據(jù)庫實例。我們點擊具體的實例id鏈接并選擇“自治中心”選項，可以看到如圖12.及圖13.所示的PolarDB自動擴、縮容設(shè)置及RDS-MySQL自動擴容設(shè)置，對于PolarDB實例，用戶可以設(shè)置擴容規(guī)格上限、只讀節(jié)點數(shù)量上限、觀測窗口及靜默期等選項，對于RDS-MySQL實例，用戶可以設(shè)置觸發(fā)閾值、規(guī)格上限及存儲容量上限等選項。

圖11. DAS產(chǎn)品首頁

圖12. PolarDB自動擴、縮容設(shè)置圖示

圖13. RDS-MySQL自動擴、縮容設(shè)置圖示

3.3 效果案例

本章節(jié)將介紹兩個具體的線上案例。如圖14.所示為線上PolarDB實例的計算規(guī)格Autoscaling觸發(fā)示意圖，在05:00-07:00的時間段，實例的負(fù)載慢慢上升，最終CPU使用率超過了80%，在07:00時觸發(fā)了自動擴容操作，后臺的Autoscaling服務(wù)判斷實例當(dāng)前讀流量占主導(dǎo)，于是執(zhí)行了ScaleOut操作，為集群增加了兩個只讀節(jié)點，通過圖示可以看到，增加節(jié)點后集群的負(fù)載明顯下降，CPU使用率降至了50%左右；在之后的2個小時里，實例的業(yè)務(wù)流量繼續(xù)增加，導(dǎo)致實例負(fù)載繼續(xù)在緩慢上升，于是在09:00的時候再次達(dá)到了擴容的觸發(fā)條件，此時后臺服務(wù)判斷實例當(dāng)前寫流量占主導(dǎo)，于是執(zhí)行了ScaleUp操作，將集群的規(guī)格由4核8GB升級到8核16GB，由圖示可以看到規(guī)格升級后實例的負(fù)載趨于穩(wěn)定，并維持了近17個小時，之后實例的負(fù)載下降并觸發(fā)了自動回縮操作，后臺Autoscaling服務(wù)將實例的規(guī)格由8核16GB降至4核8GB，并減少了兩個只讀節(jié)點。Autoscaing服務(wù)在后臺會自動運行，無需人工干預(yù)，在負(fù)載高峰期擴容、在負(fù)載低谷時回縮，提升業(yè)務(wù)穩(wěn)定性的同時降低了用戶的成本。

圖14. 線上PolarDB 水平擴容、垂直擴容效果示意圖

如圖15.所示為線上RDS-MySQL實例的存儲空間自動擴容示意圖，左側(cè)圖表示實例在近3個小時內(nèi)觸發(fā)了3次磁盤空間擴容操作、累計擴容近300GB，右側(cè)是磁盤空間的增長示意圖，可以發(fā)現(xiàn)在實例存儲空間迅速增長時，空間自動擴容操作能夠無縫執(zhí)行，真正做到了隨用隨取，在避免實例空間打滿的同時節(jié)省了用戶的成本。

圖15. 線上RDS-MySQL空間擴容效果示意圖

原文鏈接：http://click.aliyun.com/m/1000282741/