資料庫自治服務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所示，其具體流程為：首先，異常檢測模組針對執行個體出/入口流量使用率進行突增流量異常識別，經決策中心判別是否需要進行頻寬自動擴容，然後由頻寬規格建議模組產生高規格建議，再由管控組件執行頻寬規格升配。
待異常流量結束後，異常檢測模組將識別出流量已迴歸正常，頻寬規格建議模組產生頻寬回縮建議，然後再由管控組件執行頻寬規格回縮。在整個變更配置流程結束之後，將有變更配置效果跟蹤模組產出變更配置期間的效能變化趨勢和效果評估。
目前頻寬自動Auto Scaling在觸發時機方面，主要是採取對執行個體的出/入口流量使用率進行異常檢測之後，結合使用者設定的觀測視窗期長度來實現頻寬Auto Scaling的觸發。觸發頻寬Auto Scaling後，頻寬規格推薦演算法模組將基於訓練好的模型結合當前執行個體的效能資料、頻寬規格以及歷史效能資料進行計算，產出更適合當前流量的執行個體頻寬規格。頻寬規格回縮的觸發時機也是結合了執行個體的效能資料進行判斷，當符合頻寬規格回縮條件後，將基於頻寬規格建議模組產生的頻寬回縮建議進行頻寬規格的回縮。
核心技術
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緊張問題，有效保障資料庫執行個體的業務穩定運行。