前言

在全球經(jīng)濟增長放緩的大背景之下，企業(yè)在加強數(shù)字化建設的過程中，實現(xiàn)效益最大化成為一個繞不開的話題。阿里云瑤池旗下的云原生數(shù)倉AnalyticDB?MySQL湖倉版（以下簡稱AnalyticDB?MySQL）在發(fā)布之初提供了定時彈性功能，幫助業(yè)務有規(guī)律的客戶定時升降配計算資源以節(jié)省成本。時隔一年，AnalyticDB MySQL針對用戶痛點，再推出Multi-Cluster彈性資源模式，它具備貼合用戶負載、自動配置、性能線性提升等優(yōu)點，進一步幫用戶節(jié)省成本，提高計算效率。

彈性模型介紹

彈性模型分為兩種，分別是Min-Max彈性模型和Multi-Cluster彈性模型。

???Min-Max彈性模型：

單個SQL可使用的資源量在Min和Max資源量之間進行擴縮，該模型適用于ETL場景，用于提升單個SQL的性能。例如，Min=16 cores，Max=32cores，單個SQL可使用的資源量在區(qū)間[16cores, 32cores]中。

???Multi-Cluster彈性模型：

以Cluster粒度進行資源擴縮，單個SQL可使用的資源量為單個Cluster，Cluster之間資源隔離，該模型適用于在線分析和交互式分析場景，用于提升SQL的并發(fā)度。

例如，單個Cluster大小=16cores，最小Cluster和最大Cluster個數(shù)分別為1和2，那么，每個SQL可使用的資源量為16cores（單個Cluster），隨著SQL并發(fā)度的提高或降低，Cluster個數(shù)可以在1和2之間自動進行調(diào)整，Cluster1中運行的SQL不會影響Cluster2中的SQL。

Multi-Cluster彈性模式優(yōu)勢

AnalyticDB MySQL在沒有Multi-Cluster彈性模型之前，采用的是Min-Max彈性模型，通過定時彈性實現(xiàn)資源的彈起和釋放，存在不少限制，具體表現(xiàn)在以下方面：

• 易用性：用戶只能根據(jù)業(yè)務規(guī)律，在固定時間段將資源彈升，彈性計劃生效間隔長（最短間隔10分鐘）；
• 性能：小查詢的性能容易受到大查詢的干擾，?查詢并發(fā)數(shù)不隨資源組大小變化，查詢可能排隊；
• 成本：用戶需要指定固定時間段的彈升規(guī)格，難以貼合實時的業(yè)務負載，短時間段的業(yè)務波谷無法縮容。

為了解決上述問題，應對查詢的高并發(fā)實時分析場景，AnalyticDB MySQL引入了Multi-Cluster彈性模型。Multi-Cluster彈性模型作用在AnalyticDB MySQL在線資源組內(nèi)部，一個在線資源組由一個或者多個Cluster組成，相比Min-Max彈性模型，在易用性、性能和成本上均有了較大提升。

易用性

自動根據(jù)當前實例的負載進行Cluster個數(shù)的擴縮，無需手動設置資源擴縮時間，更靈活地應對不同的業(yè)務流量。用戶只需設置好Cluster個數(shù)的上限、下限及每個Cluster大小即可。

性能

Cluster之間資源隔離，單個SQL只會影響其所在的Cluster，不影響其余Cluster中SQL的運行，避免了單個大SQL對其它小SQL的干擾，進而影響資源組內(nèi)查詢的整體性能。根據(jù)實驗結(jié)果，隨著Cluster個數(shù)的增多，查詢并發(fā)數(shù)呈線性增長趨勢。與Min-Max彈性模型相比，Multi-Cluster彈性模型下在同等計算資源下，查詢并發(fā)度可提升高達28%。

成本

貼合用戶負載，動態(tài)選擇最優(yōu)Cluster個數(shù)，應對業(yè)務的波峰波谷。為了更直觀地展示Multi-Cluster彈性模型和Min-Max彈性模型在成本上的收益，我們這里舉個實際應用的案例：

• 0-7點：某客戶在晚上0-7點的時候，處于業(yè)務低峰期，用戶采用定時彈性，將計算資源縮小至48ACU；
• 7-24點：客戶業(yè)務處于間歇性高峰期，用戶采用定時彈性將計算資源保持在192ACU，以應對隨時可能到來的波峰；
• 全天使用的總資源量為3600ACU。

