如何用好數(shù)據(jù)庫，調(diào)校數(shù)據(jù)庫使其發(fā)揮最優(yōu)的性能？
如何快速診斷和應(yīng)對各種原因?qū)е碌耐话l(fā)數(shù)據(jù)庫性能問題？
如何以最低資源成本滿足業(yè)務(wù)需求？

......

這些復(fù)雜的運維難題最優(yōu)解到底是什么？

今天（4月22日）15:00
數(shù)據(jù)庫自治服務(wù)DAS重磅發(fā)布會
現(xiàn)場為你揭曉答案！
數(shù)據(jù)庫自動駕駛時代一觸即發(fā)
點擊這里
即可預(yù)約直播

今天提前為大家揭秘數(shù)據(jù)庫自治服務(wù)DAS的一個創(chuàng)新功能 —— AutoScale，基于數(shù)據(jù)庫實例的實時性能數(shù)據(jù)作為輸入，由DAS完成流量異常發(fā)現(xiàn)、合理數(shù)據(jù)庫規(guī)格建議和合理磁盤容量建議，使數(shù)據(jù)庫服務(wù)具備自動擴展存儲和計算資源的能力。

01背 景

為業(yè)務(wù)應(yīng)用選擇一個合適的數(shù)據(jù)庫規(guī)格，是每個數(shù)據(jù)庫運維同學(xué)都會經(jīng)常面臨的一個問題。若規(guī)格選的過大，會產(chǎn)生資源浪費；若規(guī)格選的過小，計算性能不足會影響業(yè)務(wù)。

通常情況下，運維同學(xué)會采用業(yè)務(wù)平穩(wěn)運行狀態(tài)下，CPU可處于合理水位（例如50%以下）的一個規(guī)格（如4核CPU配8G內(nèi)存）并配一個相對富余的磁盤規(guī)格（如200G）。

然而在數(shù)據(jù)庫應(yīng)用運維同學(xué)的日常生活里，線上應(yīng)用流量突增導(dǎo)致數(shù)據(jù)庫資源打滿的情況時有發(fā)生，而引發(fā)這類問題的場景可能多種多樣：

• 1、新業(yè)務(wù)上線，對業(yè)務(wù)流量預(yù)估不足，導(dǎo)致資源打滿，如新上線的應(yīng)用接入了大量的引流，或基礎(chǔ)流量比較大的平臺上線了一個新特性功能。
• 2、不可預(yù)知的流量，如突發(fā)的輿論熱點帶來的臨時流量，或某個網(wǎng)紅引發(fā)的限時搶購、即興話題等。
• 3、一些平時運行頻次不高，但又偶發(fā)集中式訪問，如每日一次的上班打卡場景，或每周執(zhí)行幾次的財務(wù)核算業(yè)務(wù)。這類業(yè)務(wù)場景平時業(yè)務(wù)壓力不高，雖已知會存在訪問高峰，但為節(jié)省資源而通常不會分配較高的規(guī)格。

當(dāng)上述業(yè)務(wù)場景突發(fā)計算資源不足狀況時，通常會讓運維同學(xué)措手不及，嚴(yán)重影響業(yè)務(wù)，如何應(yīng)對“數(shù)據(jù)庫資源打滿”是運維同學(xué)常常被挑戰(zhàn)的問題之一。

在數(shù)據(jù)庫場景下，資源打滿可分為計算資源和存儲資源兩大類，其主要表現(xiàn)：

• 1、計算資源打滿，主要表現(xiàn)為CPU資源利用率達(dá)到100%，當(dāng)前規(guī)格下的計算能力不足以應(yīng)對；
• 2、存儲資源打滿，主要表現(xiàn)為磁盤空間使用率達(dá)到100%，數(shù)據(jù)庫寫入的數(shù)據(jù)量達(dá)到當(dāng)前規(guī)格下的磁盤空間限制，導(dǎo)致業(yè)務(wù)無法寫入新數(shù)據(jù)；

針對上述兩類問題，數(shù)據(jù)庫自治服務(wù) DAS 進行了服務(wù)創(chuàng)新，使數(shù)據(jù)庫服務(wù)具備自動擴展存儲和計算資源的技術(shù)能力，應(yīng)對上述的問題。

DAS AutoScale基于數(shù)據(jù)庫實例的實時性能數(shù)據(jù)作為輸入，由DAS完成流量異常發(fā)現(xiàn)、合理數(shù)據(jù)庫規(guī)格建議和合理磁盤容量建議，使數(shù)據(jù)庫服務(wù)具備自動擴展存儲和計算資源的能力。

