這些複雜的運維難題最優解到底是什麼？
今天（4月22日）15:00
數據庫自治服務DAS重磅發佈會
現場為你揭曉答案！
數據庫自動駕駛時代一觸即發
觀看直播：阿里雲新品發佈會第90期：數據庫自治服務DAS重磅新品發佈會-技術公開課-阿里雲開發者社區
今天提前為大家揭秘數據庫自治服務DAS的一個創新功能 —— AutoScale，基於數據庫實例的實時性能數據作為輸入，由DAS完成流量異常發現、合理數據庫規格建議和合理磁盤容量建議，使數據庫服務具備自動擴展存儲和計算資源的能力。
01、背 景
為業務應用選擇一個合適的數據庫規格，是每個數據庫運維同學都會經常面臨的一個問題。若規格選的過大，會產生資源浪費；若規格選的過小，計算性能不足會影響業務。
通常情況下，運維同學會採用業務平穩運行狀態下，CPU可處於合理水位（例如50%以下）的一個規格（如4核CPU配8G內存）並配一個相對富餘的磁盤規格（如200G）。
然而在數據庫應用運維同學的日常生活裡，線上應用流量突增導致數據庫資源打滿的情況時有發生，而引發這類問題的場景可能多種多樣：
1、新業務上線，對業務流量預估不足，導致資源打滿，如新上線的應用接入了大量的引流，或基礎流量比較大的平臺上線了一個新特性功能。
2、不可預知的流量，如突發的輿論熱點帶來的臨時流量，或某個網紅引發的限時搶購、即興話題等。
3、一些平時運行頻次不高，但又偶發集中式訪問，如每日一次的上班打卡場景，或每週執行幾次的財務核算業務。這類業務場景平時業務壓力不高，雖已知會存在訪問高峰，但為節省資源而通常不會分配較高的規格。
當上述業務場景突發計算資源不足狀況時，通常會讓運維同學措手不及，嚴重影響業務，如何應對“數據庫資源打滿”是運維同學常常被挑戰的問題之一。
在數據庫場景下，資源打滿可分為計算資源和存儲資源兩大類，其主要表現：
1、計算資源打滿，主要表現為CPU資源利用率達到100%，當前規格下的計算能力不足以應對；
2、存儲資源打滿，主要表現為磁盤空間使用率達到100%，數據庫寫入的數據量達到當前規格下的磁盤空間限制，導致業務無法寫入新數據；
針對上述兩類問題，數據庫自治服務 DAS 進行了服務創新，使數據庫服務具備自動擴展存儲和計算資源的技術能力，應對上述的問題。
DAS AutoScale基於數據庫實例的實時性能數據作為輸入，由DAS完成流量異常發現、合理數據庫規格建議和合理磁盤容量建議，使數據庫服務具備自動擴展存儲和計算資源的能力。
接下來，本文將對DAS AutoScale服務的架構進行詳細的介紹，包括技術挑戰、解決方案和關鍵技術。
02、技術挑戰
計算節點規格調整是數據庫優化的一種常用手段，儘管計算資源規格只涉及到CPU和內存，但在生產環境進行規格變配的影響還是不容忽視，將涉及數據遷移、HA切換、Proxy切換等操作，對業務也會產生影響。
在業務有突發流量時，計算資源通常會變得緊張甚至出現CPU達到100%的情況。通常情況下，這種情況會通過擴容數據庫規格的方式來解決問題，同時DBA在準備擴容方案時會至少思考如下三個問題：
- 擴容是否能解決資源不足的問題？
- 何時應該進行擴容？
- 如何擴容，規格該如何選擇？
解決這三個問題，DAS同樣面臨如下三個方面挑戰：
2.1. 挑戰一：如何判別擴容是否能夠解決問題？
在數據庫場景下，CPU打滿只是一個計算資源不足的表徵，導致這個現象的根因多樣，解法也同樣各異。例如業務流量激增，當前規格的資源確實不能夠滿足計算需求，在合適的時機點，彈性擴容是一個好的選擇，再如出現了大量的慢SQL，慢SQL堵塞任務隊列，且佔用了大量的計算資源等，此時資深的數據庫管理員首先想到的是緊急SQL限流，而不是擴容。在感知到實例資源不足時，DAS同樣需要從錯綜複雜的問題中抽絲剝繭定位根因，基於根因做出明智的決策，是限流，是擴容，還是其它。
2.2. 挑戰二：如何選擇合適的擴容時機和擴容方式？
對於應急擴容時機，選擇的好壞與緊急情況的判斷準確與否密切相關。“緊急”告警發出過於頻繁，會導致實例頻繁的高規格擴容，產生不必要的費用支出；“緊急”告警發出稍晚，業務受到突發情況影響的時間就會相對較長，對業務會產生影響，甚至引發業務故障。在實時監控的場景下，當我們面臨一個突發的異常點時，很難預判下一時刻是否還會異常。因此，是否需要應急告警變得比較難以決斷。
對於擴容方式，通常有兩種方式，分別是通過增加只讀節點的水平擴容，以及通過改變實例自身規格的垂直擴容。
其中，水平擴容適用於讀流量較多，而寫流量較少的場景，但傳統數據庫需要搬遷數據來搭建只讀節點，而搬遷過程中主節點新產生的數據還存在增量同步更新的問題，會導致創建新節點比較慢。
垂直擴容則是在現有規格基礎上進行升級，其一般流程為先對備庫做升級，然後主備切換，再對新備庫做規格升級，通過這樣的流程來降低對業務的影響，但是備庫升級後切換主庫時依然存在數據同步和數據延遲的問題。因此，在什麼條件下選擇哪種擴容方式也需要依據當前實例的具體流量來進行確定。
2.3. 挑戰三：如何選擇合適的計算規格？
在數據庫場景下，實例變更一次規格涉及多項管控運維操作。以物理機部署的數據庫變更規格為例，一次規格變更操作通常會涉及數據文件搬遷、cgroup隔離重新分配、流量代理節點切換、主備節點切換等操作步驟；而基於Docker部署的數據庫規格變更則更為複雜，會額外增加Docker鏡像生成、Ecs機器選擇、規格庫存等微服務相關的流程。因此，選擇合適的規格可有效地避免規格變更的次數，為業務節省寶貴的時間。
當CPU已經是100%的時候，升配一個規格將會面臨兩種情況：第一種是升配之後，計算資源負載下降並且業務流量平穩；第二種是升配之後，CPU依然是100%，並且流量因為規格提升後計算能力增強而提升。
第一種情況，是比較理想的情況，也是預期擴容後應該出現的效果，但是第二種情況也是非常常見的情形，由於升配之後的規格依然不能承載當前的業務流量容量，而導致資源依然不足，並且仍在影響業務。如何利用數據庫運行時的信息選擇一個合適的高配規格是將直接影響升配的有效性。
03、解決方案
針對上述提到的三項技術挑戰，下面從DAS AutoScale服務的產品能力、解決方案、核心技術這三個方面進行解讀，其中涉及RDS和PolarDB兩種數據庫服務，以及存儲自動擴容和規格自動變更兩個功能，最後以一個案例進一步具體說明。
3.1. 能力介紹
在產品能力上，目前DAS AutoScale服務針對阿里雲RDS數據庫和PolarDB數據提供存儲自動擴容服務和規格自動變配服務。
其中，針對即將達到用戶已購買規格上限的實例，DAS存儲自動擴容服務可以進行磁盤空間預擴容，避免出現因數據庫磁盤滿而影響用戶業務的發生。在該服務中，用戶可自主配置擴容的閾值比例，也可以採用DAS服務預先提供的90%規格上界的閾值配置，當觸發磁盤空間自動擴容事件後，DAS會對該實例的磁盤進行擴容；
針對需要變更實例規格的數據庫實例，DAS規格自動變配服務可進行計算資源的調整，用更符合用戶業務負載的計算資源來處理應用請求，在該服務中，用戶可自主配置業務負載流量的突發程度和持續時間，並可以指定規格變配的最大配置以及變配之後是否回縮到原始規格。
在用戶交互層面，DAS AutoScale主要採用消息通知的方式展示具體的進度以及任務狀態，其中主要包括異常觸發事件、規格建議和管控任務狀態三部分。異常觸發事件用於通知用戶觸發變配任務，規格建議將針對存儲擴容和規格變配的原始規格和目標值進行說明，而管控任務狀態則將反饋AutoScale任務的具體進展和執行狀態。
3.2. 方案介紹
為了實現上面介紹的具體能力，DAS AutoScale實現了一套完整的數據閉環，如圖1：
圖1 DAS AutoScale數據閉環
在該閉環中，包含性能採集模塊、決策中心、算法模型、規格建議模塊、管控執行模塊和任務跟蹤模塊，各模塊的具體功能如下：
- 性能採集模塊負責對實例進行實時性能數據採集，涉及數據庫的多項性能指標信息、規格配置信息、實例運行會話信息等；
- 決策中心模塊則會根據當前性能數據、實例會話列表數據等信息進行全局判斷，以解決挑戰一的問題。例如可通過SQL限流來解決當前計算資源不足的問題則會採取限流處理；若確實為突增的業務流量，則會繼續進行AutoScale服務流程；
- 算法模型是整個DAS AutoScale服務的核心模塊，負責對數據庫實例的業務負載異常檢測和容量規格模型推薦進行計算，進而解決挑戰二和挑戰三的具體問題；
- 規格建議校驗模塊將產出具體建議，並針對數據庫實例的部署類型和實際運行環境進行適配，並與當前區域的可售賣規格進行二次校驗，確保的建議能夠順利在管控側進行執行；
- 管控模塊負責按照產出的規格建議進行分發執行；
- 狀態跟蹤模塊則用於衡量和跟蹤規格變更前後數據庫實例上的性能變化情況；
接下來，將分別針對DAS AutoScale支持的存儲擴容和規格變配兩個業務場景進行展開介紹。
圖2 存儲擴容方案
存儲擴容的方案見圖2，主要有兩類觸發方式，分別是用戶自定義觸發和算法預測觸發。其中，算法將根據數據庫實例過去一段時間內的磁盤使用值結合時序序列預測算法，預測出未來一段時間內的磁盤使用量，若短時間內磁盤使用量將超過用戶實例的磁盤規格，則進行自動擴容。每次磁盤擴容將最少擴大5G，最多擴大原實例規格的15%，以確保數據庫實例的磁盤空間充足。
目前在磁盤AutoScale的時機方面，主要採用的是閾值和預測相結合的方式。當用戶的磁盤數據緩慢增長達到既定閾值（90%）時，將觸發擴容操作；如果用戶的磁盤數據快速增長，算法預測到其短時間內將會可用空間不足時，也會給出磁盤擴容建議及相應的擴容原因說明。
圖3 規格變配方案
規格變配的方案見圖3，其具體流程為：首先，異常檢測模塊將針對業務突發流量從多個維度（qps、tps、active session、iops等指標）進行突發異常識別，經決策中心判別是否需要AutoScale變配規格，然後由規格建議模塊產生高規格建議，再由管控組件進行規格變配執行。
待應用的異常流量結束之後，異常檢測模塊將識別出流量已迴歸正常，然後再由管控組件根據元數據中存儲的原規格信息進行規格回縮。在整個變配流程結束之後，將有效果跟蹤模塊產出變配期間的性能變化趨勢和效果評估。
目前規格的AutoScale觸發時機方面，主要是採取對實例的多種性能指標（包括cpu利用率、磁盤iops、實例Logic read等）進行異常檢測之後，結合用戶設定的觀測窗口期長度來實現有效的規格AutoScale觸發。
觸發AutoScale之後，規格推薦算法模塊將基於訓練好的模型並結合當前性能數據、規格、歷史性能數據進行計算，產出更適合當前流量的實例規格。此外，回縮原始規格的觸發時機也是需要結合用戶的靜默期配置窗口長度和實例的性能數據進行判斷，當符合回縮原始規格條件後，將進行原始規格的回縮。
3.3. 核心技術支撐
DAS AutoScale服務依賴的是阿里雲數據庫數據鏈路團隊、管控團隊和內核團隊技術的綜合實力，其中主要依賴瞭如下幾項關鍵技術：
- 全網數據庫實例的秒級數據監控技術，目前監控採集鏈路實現了全網所有數據庫實例的秒級採集、監控、展現、診斷，可每秒實時處理超過1000萬項監控指標，為數據庫服務智能化打下了堅實的數據基礎；
- 全網統一的RDS管控任務流技術，目前該管控任務流承擔了阿里雲全網實例的運維操作執行，為AutoScale技術的具體執行落地提供了可靠的保障；
- 基於預測和機器學習的時序異常檢測算法，目前的時序異常檢測算法可提供週期性檢測、轉折點判定和連續異常區間識別等功能，目前對線上10w+的數據庫實例進行1天后數據預測，誤差小於5%的實例佔比穩定在99%以上， 並且預測14天之後的誤差小於5%的實例佔比在94%以上；
- 基於DeepLearning的數據庫RT預測模型，該算法可基於數據庫實例的CPU使用情況、邏輯讀、物理讀和iops等多項數據指標預測出實例運行時的rt值，用於指導數據庫對BufferPool內存的縮減，為阿里巴巴數據庫節省超27T內存，佔比總內存約17%；
- 基於雲計算架構的下一代關係型數據庫PolarDB，PolarDB是阿里雲數據庫團隊為雲計算時代定製的數據庫，其中它的具備計算節點與存儲節點分離特性對AutoScale提供了強有力的技術保障，能夠避免拷貝數據存儲帶來的額外開銷，大幅提升AutoScale的體驗。
在上述多項技術的加持下，DAS AutoScale目前提供對RDS規格推薦建議、RDS存儲AutoScale以及PolarDB的規格和存儲AutoScale能力，並能夠保證AutoScale期間的數據一致性和完整性，能夠在不影響業務穩定性的情況下實現AutoScale，為業務保駕護航！
3.4. 具體案例
圖4 變配任務示例
接下來，以某實例上的AutoScale過程進行說明，如圖4。
該業務在19:43分突然出現異常流量，導致CPU和活躍會話飆升，CPU資源從原10%左右升至70%以上，資源相對緊張。
在該實例上，用戶配置了15分鐘的觀測窗口以及CPU超過70%的觸發條件，用於避免過於頻繁的AutoScale觸發。異常流量持續到19:58時，已經具備了觸發AutoScale的條件。經過7分鐘的管控任務，在20:05完成主節點的規格變配。對比升配前後的資源使用情況，可看出，初始階段該實例的CPU、IOPS相對較高，再升到高配規格之後，CPU、IOPS的使用量均有明顯下降。
04、如何使用
您可以在阿里雲數據庫自治服務 DAS 上免費使用該功能，立即申請體驗。
05、相關閱讀
業務異常只能瞅著數據庫崩潰？看看應急處理利器——自動SQL限流