注：ACU（AnalyticDB Compute Unit）是AnalyticDB MySQL湖倉版資源分配的最小單位。一個ACU約等于1核4GB。

應用Multi-Cluster彈性模型之后：

• 0-7點：用戶將Cluster大小縮小為48ACU，保持和定時彈性的資源使用量一直；
• 7-24點：用戶將Cluster大小變?yōu)?6ACU，并設置最小Cluster個數(shù)為1，最大Cluster為2；
• 全天使用的總資源量為2208ACU，相比定時彈性節(jié)省資源約38.7%。

可以看到相對定時彈性，Multi-Cluster彈性模型可以在業(yè)務兩個高峰之間的波谷，為用戶減少Cluster個數(shù)，節(jié)省成本，當用戶的業(yè)務波峰到來后，Cluster個數(shù)隨之彈升，滿足業(yè)務負載。

總的來說，相比Min-Max彈性模型，Multi-Cluster彈性模型更適合高并發(fā)實時分析場景，體現(xiàn)在易用性、性能和成本等維度。下面我們將深入地了解Multi-Cluster的技術(shù)架構(gòu)，以及如何實現(xiàn)“彈得準、彈得快、彈得好”的目標。

Multi-Cluster技術(shù)架構(gòu)

在設計Multi-Cluster技術(shù)架構(gòu)的時候，我們的核心目標有三個：彈得準、彈得快、彈得好。下圖是AnalyticDB MySQL Multi-Cluster的整體架構(gòu)圖，從上至下可分為三層:

• 接入層：負責將用戶的查詢投遞到特定的資源組，再根據(jù)Cluster的負載情況分配到具體的Cluster上去執(zhí)行；
• 執(zhí)行層：資源組內(nèi)部劃分為相同大小的多個Cluster，每個query只在其中一個Cluster上執(zhí)行；
• 決策層：通過實時讀取AnalyticDB MySQL資源的負載情況，進行Multi-Cluster資源組的擴縮容決策。

彈得快：實時數(shù)據(jù)鏈路

為了保障擴容的時效性，快速應對用戶查詢的到來，AnalyticDB MySQL建立了Region級別的指標采集系統(tǒng)。AnalyticDB MySQL實例也進行了改造，能實時地更新內(nèi)部的業(yè)務指標（如Query排隊數(shù)、CPU使用等），并被指標采集進程采集到中心的存儲端。目前整個數(shù)據(jù)鏈路的延遲在10s左右。

彈得準：穩(wěn)定的擴縮容策略

AnalyticDB MySQL實例是由接入層節(jié)點、計算節(jié)點、存儲節(jié)點共同構(gòu)成的復雜系統(tǒng)，在對計算資源進行擴縮容決策的時候面臨如下挑戰(zhàn)：

• 多組件交互的系統(tǒng)，如何識別外部組件瓶頸；
• 實例指標繁多，基于什么指標來進行擴縮容決策；
• 如何防止指標短時間的抖動，導致擴縮容策略不準；
• 如何判斷擴縮容決策是否合理。

為此，我們將整個Cluster個數(shù)計算分為三個階段：決策、執(zhí)行、反饋。

決策

?? 瓶頸識別

我們在決策系統(tǒng)中，將指標分為兩類：

正向指標：反饋要擴容目標的負載情況，決定擴容目標的擴縮容。

負向指標：反饋除擴容目標外的其余組件的負載情況，用于判斷外部瓶頸。

當負向指標達到設定的閾值時，我們認為計算節(jié)點擴容對于AnalyticDB MySQL實例整體而言已經(jīng)無法起到加速查詢，提升并發(fā)數(shù)的作用。對于這種情況，決策系統(tǒng)將會報警直至瓶頸解除。

???Cluster個數(shù)預估

對AnalyticDB MySQL實例的負載分析后，我們發(fā)現(xiàn)對于擴縮容的決策并不能由單個指標決定，隨著用戶負載類型不同，決定擴縮容的指標也不一樣。主要用到的指標有：用戶CPU使用率，用戶內(nèi)存使用率，用戶查詢排隊數(shù)等。

因此在擴縮容的預估的過程中，我們會先根據(jù)每個指標計算得出一個候選Cluster數(shù)，最后再選擇所有指標中最大的Cluster數(shù)作為最終候選項。

• 對于和Cluster掛鉤的指標（如CPU利用率）我們采用如下計算公式：