接下來，本文將對DAS AutoScale服務(wù)的架構(gòu)進行詳細(xì)的介紹，包括技術(shù)挑戰(zhàn)、解決方案和關(guān)鍵技術(shù)。

02技術(shù)挑戰(zhàn)

計算節(jié)點規(guī)格調(diào)整是數(shù)據(jù)庫優(yōu)化的一種常用手段，盡管計算資源規(guī)格只涉及到CPU和內(nèi)存，但在生產(chǎn)環(huán)境進行規(guī)格變配的影響還是不容忽視，將涉及數(shù)據(jù)遷移、HA切換、Proxy切換等操作，對業(yè)務(wù)也會產(chǎn)生影響。

業(yè)務(wù)有突發(fā)流量時，計算資源通常會變得緊張甚至出現(xiàn)CPU達(dá)到100%的情況。通常情況下，這種情況會通過擴容數(shù)據(jù)庫規(guī)格的方式來解決問題，同時DBA在準(zhǔn)備擴容方案時會至少思考如下三個問題：

• 1.擴容是否能解決資源不足的問題？
• 2.何時應(yīng)該進行擴容？
• 3.如何擴容，規(guī)格該如何選擇？

解決這三個問題，DAS同樣面臨如下三個方面挑戰(zhàn)：

2.1. 挑戰(zhàn)一：如何判別擴容是否能夠解決問題？

在數(shù)據(jù)庫場景下，CPU打滿只是一個計算資源不足的表征，導(dǎo)致這個現(xiàn)象的根因多樣，解法也同樣各異。例如業(yè)務(wù)流量激增，當(dāng)前規(guī)格的資源確實不能夠滿足計算需求，在合適的時機點，彈性擴容是一個好的選擇，再如出現(xiàn)了大量的慢SQL，慢SQL堵塞任務(wù)隊列，且占用了大量的計算資源等，此時資深的數(shù)據(jù)庫管理員首先想到的是緊急SQL限流，而不是擴容。在感知到實例資源不足時，DAS同樣需要從錯綜復(fù)雜的問題中抽絲剝繭定位根因，基于根因做出明智的決策，是限流，是擴容，還是其它。

2.2. 挑戰(zhàn)二：如何選擇合適的擴容時機和擴容方式？

對于應(yīng)急擴容時機，選擇的好壞與緊急情況的判斷準(zhǔn)確與否密切相關(guān)。“緊急”告警發(fā)出過于頻繁，會導(dǎo)致實例頻繁的高規(guī)格擴容，產(chǎn)生不必要的費用支出；“緊急”告警發(fā)出稍晚，業(yè)務(wù)受到突發(fā)情況影響的時間就會相對較長，對業(yè)務(wù)會產(chǎn)生影響，甚至引發(fā)業(yè)務(wù)故障。在實時監(jiān)控的場景下，當(dāng)我們面臨一個突發(fā)的異常點時，很難預(yù)判下一時刻是否還會異常。因此，是否需要應(yīng)急告警變得比較難以決斷。

對于擴容方式，通常有兩種方式，分別是通過增加只讀節(jié)點的水平擴容，以及通過改變實例自身規(guī)格的垂直擴容。

其中，水平擴容適用于讀流量較多，而寫流量較少的場景，但傳統(tǒng)數(shù)據(jù)庫需要搬遷數(shù)據(jù)來搭建只讀節(jié)點，而搬遷過程中主節(jié)點新產(chǎn)生的數(shù)據(jù)還存在增量同步更新的問題，會導(dǎo)致創(chuàng)建新節(jié)點比較慢。

垂直擴容則是在現(xiàn)有規(guī)格基礎(chǔ)上進行升級，其一般流程為先對備庫做升級，然后主備切換，再對新備庫做規(guī)格升級，通過這樣的流程來降低對業(yè)務(wù)的影響，但是備庫升級后切換主庫時依然存在數(shù)據(jù)同步和數(shù)據(jù)延遲的問題。因此，在什么條件下選擇哪種擴容方式也需要依據(jù)當(dāng)前實例的具體流量來進行確定。

2.3. 挑戰(zhàn)三：如何選擇合適的計算規(guī)格？

在數(shù)據(jù)庫場景下，實例變更一次規(guī)格涉及多項管控運維操作。以物理機部署的數(shù)據(jù)庫變更規(guī)格為例，一次規(guī)格變更操作通常會涉及數(shù)據(jù)文件搬遷、cgroup隔離重新分配、流量代理節(jié)點切換、主備節(jié)點切換等操作步驟；而基于Docker部署的數(shù)據(jù)庫規(guī)格變更則更為復(fù)雜，會額外增加Docker鏡像生成、Ecs機器選擇、規(guī)格庫存等微服務(wù)相關(guān)的流程。因此，選擇合適的規(guī)格可有效地避免規(guī)格變更的次數(shù)，為業(yè)務(wù)節(jié)省寶貴的時間。

