阿里雲是幹什麼用的

1。 前言

Gartner預測到2023年，全球3/4的資料庫都會跑在雲上，雲原生資料庫最大的優勢之一便是天然擁有云計算的彈效能力，資料庫可以像水、電、煤一樣隨取隨用，而Autosaling能力便是彈性的極致體現。資料庫的Autoscaling能力是指資料庫處於業務高峰期時，自動擴容增加例項資源；在業務負載回落時，自動釋放資源以降低成本。

業界的雲廠商AWS與Azure在其部分雲資料庫上實現了Autoscaling能力，阿里雲資料庫同樣實現了其特有的Autosaling能力，該能力由資料庫核心、管控及DAS（資料庫自治服務）團隊共同構建，核心及管控團隊提供了資料庫Autoscaling的基礎能力，DAS則負責效能資料的監測、Scaling決策演算法的實現及Scaling結果的呈現。DAS（Database Autonomy Service）是一種基於機器學習和專家經驗實現資料庫自感知、自修復、自最佳化、自運維及自安全的雲服務，幫助使用者消除資料庫管理的複雜性及人工操作引發的服務故障，有效保障資料庫服務的穩定、安全及高效。其解決方案架構如圖1。所示，Autoscaling/Serverless能力在其中屬於“自運維”的部分。

圖1。 DAS的解決方案架構

2。 Autosaling的工作流程

資料庫Autoscaling整體的工作流程可定義為如圖2。所示的三個階段，即“When：何時觸發Scaling”、“How：採取哪種方式Scaling”及“What：Scaling到哪個規格”。

何時觸發Scaling即確定資料庫例項的擴容與回縮的時機，通常的做法是透過觀測資料庫例項的效能指標，在例項的負載高峰期執行擴容操作、在負載回落時執行回縮操作，這是常見的Reative被動式觸發方式，除此之外我們還實現了基於預測的Proactive主動式觸發方式。關於觸發時機在2。1章節會進行詳細的介紹。

Scaling的方式通常有ScaleOut（水平擴縮容）與ScaleUp（垂直擴縮容）兩種形式。以分散式資料庫PolarDB為例，ScaleOut的實現形式是增加只讀節點的數量，例如由2個只讀節點增加至4個只讀節點，該方式主要適用於例項負載以讀流量佔主導的情形；ScaleUp的實現形式是升級例項的CPU與記憶體規格，如由2核4GB升級至8核16GB，該方式主要適用於例項負載以寫流量佔主導的情形。關於Scaling方式在2。2章節會進行詳細的介紹。

在擴容方式確定後需要選擇合適的規格，來使例項的負載降至合理的水位。例如對於ScaleOut方式，需要確定增加多少個例項節點；對於ScaleUp方式，需要確定升級例項的CPU核數與記憶體，以確定升級至哪種例項規格。關於擴容規格的選擇在2。3章節會進行詳細的介紹。

圖2。 Autoscaling的工作流程圖示

2.1 Autoscaling的觸發時機

2。1。1 Reactive被動式觸發（基於觀察）

基於觀察的Reactive被動式觸發是當前Autoscaling主要的實現形式，由使用者為不同的例項設定不同的擴、縮容觸發條件。對於計算效能擴容，使用者可以透過設定觸發CPU閾值、觀測視窗長度、規格上限、只讀節點數量上限及靜默期等選項來配置符合業務負載的觸發條件；對於儲存空間擴容，使用者可以透過設定空間的擴容觸發閾值及擴容上限來滿足例項業務的增長，並避免磁碟資源的浪費。被動式觸發的配置選項在3。2章節會進行詳細的展示。

Reactive被動式觸發的優點是實現相對容易、使用者接受度高，但如圖3。所示，被動式觸發也存在其缺點，通常Scaling操作在達到使用者配置的觀測條件後才會真正執行，而Scaling操作的執行也需要一定的時間，在這段時間內使用者的例項可能已經處於高負載較長時間，這會在一定程度上影響使用者業務的穩定性。

圖3。 被動式觸發的擴容資源對比圖示

2。1。2 Proactive主動式觸發（基於預測）

解決Reactive被動式觸發的方法便是Proactive主動式觸發，如圖4。所示，透過對例項負載的預測，在預測例項負載即將處於高峰前的一段時間，便提前對例項執行擴容操作，使例項能夠平穩度過整個業務高峰期。週期性workload是基於預測的方式中最典型的應用場景（線上具有周期性特徵的例項約佔40%），DAS使用了達摩院智慧資料庫實驗室同學實現的週期性檢測演算法，該演算法結合了頻域和時域資訊，準確率達到了80%以上。例如對具有“天級別”週期性特徵的線上例項，Autoscaling服務會在例項每天的業務高峰期開始之前進行擴容，以使例項更好地應對週期性的業務峰值。