• 對于和資源組掛鉤、但不和Cluster掛鉤的指標（如查詢排隊數(shù)和并發(fā)數(shù)）我們采用如下公式計算：

• 最終我們?nèi)∷兴愠鰜淼哪繕薈luster數(shù)的較大值：

???穩(wěn)定窗口

為避免因為實例負載抖動等因素造成的metric抖動，我們采用了穩(wěn)定窗口的算法來避免抖動

在穩(wěn)定窗口期間，每次預估的Cluster個數(shù)都會記錄下來，并使用當前的Cluster個數(shù)和穩(wěn)定窗口中推薦的個數(shù)進行對比。

a)?若窗口Min ≤ 當前Cluster個數(shù) ≤ 窗口Max，則當前Cluster個數(shù)保持不變；

b)?若當前Cluster個數(shù) < 窗口Min，則說明應當將當前Cluster個數(shù)應當擴容至窗口Min；

c)?若當前Cluster個數(shù) > 窗口Max，說明當前Cluster個數(shù)應當縮到穩(wěn)定窗口Max。

執(zhí)行

資源組內(nèi)部的Cluster，在AnalyticDB?MySQL內(nèi)部對應的K8s的自定義資源(Custom?Resource)，由自研的Operator進行管理，這些自定義資源實現(xiàn)了K8s的Scale SubResource。當決策系統(tǒng)作出決策后，會通過K8s的Scale API，將目標Cluster個數(shù)下發(fā)給自定義Operator進行擴縮容。

反饋：有效性評估

在執(zhí)行完擴（縮）容后，決策系統(tǒng)會記錄擴容之前的metric指標的值，并在擴（縮）容完成后持續(xù)觀察用戶負載的指標。

• 擴容評估:?決策系統(tǒng)持續(xù)觀察擴容后用戶查詢的qps是否按照Cluster的比例增長了，或者用戶查詢的rt是否按照Cluster的比例降低了，如果沒有明顯增長，則認為擴容無效，決策將Cluster個數(shù)恢復成擴容前的個數(shù)，停止擴容決策運行，并預警。
• 縮容評估：決策系統(tǒng)持續(xù)觀察縮容后用戶查詢的qps和rt是否均有明顯變化，如果變化超過了一定的閾值，則將Cluster恢復成縮容前的個數(shù)，決策系統(tǒng)將Cluster個數(shù)恢復成縮容前的個數(shù)，停止縮容決策，并預警。

彈得好：負載均衡路由策略

在Cluster個數(shù)提升之后，用戶無需指定查詢路由到的Cluster，AnalyticDB MySQL自動根據(jù)負載均衡算法將查詢路由到負載最小的Cluster中。

下圖是一個根據(jù)Cluster負載均衡路由的示意圖。

1.?當Q5到來時，由于Cluster0的負載是2，Cluster1的負載是1，Cluster2的負載是1。Q5會優(yōu)先分配給Cluster1執(zhí)行。

2.?當Q6到來時，由于Cluster0的負載是2，Cluster1的負載是2，Q6會分配給Cluster2執(zhí)行。

總結(jié)及未來規(guī)劃

為了更好地貼合業(yè)務負載，充分利用資源，實現(xiàn)效益最大化，我們推出了AnalyticDB MySQL Multi-Cluster彈性模型，完成了自動化、智能化擴縮容。AnalyticDB MySQL Multi-Cluster形態(tài)有如下特點：

1. 成本：貼合業(yè)務負載自動擴縮容，相比單Cluster資源組固定資源，可以節(jié)省更多的成本；

2. 查詢性能：線性增加，查詢的隔離性相比Min-Max模型資源組要更優(yōu)越；

3. 自動彈性：避免了用戶手動調(diào)整資源組大小。

未來，我們還將在以下幾個方面繼續(xù)打磨和增強:文章來源地址http://www.zghlxwxcb.cn/news/detail-826298.html

• 主動彈性：基于預測的主動彈性，查詢延遲最小化；
• 負載解耦：基于WorkLoadManager，大query自動投遞到離線資源組減少對在線資源組的資源搶占；
• 彈性效率：資源Pod熱池加速彈性效率；
• 效果展示：性能優(yōu)化及成本節(jié)省可視化。

到了這里，關(guān)于自動彈性，QPS線性提升｜一文讀懂云原生數(shù)倉AnalyticDB彈性技術(shù)原理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！