當(dāng)CPU已經(jīng)是100%的時候，升配一個規(guī)格將會面臨兩種情況：第一種是升配之后，計算資源負(fù)載下降并且業(yè)務(wù)流量平穩(wěn)；第二種是升配之后，CPU依然是100%，并且流量因為規(guī)格提升后計算能力增強而提升。

第一種情況，是比較理想的情況，也是預(yù)期擴容后應(yīng)該出現(xiàn)的效果，但是第二種情況也是非常常見的情形，由于升配之后的規(guī)格依然不能承載當(dāng)前的業(yè)務(wù)流量容量，而導(dǎo)致資源依然不足，并且仍在影響業(yè)務(wù)。如何利用數(shù)據(jù)庫運行時的信息選擇一個合適的高配規(guī)格是將直接影響升配的有效性。

03解決方案

針對上述提到的三項技術(shù)挑戰(zhàn)，下面從DAS AutoScale服務(wù)的產(chǎn)品能力、解決方案、核心技術(shù)這三個方面進行解讀，其中涉及RDS和PolarDB兩種數(shù)據(jù)庫服務(wù)，以及存儲自動擴容和規(guī)格自動變更兩個功能，最后以一個案例進一步具體說明。

3.1. 能力介紹

在產(chǎn)品能力上，目前DAS AutoScale服務(wù)針對阿里云RDS數(shù)據(jù)庫和PolarDB數(shù)據(jù)提供存儲自動擴容服務(wù)和規(guī)格自動變配服務(wù)。

其中，針對即將達(dá)到用戶已購買規(guī)格上限的實例，DAS存儲自動擴容服務(wù)可以進行磁盤空間預(yù)擴容，避免出現(xiàn)因數(shù)據(jù)庫磁盤滿而影響用戶業(yè)務(wù)的發(fā)生。在該服務(wù)中，用戶可自主配置擴容的閾值比例，也可以采用DAS服務(wù)預(yù)先提供的90%規(guī)格上界的閾值配置，當(dāng)觸發(fā)磁盤空間自動擴容事件后，DAS會對該實例的磁盤進行擴容；

針對需要變更實例規(guī)格的數(shù)據(jù)庫實例，DAS規(guī)格自動變配服務(wù)可進行計算資源的調(diào)整，用更符合用戶業(yè)務(wù)負(fù)載的計算資源來處理應(yīng)用請求，在該服務(wù)中，用戶可自主配置業(yè)務(wù)負(fù)載流量的突發(fā)程度和持續(xù)時間，并可以指定規(guī)格變配的最大配置以及變配之后是否回縮到原始規(guī)格。

在用戶交互層面，DAS AutoScale主要采用消息通知的方式展示具體的進度以及任務(wù)狀態(tài)，其中主要包括異常觸發(fā)事件、規(guī)格建議和管控任務(wù)狀態(tài)三部分。異常觸發(fā)事件用于通知用戶觸發(fā)變配任務(wù)，規(guī)格建議將針對存儲擴容和規(guī)格變配的原始規(guī)格和目標(biāo)值進行說明，而管控任務(wù)狀態(tài)則將反饋AutoScale任務(wù)的具體進展和執(zhí)行狀態(tài)。

3.2. 方案介紹

為了實現(xiàn)上面介紹的具體能力，DAS AutoScale實現(xiàn)了一套完整的數(shù)據(jù)閉環(huán)，如圖1：

圖1 DAS AutoScale數(shù)據(jù)閉環(huán)

在該閉環(huán)中，包含性能采集模塊、決策中心、算法模型、規(guī)格建議模塊、管控執(zhí)行模塊和任務(wù)跟蹤模塊，各模塊的具體功能如下：

