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

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

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

2. Autosaling的工作流程

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

1. 何時(shí)觸發(fā)Scaling即確定數(shù)據(jù)庫(kù)實(shí)例的擴(kuò)容與回縮的時(shí)機(jī)，通常的做法是通過(guò)觀測(cè)數(shù)據(jù)庫(kù)實(shí)例的性能指標(biāo)，在實(shí)例的負(fù)載高峰期執(zhí)行擴(kuò)容操作、在負(fù)載回落時(shí)執(zhí)行回縮操作，這是常見(jiàn)的Reative被動(dòng)式觸發(fā)方式，除此之外我們還實(shí)現(xiàn)了基于預(yù)測(cè)的Proactive主動(dòng)式觸發(fā)方式。關(guān)于觸發(fā)時(shí)機(jī)在2.1章節(jié)會(huì)進(jìn)行詳細(xì)的介紹。

2. Scaling的方式通常有ScaleOut（水平擴(kuò)縮容）與ScaleUp（垂直擴(kuò)縮容）兩種形式。以分布式數(shù)據(jù)庫(kù)PolarDB為例，ScaleOut的實(shí)現(xiàn)形式是增加只讀節(jié)點(diǎn)的數(shù)量，例如由2個(gè)只讀節(jié)點(diǎn)增加至4個(gè)只讀節(jié)點(diǎn)，該方式主要適用于實(shí)例負(fù)載以讀流量占主導(dǎo)的情形；ScaleUp的實(shí)現(xiàn)形式是升級(jí)實(shí)例的CPU與內(nèi)存規(guī)格，如由2核4GB升級(jí)至8核16GB，該方式主要適用于實(shí)例負(fù)載以寫流量占主導(dǎo)的情形。關(guān)于Scaling方式在2.2章節(jié)會(huì)進(jìn)行詳細(xì)的介紹。

3. 在擴(kuò)容方式確定后需要選擇合適的規(guī)格，來(lái)使實(shí)例的負(fù)載降至合理的水位。例如對(duì)于ScaleOut方式，需要確定增加多少個(gè)實(shí)例節(jié)點(diǎn)；對(duì)于ScaleUp方式，需要確定升級(jí)實(shí)例的CPU核數(shù)與內(nèi)存，以確定升級(jí)至哪種實(shí)例規(guī)格。關(guān)于擴(kuò)容規(guī)格的選擇在2.3章節(jié)會(huì)進(jìn)行詳細(xì)的介紹。

圖2. Autoscaling的工作流程圖示

2.1 Autoscaling的觸發(fā)時(shí)機(jī)

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

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

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

圖3. 被動(dòng)式觸發(fā)的擴(kuò)容資源對(duì)比圖示

2.1.2 Proactive主動(dòng)式觸發(fā)（基于預(yù)測(cè)）

解決Reactive被動(dòng)式觸發(fā)的方法便是Proactive主動(dòng)式觸發(fā)，如圖4.所示，通過(guò)對(duì)實(shí)例負(fù)載的預(yù)測(cè)，在預(yù)測(cè)實(shí)例負(fù)載即將處于高峰前的一段時(shí)間，便提前對(duì)實(shí)例執(zhí)行擴(kuò)容操作，使實(shí)例能夠平穩(wěn)度過(guò)整個(gè)業(yè)務(wù)高峰期。周期性workload是基于預(yù)測(cè)的方式中最典型的應(yīng)用場(chǎng)景（線上具有周期性特征的實(shí)例約占40%），DAS使用了達(dá)摩院智能數(shù)據(jù)庫(kù)實(shí)驗(yàn)室同學(xué)實(shí)現(xiàn)的周期性檢測(cè)算法，該算法結(jié)合了頻域和時(shí)域信息，準(zhǔn)確率達(dá)到了80%以上。例如對(duì)具有“天級(jí)別”周期性特征的線上實(shí)例，Autoscaling服務(wù)會(huì)在實(shí)例每天的業(yè)務(wù)高峰期開(kāi)始之前進(jìn)行擴(kuò)容，以使實(shí)例更好地應(yīng)對(duì)周期性的業(yè)務(wù)峰值。

圖4. 主動(dòng)式觸發(fā)的擴(kuò)容資源對(duì)比圖示

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

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

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

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

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

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

2.3 Autoscaling的規(guī)格選擇

2.3.1 ScaleUp決策算法

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

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

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

2.3.2 ScaleOut決策算法

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

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

3. 落地

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

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

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

3.2 產(chǎn)品方案

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

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

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

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

3.3 效果案例

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

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

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

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