這篇文章是發(fā)在2018年CSUR上的一篇文章，主要是講虛擬機(jī)上web應(yīng)用的auto-scaling技術(shù)的分類　

? ? ? ?近年來(lái)許多web 應(yīng)用服務(wù)商將他們的應(yīng)用遷移到云數(shù)據(jù)中心，為什么要遷移到云上呢？其中一個(gè)重要的原因就是云數(shù)據(jù)中心的資源的彈性伸縮，這可以讓他們根據(jù)實(shí)時(shí)的需求獲取或者釋放計(jì)算資源，降低運(yùn)營(yíng)成本。為了更高效地實(shí)現(xiàn)彈性伸縮，就引出本文討論的一種技術(shù)：auto-scaling

　　那什么是auto-scaling呢？

　　Auto-scaling是一種在無(wú)需人工干預(yù)的情況下,根據(jù)實(shí)時(shí)工作負(fù)載自動(dòng)調(diào)整資源供給的技術(shù)，它能夠?qū)崿F(xiàn)在滿足服務(wù)質(zhì)量（QoS）需求的同時(shí)最小化云資源使用成本。

　　目前auto-scaling技術(shù)主要有四個(gè)階段來(lái)完成

?

?因此在分類的時(shí)候在這四個(gè)階段的基礎(chǔ)上進(jìn)行分類

?

?

?

Scaling Indicators

Auto-scaler的行為基于監(jiān)控階段獲得的應(yīng)用該性能指標(biāo)

①??? Low-level Metrics (physical/hypervisor)

• 監(jiān)控CPU利用率、內(nèi)存、缺頁(yè)率
• 僅僅看一些物理上的指標(biāo)難以精確推斷應(yīng)用程序性能

②??? High-Level Metrics（application）

• 監(jiān)控平均響應(yīng)時(shí)間、會(huì)話創(chuàng)建率、吞吐量、服務(wù)時(shí)間、請(qǐng)求組合
• 難以精確推斷需要的資源總數(shù)

③??? Hybrid Metrics

同時(shí)監(jiān)控Low-level Metrics 和High-Level Metrics

?

Scaling Timing

①??? Reactive Scaling

• 僅依據(jù)當(dāng)前的應(yīng)用和負(fù)載狀態(tài)進(jìn)行伸縮
• 適用于工作負(fù)載變化比較小的應(yīng)用

②??? Proactive Scaling

• 在伸縮時(shí)考慮應(yīng)用未來(lái)的資源需求
• 適用于有規(guī)律的工作負(fù)載變化較大的應(yīng)用
• 除考慮歷史工作負(fù)載外，還可考慮外部因素，如戶外應(yīng)用需考慮天氣情況

如果工作負(fù)載沒(méi)有規(guī)律，Proactive無(wú)法進(jìn)行預(yù)測(cè)，還是要用Reactive，因此auto-scaler無(wú)論支持不支持Proactive，都應(yīng)該能進(jìn)行Reactive Scaling

?

Scaling Methods

①??? Vertical Scaling

• 以虛擬機(jī)內(nèi)部資源為單位（CPU，存儲(chǔ)）
• 大多數(shù)廠商不支持
• 擴(kuò)展速度比垂直擴(kuò)展快
• 適用于一些不適合垂直擴(kuò)展的部分

②??? Horizontal Scaling

• ??以虛擬機(jī)為單位
• ??價(jià)格模型
  • On-demand：固定價(jià)格
  • Reserved：交一部分定金以獲得更便宜的價(jià)格
  • Rebated：售賣空閑資源，非常優(yōu)惠，隨時(shí)可以回收

③??? Hybrid

只有在水平擴(kuò)展收到限制時(shí)才使用垂直擴(kuò)展

?

Application Architectures

①??? Single Tier / Single Service

• 分層軟件棧中最小可部署組件
• 可管理的最小粒度

實(shí)際應(yīng)用中只有一層或只有一個(gè)服務(wù)的web應(yīng)用是很少的，因此Single Tier常被當(dāng)做是可管理的最小粒度，現(xiàn)今大多數(shù)的auto-scaling系統(tǒng)都是分別管理web應(yīng)用的每一層，而不是以一個(gè)整體管理。這就有一個(gè)問(wèn)題，雖然每層是最佳的資源配置，但從整體來(lái)看不一定是最佳的資源配置

?

②??? Multitier

• Front-end
• Application logic
• Database( 忽視)

多層應(yīng)用通常包括以上三層，各層之間順序連接，可以將總體的SLA劃分成每一層的SLA。因?yàn)榇蠖鄶?shù)云服務(wù)提供商都不支持不支持水平擴(kuò)展，通常database不會(huì)進(jìn)行auto-scaling

?

③??? Service-Based Architectures

• ?Service-Oriented Architecture (SOA)
• ?Microservices Architecture