圖4。 主動式觸發的擴容資源對比圖示

我們同樣在RDS-MySQL的儲存空間擴容裡實現了基於預測的方式，基於例項過去一段時間的磁碟使用量指標，使用機器學習演算法預測出例項在接下來的一段時間記憶體儲空間會達到的最大值，並會根據該預測值進行擴容容量的選擇，可以避免例項空間快速增長帶來的影響。

圖5。 基於磁碟使用量趨勢的預測

2.2 Autoscaling的方式決策

DAS的Autoscaling方式有ScaleOut與ScaleUp兩種，在給出Scaling方案的同時也會結合Workload全域性決策分析模組給出更多的診斷建議（如SQL自動限流、SQL索引建議等等）。如圖6。所示是Scaling方式的決策示意圖，該示意圖以PolarDB資料庫作為示例。PolarDB資料庫採用的是計算儲存分離的一寫多讀的分散式叢集架構，一個叢集包含一個主節點和多個只讀節點，主節點處理讀寫請求，只讀節點僅處理讀請求。圖6。所示的“效能資料監測模組”會不斷的監測叢集的各項效能指標，並判斷當前時刻的例項負載是否滿足2。1章節所述的Autoscaling觸發條件，當滿足觸發條件時，會進入到圖6。中的Workload分析模組，該模組會對例項當前的Workload進行分析，透過例項的會話數量、QPS、CPU使用率、鎖等指標來判斷例項處於高負載的原因，若判斷例項是由於死鎖、大量慢SQL或大事務等原因導致的高負載，則在推薦Autoscaling建議的同時也會推出SQL限流或SQL最佳化建議，使例項迅速故障自愈以降低風險。

在Autoscaling方式的決策生成模組，會判斷採取何種Scaling方式更有效。以PolarDB資料庫為例，該模組會透過例項的效能指標以及例項的主庫保護、事務拆分、系統語句、聚合函式或自定義叢集等特徵來判斷叢集當前的負載分佈，若判斷例項當前以讀流量佔主導，則會執行ScaleOut操作增加叢集的只讀節點數量；若判斷例項當前以寫流量佔主導，則會執行ScaleUp操作來升級叢集的規格。ScaleOut與ScaleUp決策的選擇是一個很複雜的問題，除了考慮例項當前的負載分佈外，還需要考慮到使用者設定的擴容規格上限及只讀節點數量上限，為此我們也引入了一個效果追蹤與決策反饋模組，在每次決策判斷時，會分析該例項歷史上的擴容方式及擴容效果，以此來對當前的Scaling方式選擇演算法進行一定的調整。

圖6。 PolarDB的Scaling方式決策示意圖

2.3 Autoscaling的規格選擇

2。3。1 ScaleUp決策演算法

ScaleUp決策演算法是指當確定對資料庫例項執行ScaleUp操作時，根據例項的workload負載及例項元資料等資訊，為當前例項選擇合適的規格引數，以使例項當前的workload達到給定的約束。最開始DAS Autoscaling的ScaleUp決策演算法基於規則實現，以PolarDB資料庫為例，PolarDB叢集當前有8種例項規格，採用基於規則的決策演算法在前期足夠用；但同時我們也探索了基於機器學習/深度學習的分類模型，因為隨著資料庫技術最終迭代至Serverless狀態，資料庫的可用規格數量會非常龐大，分類演算法在這種場景下會有很大的用武之地。如圖7。及圖8。所示，我們當前實現了基於效能資料的資料庫規格離線訓練模型及實時推薦模型，透過對自定義CPU使用率的範圍標註，參考DAS之前落地的AutoTune自動調參演算法，在標註資料集進行模型分類，並透過實現的proxy流量轉發工具進行驗證，當前的分類演算法已經取得了超過80%的準確率。

圖7。 基於效能資料的資料庫規格ScaleUp模型離線訓練示意圖

圖8。 基於效能資料的資料庫規格ScaleUp實時推薦方法示意圖

2。3。2 ScaleOut決策演算法