• 性能采集模塊負(fù)責(zé)對實例進行實時性能數(shù)據(jù)采集，涉及數(shù)據(jù)庫的多項性能指標(biāo)信息、規(guī)格配置信息、實例運行會話信息等；
• 決策中心模塊則會根據(jù)當(dāng)前性能數(shù)據(jù)、實例會話列表數(shù)據(jù)等信息進行全局判斷，以解決挑戰(zhàn)一的問題。例如可通過SQL限流來解決當(dāng)前計算資源不足的問題則會采取限流處理；若確實為突增的業(yè)務(wù)流量，則會繼續(xù)進行AutoScale服務(wù)流程；
• 算法模型是整個DAS AutoScale服務(wù)的核心模塊，負(fù)責(zé)對數(shù)據(jù)庫實例的業(yè)務(wù)負(fù)載異常檢測和容量規(guī)格模型推薦進行計算，進而解決挑戰(zhàn)二和挑戰(zhàn)三的具體問題；
• 規(guī)格建議校驗?zāi)K將產(chǎn)出具體建議，并針對數(shù)據(jù)庫實例的部署類型和實際運行環(huán)境進行適配，并與當(dāng)前區(qū)域的可售賣規(guī)格進行二次校驗，確保的建議能夠順利在管控側(cè)進行執(zhí)行；
• 管控模塊負(fù)責(zé)按照產(chǎn)出的規(guī)格建議進行分發(fā)執(zhí)行；
• 狀態(tài)跟蹤模塊則用于衡量和跟蹤規(guī)格變更前后數(shù)據(jù)庫實例上的性能變化情況；

接下來，將分別針對DAS AutoScale支持的存儲擴容和規(guī)格變配兩個業(yè)務(wù)場景進行展開介紹。

圖2 存儲擴容方案

存儲擴容的方案見圖2，主要有兩類觸發(fā)方式，分別是用戶自定義觸發(fā)和算法預(yù)測觸發(fā)。其中，算法將根據(jù)數(shù)據(jù)庫實例過去一段時間內(nèi)的磁盤使用值結(jié)合時序序列預(yù)測算法，預(yù)測出未來一段時間內(nèi)的磁盤使用量，若短時間內(nèi)磁盤使用量將超過用戶實例的磁盤規(guī)格，則進行自動擴容。每次磁盤擴容將最少擴大5G，最多擴大原實例規(guī)格的15%，以確保數(shù)據(jù)庫實例的磁盤空間充足。

目前在磁盤AutoScale的時機方面，主要采用的是閾值和預(yù)測相結(jié)合的方式。當(dāng)用戶的磁盤數(shù)據(jù)緩慢增長達(dá)到既定閾值（90%）時，將觸發(fā)擴容操作；如果用戶的磁盤數(shù)據(jù)快速增長，算法預(yù)測到其短時間內(nèi)將會可用空間不足時，也會給出磁盤擴容建議及相應(yīng)的擴容原因說明。

圖3 規(guī)格變配方案

規(guī)格變配的方案見圖3，其具體流程為：首先，異常檢測模塊將針對業(yè)務(wù)突發(fā)流量從多個維度（qps、tps、active session、iops等指標(biāo)）進行突發(fā)異常識別，經(jīng)決策中心判別是否需要AutoScale變配規(guī)格，然后由規(guī)格建議模塊產(chǎn)生高規(guī)格建議，再由管控組件進行規(guī)格變配執(zhí)行。

待應(yīng)用的異常流量結(jié)束之后，異常檢測模塊將識別出流量已回歸正常，然后再由管控組件根據(jù)元數(shù)據(jù)中存儲的原規(guī)格信息進行規(guī)格回縮。在整個變配流程結(jié)束之后，將有效果跟蹤模塊產(chǎn)出變配期間的性能變化趨勢和效果評估。

目前規(guī)格的AutoScale觸發(fā)時機方面，主要是采取對實例的多種性能指標(biāo)（包括cpu利用率、磁盤iops、實例Logic read等）進行異常檢測之后，結(jié)合用戶設(shè)定的觀測窗口期長度來實現(xiàn)有效的規(guī)格AutoScale觸發(fā)。

觸發(fā)AutoScale之后，規(guī)格推薦算法模塊將基于訓(xùn)練好的模型并結(jié)合當(dāng)前性能數(shù)據(jù)、規(guī)格、歷史性能數(shù)據(jù)進行計算，產(chǎn)出更適合當(dāng)前流量的實例規(guī)格。此外，回縮原始規(guī)格的觸發(fā)時機也是需要結(jié)合用戶的靜默期配置窗口長度和實例的性能數(shù)據(jù)進行判斷，當(dāng)符合回縮原始規(guī)格條件后，將進行原始規(guī)格的回縮。

3.3. 核心技術(shù)支撐

DAS AutoScale服務(wù)依賴的是阿里云數(shù)據(jù)庫數(shù)據(jù)鏈路團隊、管控團隊和內(nèi)核團隊技術(shù)的綜合實力，其中主要依賴了如下幾項關(guān)鍵技術(shù)：