Service-based在大型的web應(yīng)用中已占據(jù)主導(dǎo)地位，各獨(dú)立的服務(wù)通過(guò)各自預(yù)先定義的接口進(jìn)行交互。服務(wù)之間不是順序連接的，那它怎么做auto-scaling呢？

它要求每一個(gè)服務(wù)都要估計(jì)一個(gè)實(shí)例被添加或刪除時(shí)的響應(yīng)時(shí)間的變化。在此之后，系統(tǒng)會(huì)聚合估計(jì)，并選擇將最小總體響應(yīng)時(shí)間的操作。

?

Session Stickiness

會(huì)話（Session）：用戶與應(yīng)用之間的一系列交互行為

在每一次操作之后，用戶都要等待應(yīng)用的應(yīng)答，然后繼續(xù)執(zhí)行。

粘性（Stickiness）:如果會(huì)話數(shù)據(jù)存儲(chǔ)在服務(wù)器中，每次在會(huì)話中提交請(qǐng)求時(shí)，迫使用戶連接到同一臺(tái)服務(wù)器

①??? Sticky

②??? Non-sticky

粘性會(huì)限制auto-scaling系統(tǒng)的能力。因?yàn)槿绻绻形赐瓿傻臅?huì)話時(shí)，它們會(huì)限制auto-scaler終止沒(méi)有充分利用資源的實(shí)例

那要怎么解決這個(gè)問(wèn)題呢？一個(gè)方法是可以把會(huì)話數(shù)據(jù)存儲(chǔ)在用戶端，或者存儲(chǔ)在一個(gè)共享的虛擬機(jī)上

?

Adaptivity

對(duì)生產(chǎn)環(huán)境、工作負(fù)載變化的適應(yīng)能力

①??? Nonadaptive

• 預(yù)先確定控制模型，不允許在生產(chǎn)時(shí)自動(dòng)調(diào)整
• 需要做大量的線下測(cè)試才能獲取合適的控制模型
• 要求用戶定義一組伸縮的條件和離線操作，并且Nonadaptive它只根據(jù)即時(shí)的輸入進(jìn)行決策，只有當(dāng)滿足預(yù)先設(shè)定的條件時(shí)，才進(jìn)行伸縮操作

②??? Self-Adaptive

• 預(yù)先確定核心控制模型（線性\非線性），具體操作自動(dòng)調(diào)整
• 自動(dòng)調(diào)整需要比較長(zhǎng)的時(shí)間，前期表現(xiàn)較差

③??? Self-Adaptive Switching

連接多個(gè)Nonadaptive和Self-Adaptive，根據(jù)性能選擇控制模型

?

Resource Estimation

①??? Rule-Based Approaches

• 一組包含觸發(fā)條件和對(duì)應(yīng)行為的預(yù)定義規(guī)則
• 難以設(shè)置合適閾值和對(duì)應(yīng)行為，無(wú)法適應(yīng)應(yīng)用的動(dòng)態(tài)變化

例如CPU利用率超過(guò)70%，增加兩個(gè)實(shí)例，如果CPU利用率低于40%，減少一個(gè)實(shí)例

比如說(shuō)一開(kāi)始一個(gè)應(yīng)用由四個(gè)實(shí)例提供資源，那這時(shí)候增加一個(gè)實(shí)例就可以提升25%的能力提升。之后因?yàn)楣ぷ髫?fù)載的激增，由十個(gè)實(shí)例來(lái)提供資源，這時(shí)增加一個(gè)實(shí)例只能帶來(lái)10%的能力提升。

此外固定的閾值也可能會(huì)帶來(lái)低效的資源呢利用，70%和40%的資源利用率可能適合于只有實(shí)例較少的云，但是對(duì)于實(shí)例比較多的云，一個(gè)單獨(dú)的實(shí)例的增減可能對(duì)整體的資源利用率并不明顯，因此在資源利用率低于40%之前就可能要移除比較多的實(shí)例

?

②??? Fuzzy Inference

觸發(fā)條件語(yǔ)義化（高，中，低）

?輸入首先使用定義的成員函數(shù)進(jìn)行模糊化;然后，模糊化的輸入被用來(lái)在所有規(guī)則中同時(shí)觸發(fā)動(dòng)作部分;然后將規(guī)則的結(jié)果組合在一起，最后將其作為控制決策的輸出

?

③??? Application Profiling

尋找資源的飽和點(diǎn)

l? Offline ：每次應(yīng)用更新都需要手動(dòng)重新執(zhí)行一次

l? Online ：禁止細(xì)粒度的性能分析，要求盡可能快

從每一應(yīng)用層中獲得資源估計(jì)模型。當(dāng)對(duì)一層進(jìn)行性能分析時(shí)，給其他層足夠的資源，一個(gè)接一個(gè)，最后得到模型

?

④??? Analytical Modeling

Analytical Modeling是根據(jù)理論和分析建立數(shù)學(xué)模型的過(guò)程

基于排隊(duì)理論/排隊(duì)網(wǎng)絡(luò)

