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