ScaleOut決策演算法與ScaleUp決策演算法的思路類似，本質問題是確定增加多少個只讀節點，能使例項當前的workload負載降至合理的水位。在ScaleOut決策演算法裡，我們同樣實現了基於規則的與基於分類的演算法，分類演算法的思想與2。3。1章節裡描述的基本類似，基於規則的演算法思想則如圖9。所示，首先我們需要確定與讀流量最相關的指標，這裡選取的是com_select、qps及rows_read指標，s_i表示第i個節點讀相關指標的表徵值，c_i表示第i個節點的目標約束表徵值（通常使用CPU使用率、RT等直接反應業務效能的指標），f指目標函式，演算法的目標便是確定增加多少個只讀節點X，能使整個叢集的負載降至f函式確定的範圍。該計算方法明確且有效，演算法上線後，以變配後集群的CPU負載是否降至合理水位作為評估條件，演算法的準確率達到了85%以上，在確定採取ScaleOut變配方式後，ScaleOut決策演算法新增的只讀節點基本都能處於“恰好飽和”的工作負載，能夠有效的提升資料庫例項的吞吐。

圖9。 基於效能資料的資料庫節點數量ScaleOut推薦演算法示意圖

3。 落地

3.1 實現架構

Autoscaling能力整合在DAS服務裡，整個服務涉及異常檢測、全域性決策、Autoscaling服務、底層管控執行多個模組，如圖10。所示是DAS Autoscaling的服務能力架構。異常檢測模組是DAS所有診斷最佳化服務（Autoscaling、SQL限流、SQL最佳化、空間最佳化等）的入口，該模組會7*24小時對監控指標、SQL、鎖、日誌及運維事件等進行實時檢測，並會基於AI的演算法對其中的趨勢如Spike、Seasonaliy、Trend及Meanshift等進行預測及分析；DAS的全域性決策模組會根據例項當前的workload負載給出最佳的診斷建議；當由全域性決策模組確定執行Autoscaling操作時，則會進入到第2章節介紹的Autoscaling工作流程，最終透過資料庫底層的管控服務來實現例項的擴、縮容。

圖10。 DAS及AutoScaling的服務能力架構

3.2 產品方案

本章節將介紹Autoscaling功能在DAS裡的開啟方式。如圖11。所示是DAS的阿里雲官網產品首頁，在該介面可以看到DAS提供的所有功能，如“例項監控”、“請求分析”、“智慧壓測”等等，點選“例項監控”選項可以檢視使用者接入的所有資料庫例項。我們點選具體的例項id連結並選擇“自治中心”選項，可以看到如圖12。及圖13。所示的PolarDB自動擴、縮容設定及RDS-MySQL自動擴容設定，對於PolarDB例項，使用者可以設定擴容規格上限、只讀節點數量上限、觀測視窗及靜默期等選項，對於RDS-MySQL例項，使用者可以設定觸發閾值、規格上限及儲存容量上限等選項。

圖11。 DAS產品首頁

圖12。 PolarDB自動擴、縮容設定圖示

圖13。 RDS-MySQL自動擴、縮容設定圖示

3.3 效果案例

本章節將介紹兩個具體的線上案例。如圖14。所示為線上PolarDB例項的計算規格Autoscaling觸發示意圖，在05：00-07：00的時間段，例項的負載慢慢上升，最終CPU使用率超過了80%，在07：00時觸發了自動擴容操作，後臺的Autoscaling服務判斷例項當前讀流量佔主導，於是執行了ScaleOut操作，為叢集增加了兩個只讀節點，透過圖示可以看到，增加節點後集群的負載明顯下降，CPU使用率降至了50%左右；在之後的2個小時裡，例項的業務流量繼續增加，導致例項負載繼續在緩慢上升，於是在09：00的時候再次達到了擴容的觸發條件，此時後臺服務判斷例項當前寫流量佔主導，於是執行了ScaleUp操作，將叢集的規格由4核8GB升級到8核16GB，由圖示可以看到規格升級後例項的負載趨於穩定，並維持了近17個小時，之後例項的負載下降並觸發了自動回縮操作，後臺Autoscaling服務將例項的規格由8核16GB降至4核8GB，並減少了兩個只讀節點。Autoscaing服務在後臺會自動執行，無需人工干預，在負載高峰期擴容、在負載低谷時回縮，提升業務穩定性的同時降低了使用者的成本。

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

如圖15。所示為線上RDS-MySQL例項的儲存空間自動擴容示意圖，左側圖表示例項在近3個小時內觸發了3次磁碟空間擴容操作、累計擴容近300GB，右側是磁碟空間的增長示意圖，可以發現在例項儲存空間迅速增長時，空間自動擴容操作能夠無縫執行，真正做到了隨用隨取，在避免例項空間打滿的同時節省了使用者的成本。

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

原文連結：http://click.aliyun.com/m/1000282741/

本文為阿里雲原創內容，未經允許不得轉載。