?????? A：到達(dá)隊(duì)列的時(shí)間間隔分布? Markov/General

?????? S：處理工作所需要的時(shí)間分配? Markov/Deterministic/General

?????? C：服務(wù)器的數(shù)量

?

⑤??? Machine Learning

• Reinforcement Learning（Q-learning）
• Regression（Linear）

學(xué)習(xí)的時(shí)間長(zhǎng)，初期表現(xiàn)差，并且收斂的時(shí)間難以預(yù)測(cè)

強(qiáng)化學(xué)習(xí)目的是讓軟件系統(tǒng)學(xué)習(xí)如何在特定的環(huán)境中進(jìn)行自適應(yīng)的反應(yīng)，以最大化其收益。學(xué)習(xí)算法選擇一個(gè)單獨(dú)的操作，然后觀察結(jié)果。如果結(jié)果是正的，那么在遇到類似情況時(shí)，自動(dòng)定標(biāo)器將更有可能采取相同的動(dòng)作。

回歸估計(jì)變量之間的關(guān)系。它根據(jù)觀察到的數(shù)據(jù)生成一個(gè)函數(shù)然后用它來(lái)進(jìn)行預(yù)測(cè)，要求用戶決定函數(shù)類型，

?

⑥??? Hybrid Approaches

• Machine Learning + Fuzzy rules-based inference
• Machine Learning + Analytical model
• 選擇不同的指標(biāo)和不同的機(jī)器學(xué)習(xí)算法

對(duì)web應(yīng)用來(lái)說(shuō)以上的幾種都有他的優(yōu)點(diǎn)和缺點(diǎn)，因此一些工作將多種方式整合在一起用來(lái)資源預(yù)測(cè)Rule在應(yīng)用發(fā)生變化時(shí)不靈活，并且需要專業(yè)知識(shí)來(lái)進(jìn)行設(shè)計(jì)和測(cè)試，如果rules由機(jī)器學(xué)習(xí)算法來(lái)動(dòng)態(tài)生成一些分析隊(duì)列模型需要一些難以直接測(cè)量的性能指標(biāo)請(qǐng)求服務(wù)時(shí)間，請(qǐng)求組合，在機(jī)器學(xué)習(xí)的收斂前用其他算法代替

?

Oscillation Mitigation

波動(dòng)（Oscillation）：auto-scaler不斷地執(zhí)行相反的操作，當(dāng)監(jiān)控或縮放操作過(guò)于頻繁時(shí)，或者規(guī)則配置不當(dāng)（區(qū)間太小）有可能會(huì)發(fā)生

①??? Cooling Time

• 固定等待時(shí)間
• 延長(zhǎng)等待時(shí)間

②??? Dynamic Parameters

當(dāng)大多數(shù)資源被用來(lái)降低目標(biāo)的使用率時(shí)，提高它的下降的閾值

?

③??? Exhaustion

如果可以找到造成波動(dòng)的設(shè)定，那就可以在這些設(shè)定上做限制

?

Environment

①??? Single Cloud

上面講的都是single云的情況

?

②??? Multiple Coluds

①??? 在每一個(gè)數(shù)據(jù)中心都部署一整個(gè)應(yīng)用

②??? 在不同的數(shù)據(jù)中心分別部署應(yīng)用的某個(gè)部分

③??? 優(yōu)勢(shì)：

• 降低延遲，在距離用戶最近的云中心進(jìn)行服務(wù)
• 提高可靠性，多個(gè)云同時(shí)備份
• 在auto-scaling時(shí)考慮地區(qū)選擇和請(qǐng)求路徑

?

未來(lái)的發(fā)展方向

①??? Service-Based Architectures

缺少精確的資源估計(jì)模型，實(shí)時(shí)計(jì)算出每一個(gè)服務(wù)應(yīng)該被提供的資源

?

②??? Monitoring Tools for Hidden Parameters.

計(jì)算一些不能直接獲得的數(shù)據(jù)：平均服務(wù)時(shí)間，請(qǐng)求組合

?

③??? Resource Estimation Models

需要提高現(xiàn)在的資源估計(jì)模型的精確度，通用性和易用性。認(rèn)為將分析模型和機(jī)器學(xué)習(xí)相結(jié)合最有前景

?

④??? Provisioning Using Rebated Pricing Models

星云

?

⑤??? Better Vertical Scaling Support

同一個(gè)物理機(jī)內(nèi)部延遲比較低，可以對(duì)database進(jìn)行auto-scaliing

⑥??? Event-Based Workload Prediction

考慮天氣，雙十一等事件

⑦??? Energy and Carbon-Aware Auto-Scaling

⑧??? Container-Based Auto-Scalers

?

轉(zhuǎn)載于:https://www.cnblogs.com/yuxiaoba/p/9349521.html

總結(jié)

以上是生活随笔為你收集整理的Auto-Scaling Web Applications in Clouds: A Taxonomy and Survey读书笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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