• 1.全網(wǎng)數(shù)據(jù)庫實例的秒級數(shù)據(jù)監(jiān)控技術(shù)，目前監(jiān)控采集鏈路實現(xiàn)了全網(wǎng)所有數(shù)據(jù)庫實例的秒級采集、監(jiān)控、展現(xiàn)、診斷，可每秒實時處理超過1000萬項監(jiān)控指標(biāo)，為數(shù)據(jù)庫服務(wù)智能化打下了堅實的數(shù)據(jù)基礎(chǔ)；
• 2.全網(wǎng)統(tǒng)一的RDS管控任務(wù)流技術(shù)，目前該管控任務(wù)流承擔(dān)了阿里云全網(wǎng)實例的運維操作執(zhí)行，為AutoScale技術(shù)的具體執(zhí)行落地提供了可靠的保障；
• 3.基于預(yù)測和機器學(xué)習(xí)的時序異常檢測算法，目前的時序異常檢測算法可提供周期性檢測、轉(zhuǎn)折點判定和連續(xù)異常區(qū)間識別等功能，目前對線上10w+的數(shù)據(jù)庫實例進行1天后數(shù)據(jù)預(yù)測，誤差小于5%的實例占比穩(wěn)定在99%以上， 并且預(yù)測14天之后的誤差小于5%的實例占比在94%以上；
• 4.基于DeepLearning的數(shù)據(jù)庫RT預(yù)測模型，該算法可基于數(shù)據(jù)庫實例的CPU使用情況、邏輯讀、物理讀和iops等多項數(shù)據(jù)指標(biāo)預(yù)測出實例運行時的rt值，用于指導(dǎo)數(shù)據(jù)庫對BufferPool內(nèi)存的縮減，為阿里巴巴數(shù)據(jù)庫節(jié)省超27T內(nèi)存，占比總內(nèi)存約17%；
• 5.基于云計算架構(gòu)的下一代關(guān)系型數(shù)據(jù)庫PolarDB，PolarDB是阿里云數(shù)據(jù)庫團隊為云計算時代定制的數(shù)據(jù)庫，其中它的具備計算節(jié)點與存儲節(jié)點分離特性對AutoScale提供了強有力的技術(shù)保障，能夠避免拷貝數(shù)據(jù)存儲帶來的額外開銷，大幅提升AutoScale的體驗
  。

在上述多項技術(shù)的加持下，DAS AutoScale目前提供對RDS規(guī)格推薦建議、RDS存儲AutoScale以及PolarDB的規(guī)格和存儲AutoScale能力，并能夠保證AutoScale期間的數(shù)據(jù)一致性和完整性，能夠在不影響業(yè)務(wù)穩(wěn)定性的情況下實現(xiàn)AutoScale，為業(yè)務(wù)保駕護航！

3.4. 具體案例

圖4 變配任務(wù)示例

接下來，以某實例上的AutoScale過程進行說明，如圖4。

該業(yè)務(wù)在19:43分突然出現(xiàn)異常流量，導(dǎo)致CPU和活躍會話飆升，CPU資源從原10%左右升至70%以上，資源相對緊張。

在該實例上，用戶配置了15分鐘的觀測窗口以及CPU超過70%的觸發(fā)條件，用于避免過于頻繁的AutoScale觸發(fā)。異常流量持續(xù)到19:58時，已經(jīng)具備了觸發(fā)AutoScale的條件。經(jīng)過7分鐘的管控任務(wù)，在20:05完成主節(jié)點的規(guī)格變配。對比升配前后的資源使用情況，可看出，初始階段該實例的CPU、IOPS相對較高，再升到高配規(guī)格之后，CPU、IOPS的使用量均有明顯下降。

04如何使用

您可以在阿里云數(shù)據(jù)庫自治服務(wù) DAS 上免費使用該功能，掃描下方二維碼，即可立即申請體驗。

05相關(guān)閱讀

業(yè)務(wù)異常只能看著數(shù)據(jù)庫崩潰？看看應(yīng)急處理利器——自動SQL限流
耗時又繁重的SQL優(yōu)化，以后就都交給TA吧！
陷入人肉SQL優(yōu)化的惡性循環(huán)怎么辦？是時候跟它們說再見了
因“智”而治，數(shù)據(jù)庫即將邁入自動駕駛時代
直播預(yù)告

因“智”而治，數(shù)據(jù)庫即將邁入自動駕駛時代
4月22日 15:00 — 16:30
期待與你一同見證精彩蛻變
點擊這里
立即預(yù)約觀看DAS發(fā)布會直播

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的如何应对数据库CPU打满？最优解在这里...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。