孫天齊，胡建鵬,2，黃 娟，樊 瑩

(1.上海工程技術(shù)大學 電子電氣工程學院，上海 201620； 2.上海交通大學 計算機科學與工程系，上海 200240)

0 引言

如今越來越多Web應(yīng)用都選擇部署在云上[1]，而作為Web應(yīng)用的管理人員,同時作為云用戶，在保證服務(wù)質(zhì)量(Quality of Service， QoS)的前提下，要盡可能降低云服務(wù)支出費用。帶寬資源是云服務(wù)中一項主要支出項目，在按量付費的情況下，大多數(shù)云服務(wù)商對帶寬資源的定價方式設(shè)定為：在超過一定帶寬閾值后單位帶寬價格提高幾倍。對于一般的Web應(yīng)用，帶寬需求大部分時間都在一定的閾值范圍內(nèi)，但也會出現(xiàn)在特定的時間段內(nèi)帶寬需求增大，超出閾值，在這種情況下管理人員需要采取措施來進行帶寬管理以保證QoS，且盡可能使花費最小。另外對于在何種負載強度下會出現(xiàn)帶寬冗余同樣是管理人員需要提前獲取的知識，以便提前采取應(yīng)對策略，因此對帶寬資源管理的研究十分必要。

帶寬資源管理包含以下兩個重要方面：一方面是帶寬需求預測；另一方面是帶寬伸縮策略。帶寬需求預測是在一定負載強度下預測系統(tǒng)可能需要消耗的帶寬，對于基于Web的網(wǎng)絡(luò)密集型系統(tǒng)來說，帶寬資源總是成為影響性能的瓶頸[2]，而目前大多數(shù)資源管理研究只關(guān)注主要的計算資源，如CPU[3]、內(nèi)存[4]、磁盤I/O[3]等，其中CPU最受關(guān)注，很少涉及帶寬資源方面的研究。對于帶寬伸縮策略，管理人員一般采取以下幾種方式：帶寬增減、虛擬機(Virtual Machine， VM)增減和服務(wù)分離與組合等。帶寬增減是指直接增加或減少帶寬，而系統(tǒng)本身不發(fā)生改變，這種方式操作簡單；但是對于帶寬需求較大的Web應(yīng)用，增加帶寬可能會帶來較大的費用支出。虛擬機增減和服務(wù)分離與組合是在帶寬增減的基礎(chǔ)上另外執(zhí)行的策略。虛擬機增加是將原有的系統(tǒng)復制到多個虛擬機副本，然后通過負載均衡控制各個虛擬機的帶寬需求分配。該種方式可以使得單個虛擬機帶寬需求上限低于閾值，從而降低帶寬資源費用。虛擬機減少與虛擬機增加互為逆向操作。服務(wù)分離或組合是對系統(tǒng)結(jié)構(gòu)的拆分或重組，分離是將原本部署在同一臺虛擬機上的Web應(yīng)用服務(wù)分離，比如將圖片服務(wù)分離出來，移植到另一臺虛擬機，這種方式和虛擬機增加類似，但Web系統(tǒng)結(jié)構(gòu)會發(fā)生改變。組合則是將不同的服務(wù)整合到同一服務(wù)器。

針對各種計算資源預測的研究主要有以下幾種方法：分析建模[3,5]、測試[6-7]、仿真[8]和機器學習[9-10]。黃翔等[11]提出一種Web應(yīng)用自動建模方法用以性能剖析，他們采用基于概率的用戶行為圖模型描述負載，采用執(zhí)行圖描述事務(wù)之間的執(zhí)行流程，并均采用分層排隊網(wǎng)絡(luò)構(gòu)建模型，然后采用Kalman濾波進行服務(wù)時間估計；雖然該種方法可自動化建模，但其模型構(gòu)建過程相對復雜。WISE(What-If Scenario Evaluator)方法[9]通過學習影響內(nèi)容分發(fā)網(wǎng)絡(luò)響應(yīng)時間分布的因素之間相互關(guān)系構(gòu)建貝葉斯網(wǎng)絡(luò)，用以預測內(nèi)容分發(fā)網(wǎng)絡(luò)中配置和部署發(fā)生改變后產(chǎn)生的影響。盡管基于機器學習的方法適用于QoS的預測，且其中一些方法可不需要創(chuàng)建系統(tǒng)模型，但是機器學習方法只能學習過去出現(xiàn)的系統(tǒng)場景和配置，且需要收集足夠多的數(shù)據(jù)用以訓練。Kraken方法[6]通過不斷將實時用戶流量轉(zhuǎn)移到一個或多個數(shù)據(jù)中心來進行負載測試，并分析單個系統(tǒng)和系統(tǒng)集群的行為以識別資源瓶頸。這種基于測試的方法可以提供可信的結(jié)果，但是該方法通常需要考慮額外的計算資源，另外其涉及大量的開發(fā)工作。Alam等[8]開發(fā)了一種用于Web系統(tǒng)性能管理的離散事件仿真工具；其仿真參數(shù)需要人工設(shè)置，且該方法僅適用于性能評估。

本文利用網(wǎng)絡(luò)仿真工具模擬復雜網(wǎng)絡(luò)傳輸過程，以適應(yīng)帶寬資源需求和QoS預測，普通仿真工具無法實現(xiàn)。上述研究中大部分負載模型采用概率圖模型[12-13]來描述用戶行為。傳統(tǒng)事務(wù)型Web應(yīng)用，包含了多種不同的交互事務(wù)，且用戶行為由一系列會話，即對Web服務(wù)器的一系列請求(查詢網(wǎng)頁，下載圖片等)組成，同時包含對不同頁面的訪問時間以及會話持續(xù)時間。由于用戶行為的復雜性，導致概率圖模型也變得復雜，這極大地增加了仿真的難度和時長。本文針對這種會話型Web應(yīng)用，提出了一種簡化的并行負載模型，極大地簡化了用戶行為描述，使得模型參數(shù)簡化，并將此模型映射到網(wǎng)絡(luò)仿真工具之上；同時本文采用自動化數(shù)據(jù)挖掘方法從Web應(yīng)用訪問日志中獲取模型參數(shù)，進而通過仿真對不同負載強度下的帶寬需求及響應(yīng)時間進行預測。本文采用經(jīng)典的TPC-W基準測試系統(tǒng)[14]對所提方法進行驗證，并對不同帶寬伸縮方案進行仿真評估，評估結(jié)果可為Web應(yīng)用資源管理人員選擇何種方案提供參考。

1 建模與仿真方法

1.1 Web服務(wù)建模與仿真框架

大型Web系統(tǒng)通常由一系列分布式服務(wù)組件組成。其中大部分包含多層次的體系結(jié)構(gòu)，這些組件如用戶接口(Web服務(wù)器)、業(yè)務(wù)邏輯(應(yīng)用服務(wù)器)、數(shù)據(jù)存儲(文件服務(wù)器)和數(shù)據(jù)庫訪問(數(shù)據(jù)庫服務(wù)器)分別作為獨立的模塊進行維護。終端用戶使用瀏覽器發(fā)送請求，這些請求通過網(wǎng)絡(luò)傳輸?shù)絎eb服務(wù)器。Web服務(wù)的建模與仿真不僅需要設(shè)計系統(tǒng)模型來描述系統(tǒng)架構(gòu)，而且需要可以表示真實用戶行為的負載模型；同時，基于TCP的復雜網(wǎng)絡(luò)傳輸機制也需要在仿真框架中有所體現(xiàn)，因此，本文提出一個適用于Web服務(wù)的建模與仿真框架。

圖1為本文系統(tǒng)模型的架構(gòu)，包含從客戶端到服務(wù)器端的所有子模型。本文通過負載模型挖掘用戶行為和負載強度，通過Web服務(wù)模型獲取各服務(wù)的屬性，進而將模型映射到網(wǎng)絡(luò)仿真工具相對應(yīng)的物理模型中，模擬真實的網(wǎng)絡(luò)傳輸過程。

圖1 系統(tǒng)模型架構(gòu)Fig. 1 Architecture of system model

圖1中Profile模型是仿真工具中實現(xiàn)并行負載模型的組件，Application模型是仿真工具中模擬Web服務(wù)的組件，局域網(wǎng)(Local Area Network，LAN)模型用來模擬屬于同一用戶群組的客戶端，Switch模型模擬交換機，各服務(wù)器模型對應(yīng)真實的服務(wù)器。本文將Web服務(wù)定義為三元組(S，O，SG)，其中：S是指由Web應(yīng)用提供的一系列服務(wù)；O表示嵌入在服務(wù)中的各種對象，每個對象具有兩種屬性，即類型(如Web頁面、CSS (Cascading Style Sheets) 文件、JS (JavaScript) 文件、圖片或子頁面等)和該對象所占字節(jié)大小；SG(Service Group)是指具有相似性質(zhì)服務(wù)的集合，每個服務(wù)可以根據(jù)其性質(zhì)被分組到某一類SG中。另外本文將單次服務(wù)請求定義為六元組(t，u，s，o，b，rt)，其中：t表示服務(wù)請求時間，u表示請求用戶，s∈S，o∈O，b表示該請求接收字節(jié)數(shù)，rt表示請求該服務(wù)的響應(yīng)時間。Web服務(wù)模型參數(shù)將通過日志挖掘獲得。

本文所提仿真方法包含4個主要步驟：1)建立負載模型；2)建立系統(tǒng)模型；3)挖掘訪問日志以獲得模型參數(shù)；4)運行仿真驗證模型以及預測帶寬需求和響應(yīng)時間。由于負載特征的復雜性，本文提出了一種簡化的并行負載模型，同時采用自動化日志挖掘方法，可以有效減少模型構(gòu)建時間。

1.2 并行負載模型

本文負載模型的建立基于WESSBAS(Workload Extraction and Specification for Session-Based Application Systems)[12]方法，并在其基礎(chǔ)上作出一系列修改，以滿足對帶寬資源的預測需求。在前期工作[15]中，我們設(shè)置了一個固定長度的時間窗口用以建模和仿真。時間窗口設(shè)定之后，模型的建立和仿真過程都要按照該時間窗口設(shè)置。這種設(shè)置有兩個缺點：一方面時間窗口內(nèi)出現(xiàn)的用戶數(shù)量并不能代表并發(fā)的用戶數(shù)量，對于負載強度的統(tǒng)計無法與基準測試系統(tǒng)統(tǒng)一起來；另一方面時間窗口對用戶行為進行切片，破壞了用戶行為的完整性，因此本文去除了時間窗口的設(shè)置。

大多數(shù)負載模型存在一個共同的問題，即請求的順序和請求的數(shù)量由于遵循概率屬性而難以控制，但是這個問題并不影響對于帶寬需求的預測，因此本文假設(shè)在用戶的會話中服務(wù)請求是無序的。本文使用多條并行子路徑來代替對多個SG的串行請求序列，每一類SG的請求序列代表一條子路徑，如圖2所示。傳統(tǒng)的負載模型中，多以串行請求路徑來表征用戶行為，一般含有三個參數(shù)，即會話長度、請求間隔矩陣和請求之間的轉(zhuǎn)移概率矩陣，并且請求之間經(jīng)常出現(xiàn)循環(huán)路徑，這極大地提高了計算的復雜度。本文提出利用并行請求路徑來表達用戶行為，同樣具有三個參數(shù)，分別為開始偏移時間、到達間隔時間和會話持續(xù)時間，但并行路徑的設(shè)置避免了不同請求之間的相互轉(zhuǎn)移，并且不需要控制循環(huán)請求次數(shù)。關(guān)于參數(shù)的設(shè)置，在實際情況中，由于需要描述用戶會話的到達率，因此，本文添加開始偏移時間來確定用戶何時發(fā)起第一次服務(wù)請求。到達間隔時間指兩次請求之間到達的時間差，并且本文使用服務(wù)器端到達間隔時間來代替客戶端用戶的思考時間，因為所有的時間信息都是從服務(wù)器端日志中獲取。

圖2 并行負載模型Fig. 2 Parallel workload model

本文首先將具有相似行為模式的用戶劃分為若干群組(User Group, UG)，則負載模型可定義為行為組合(Behavior Mix，BM)與負載強度(Workload Intensity，WI)組成的二元組(BM，WI)。BM={B1，B2，…，Bn}，表示n個用戶群組的行為組合，其中Bi是某個用戶群組的服務(wù)請求行為，由多條SG并行路徑組成，多種行為按比例混合成行為組合。WI表示負載強度，它代表在會話持續(xù)時間內(nèi)出現(xiàn)的屬于不同用戶群組的用戶數(shù)量。

由于帶寬是一種并發(fā)消耗資源，不同于CPU的獨占性，故本文采用并行請求路徑來描述用戶行為，忽略了不同請求之間的順序，此種忽略對帶寬消耗以及服務(wù)質(zhì)量預測的影響不大。對于一個特定Web應(yīng)用，用戶對服務(wù)的請求將影響帶寬需求。本文并行負載模型忽略了對請求順序的控制，如圖2所示，并行路徑雖然分離了不同類型的服務(wù)請求，但在會話長度內(nèi)，請求之間的到達間隔時間同樣遵循串行路徑中對應(yīng)請求之間到達間隔時間的分布，使得對不同類型的服務(wù)獨立請求，即在一段時間內(nèi)對同一類型服務(wù)的請求時間較真實情況可能會提前或延后，但總請求數(shù)量變化不大。盡管這種設(shè)置會稍改變真實請求在時間上的順序，但從全局來看，一段時間內(nèi)的請求數(shù)量不會發(fā)生太大改變，使得本文所預測的全局性的帶寬消耗量也基本不會改變。這樣的設(shè)置同時使得負載模型變得相對簡單，所需要的模型參數(shù)也得到簡化。負載的生成需要用戶行為的描述以及負載強度的定義。本文在仿真時，以用戶數(shù)量來設(shè)置一定的負載強度，即可進行不同負載強度下帶寬等相關(guān)資源的預測。在仿真完成后，仿真時間內(nèi)總頁面請求數(shù)、服務(wù)器端發(fā)送的總字節(jié)數(shù)和平均頁面響應(yīng)時間等可以作為主要的比較度量。

1.3 系統(tǒng)模型及其參數(shù)

對帶寬需求和QoS的預測不僅需要表示真實用戶行為的負載模型，而且需要構(gòu)建系統(tǒng)模型來描述系統(tǒng)架構(gòu)。描述系統(tǒng)架構(gòu)需要基于組件的建模方法，目前已有很多體系結(jié)構(gòu)建模語言和工具具備這樣的能力，但是這些工具不能對如網(wǎng)絡(luò)協(xié)議和包傳輸之類的網(wǎng)絡(luò)問題進行建模，它們僅適合于非網(wǎng)絡(luò)系統(tǒng)的建?；蚝雎跃W(wǎng)絡(luò)資源的一些場景。一些常用的網(wǎng)絡(luò)仿真工具，如NS- 2[16]和OMNET+[17]雖然具備網(wǎng)絡(luò)建模功能，但并不適合對復雜的網(wǎng)絡(luò)應(yīng)用進行建模，而著名的OPNET[18]可以解決此問題。由于網(wǎng)絡(luò)的復雜性，預測Web系統(tǒng)的QoS相對困難。由于網(wǎng)絡(luò)擁塞控制和重傳對響應(yīng)時間有很大的影響，需要同時在應(yīng)用層和網(wǎng)絡(luò)層對系統(tǒng)進行細粒度建模，因此，選擇一個特定的網(wǎng)絡(luò)建模與仿真工具OPNET作為基礎(chǔ)的建模與仿真工具，并將本文所提仿真框架映射到OPNET模型之上，這些模型的特征參數(shù)即代表用戶行為和Web應(yīng)用的特征，以實現(xiàn)對真實場景的模擬。

表1顯示了本文所涉及的主要模型與參數(shù)的對應(yīng)關(guān)系，這些參數(shù)可以通過日志挖掘獲得或根據(jù)需要手動調(diào)節(jié)。

這些模型中的客戶端和服務(wù)器端均包含物理層、網(wǎng)絡(luò)層和應(yīng)用層三層架構(gòu)。在物理層，OPNET可以提供細粒度的建模來支持系統(tǒng)模型的構(gòu)建；在服務(wù)器端，多層Web系統(tǒng)由交換機和服務(wù)器組成；在客戶端，本文使用多個局域網(wǎng)模型來表示不同的用戶集群。所有這些模型通過IP云和路由器模型連接起來。

表1 模型與參數(shù)對應(yīng)關(guān)系 Tab. 1 Corresponding relationship between models and attributes

在網(wǎng)絡(luò)層，所有客戶端均配置HTTP 1.1協(xié)議。另外需要對TCP屬性進行一些配置，OPNET提供不同操作系統(tǒng)(如Windows、Linux、IOS、Android)的默認TCP設(shè)置。TCP參數(shù)也可以根據(jù)需求自定義配置，包括接收緩沖區(qū)大小、協(xié)議特定算法、重傳超時等。本文通過在Web訪問日志中查詢用戶信息字段(包括操作系統(tǒng)和瀏覽器的信息)來決定客戶端模型的TCP設(shè)置。在服務(wù)器端，服務(wù)器的TCP設(shè)置與真實實驗環(huán)境所采用的TCP設(shè)置相同。帶寬限制可以在服務(wù)器端和客戶端之間的鏈路屬性上指定?？蛻舳撕头?wù)器端之間的距離會影響服務(wù)請求的響應(yīng)時間，如果需要進行位置感知仿真，用戶的位置信息可以通過Web訪問日志中用戶的IP地址匹配獲得。本文采用TPC-W基準測試系統(tǒng)進行模擬實驗，所有用戶位置相同且已知，故可以直接設(shè)置客戶端模型位置。

在應(yīng)用層，使用標準的HTTP應(yīng)用模型來表示位于不同Web服務(wù)器和文件服務(wù)器中的Web服務(wù)。每個Web服務(wù)包含兩個主要參數(shù)，即到達間隔時間和頁面屬性。頁面屬性包含頁面嵌入對象的數(shù)量和字節(jié)大小。本文使用OPNET的Profile模型來描述用戶行為，其中需要指定開始偏移時間和會話持續(xù)時間。另外需要設(shè)置各局域網(wǎng)模型對應(yīng)用戶集群的用戶數(shù)量，同時仿真開始前需要設(shè)置仿真時長，且需要根據(jù)具體實驗設(shè)定。

1.4 從日志中挖掘模型參數(shù)

1.4.1 日志預處理

本文采用的日志為Web服務(wù)器訪問日志，為服務(wù)器記錄的標準日志，云用戶可從服務(wù)器中獲取。Web應(yīng)用訪問日志通常包含以下數(shù)據(jù)字段：請求的日期和時間、客戶端用戶IP地址和用戶代理、請求服務(wù)的統(tǒng)一資源標識符(Uniform Resource Identifier，URI)、協(xié)議狀態(tài)碼、發(fā)送的字節(jié)、引用站點等。在原始日志中，每行記錄表示一條請求，其可以是對Web頁面、JS文件、CSS文件、圖片或嵌入子頁面等服務(wù)的請求。在預處理階段，每一條記錄將根據(jù)其所請求服務(wù)的類型被添加不同的標簽。請求的日期和時間將合并在一起，并轉(zhuǎn)換成時間戳格式。每個用戶通過IP地址和用戶代理來唯一標識，但本文中所采用的TPC-W基準測試實驗為模擬用戶訪問Web應(yīng)用，所產(chǎn)生的日志文件中用戶IP信息均相同，故本文采用模擬瀏覽器ID來代替用戶IP。另外，單個頁面服務(wù)請求通常包含多個嵌入的對象，請求這些對象均會產(chǎn)生日志記錄，本文將屬于同一頁面服務(wù)的請求添加同一頁面標簽。

1.4.2 服務(wù)請求的分組

許多服務(wù)請求在結(jié)構(gòu)上非常相似。例如，某一用戶在電子商務(wù)網(wǎng)站瀏覽兩款不同的產(chǎn)品時，可能會導致兩個請求具有不同的URI，但其響應(yīng)結(jié)構(gòu)是相同的。在該步驟中，將相似的請求分組到同一個SG中。分組完成之后，將會忽略一些總請求數(shù)較少并且對服務(wù)器負載貢獻很小的SG，以簡化后續(xù)參數(shù)挖掘和仿真實驗過程。

1.4.3 參數(shù)挖掘

本文參數(shù)挖掘的過程是從處理之后的日志數(shù)據(jù)中提取參數(shù)的概率分布。本文主要采用兩種方法來獲取參數(shù)的概率分布。首先，本文使用分布擬合來估計參數(shù)概率分布。OPNET預先定義了多種刻畫參數(shù)隨機值的分布，本文將這些分布作為候選目標來擬合參數(shù)的概率分布，并通過擬合優(yōu)度檢驗選擇最佳模型。如果某一參數(shù)不能通過分布擬合來獲得概率分布，本文采用OPNET中的概率分布函數(shù)(Probability Distribution Function，PDF)模型來定義，PDF允許對隨機變化的值進行建模，因此能更真實地再現(xiàn)用戶行為。本文所需挖掘的參數(shù)為并行負載模型以及Web服務(wù)模型所涉及的開始偏移時間、到達間隔時間、會話持續(xù)時間以及頁面嵌入對象的數(shù)量和大小。

1.5 模型驗證與仿真預測

在進行預測之前，需要通過一系列的仿真實驗來驗證模型的準確性和穩(wěn)定性，即檢驗該模型預測的結(jié)果是否能表現(xiàn)出與原始日志數(shù)據(jù)相近的用戶行為。模型的驗證通過比較仿真結(jié)果和模擬實驗日志數(shù)據(jù)的同一性和差異性，本文選擇模擬實驗設(shè)置的模擬瀏覽器數(shù)量作為負載強度，因為模擬瀏覽器數(shù)量即等同于用戶數(shù)量，另外仿真時長設(shè)置與模擬實驗相同，然后計算仿真結(jié)果中的平均請求數(shù)和服務(wù)器總發(fā)送字節(jié)，與相應(yīng)的原始日志數(shù)據(jù)統(tǒng)計結(jié)果進行比較。

本文首先驗證在負載強度變化情況下的模型準確性。模擬實驗的原始日志文件將會分為兩部分：一部分作為訓練集和驗證集；另一部分作為測試集。本文以頁面平均響應(yīng)時間(Average Response Time，ART)作為主要的QoS度量進行預測，響應(yīng)時間是指用戶從發(fā)出HTTP請求與接收到響應(yīng)的最后一個字節(jié)之間的時間。

2 帶寬需求預測實驗

根據(jù)第1章的介紹，本文選取TPC-W基準測試系統(tǒng)進行實驗來驗證本文方法的有效性和準確性。

2.1 實驗設(shè)置

本文采用威斯康星大學實現(xiàn)的Java版TPC-W基準測試系統(tǒng)[19]，該系統(tǒng)是一種服務(wù)器性能測試工具，它支持模擬用戶瀏覽網(wǎng)頁和在網(wǎng)站上處理訂單等操作。本文所采用的TPC-W基準測試系統(tǒng)具體實現(xiàn)為一個電子商務(wù)網(wǎng)站和一個客戶端，網(wǎng)站設(shè)置有兩大類14種頁面，測試時每個模擬用戶在瀏覽一個頁面后，會隨機地進入到另外一個頁面，直到一次會話結(jié)束?？蛻舳四M用戶訪問網(wǎng)站，并收集一些訪問數(shù)據(jù)。訪問模式分為三種，根據(jù)用戶興趣度而設(shè)定，分別為瀏覽型、商務(wù)型和購物型，同時客戶端可以設(shè)置模擬訪問人數(shù)、測試時間和用戶思考時間等。本文模擬實驗采用貼近真實場景的商務(wù)型訪問模式。為了減少CPU資源競爭對服務(wù)質(zhì)量預測的影響，實驗中虛擬機的CPU利用率均控制在20%以下。

本文模擬實驗選擇在云服務(wù)器上實施。本文選擇了多臺阿里云服務(wù)器，分別位于上海和深圳，深圳地區(qū)云服務(wù)器作為TPC-W服務(wù)器端并采用CentOS 6.8操作系統(tǒng)，上海地區(qū)云服務(wù)器作為客戶端并采用Windows Server 2008操作系統(tǒng)；同時在服務(wù)器端安裝性能監(jiān)控工具，實時獲取服務(wù)器端性能數(shù)據(jù)。

服務(wù)器端帶寬設(shè)置為5 Mb/s，第一次實驗時間設(shè)置為5 h，模擬人數(shù)為30，該實驗數(shù)據(jù)作為訓練集和驗證集，另外分別進行50人、70人、90人、100人、105人、110人、118人、122人、130人、140人和150人共11次實驗作為測試集，每次實驗時間為30 min，每次實驗會得到客戶端訪問數(shù)據(jù)、服務(wù)器端性能監(jiān)控數(shù)據(jù)和原始訪問日志。

本文利用OPNET工具構(gòu)建了包含一臺服務(wù)器和一個局域網(wǎng)模型的系統(tǒng)架構(gòu)，并通過路由器和交換機相連接。局域網(wǎng)模型代表同類型的用戶集群，且被放置在上海區(qū)域，后續(xù)會根據(jù)實驗結(jié)果調(diào)整位置，以滿足響應(yīng)時間預測要求。服務(wù)器模型放置在深圳區(qū)域，帶寬限制為5 Mb/s，最后設(shè)置模型參數(shù)和負載強度以及仿真時長，負載強度和仿真時長與模擬實驗設(shè)置相同。

2.2 實驗結(jié)果及分析

2.2.1 參數(shù)挖掘

模型參數(shù)從30人實驗日志中獲得。通過數(shù)據(jù)處理發(fā)現(xiàn)用戶訪問的所有頁面中其中7類頁面總字節(jié)數(shù)占比96%以上，為了進一步簡化模型，本文忽略剩余其他頁面的影響。嵌入對象數(shù)量及大小均為固定值或離散分布，到達間隔時間均服從lognormal分布，如圖3所示為Home頁面到達間隔時間分布直方圖。開始偏移時間和請求持續(xù)時間分布無規(guī)律，故均采用OPNET進行PDF建模。

圖3 Home頁面到達間隔時間 分布直方圖Fig. 3 Distribution histogram of inter-arrival time of Home page

2.2.2 帶寬需求及QoS預測

首先進行模型驗證，即通過上述所建模型進行仿真，將仿真結(jié)果與訓練集數(shù)據(jù)進行比較。本次仿真實驗設(shè)置負載強度為30人，時長5 h，仿真過后比較總請求數(shù)量和服務(wù)器發(fā)送的總字節(jié)。

日志統(tǒng)計總請求次數(shù)為72 718，發(fā)送的總字節(jié)數(shù)為2 864 004 014 B,仿真結(jié)果總請求次數(shù)為67 783，發(fā)送的總字節(jié)數(shù)為2 890 102 556 B?？梢钥吹?，仿真結(jié)果都非常接近真實日志統(tǒng)計結(jié)果，服務(wù)器發(fā)送總字節(jié)相對誤差更是在1%之內(nèi)，而總請求數(shù)量相對誤差稍大，為6.8%，主要是由于參數(shù)挖掘過程中忽略了對總字節(jié)貢獻很小的頁面和服務(wù)。結(jié)果說明訓練的模型能很好地再現(xiàn)模擬實驗中的用戶行為。

其次測試模型預測能力。根據(jù)上述模型預測30人、50人、70人、90人、100人、105人、110人、118人、122人、130人、140人和150人的訪問結(jié)果。負載強度均設(shè)置與模擬實驗相同人數(shù)，仿真時長均設(shè)置為30 min。另外本文構(gòu)建經(jīng)典的線性回歸和非線性回歸預測模型對總請求次數(shù)和發(fā)送的總字節(jié)數(shù)進行預測，非線性回歸采用三次函數(shù)擬合，輸入為用戶數(shù)，最后將三種預測結(jié)果與日志統(tǒng)計結(jié)果進行比較，如圖4～5所示。

圖4為總請求數(shù)預測結(jié)果對比，圖4中可以看出，隨著負載強度不斷增大，網(wǎng)絡(luò)仿真預測結(jié)果曲線的趨勢和數(shù)值與日志統(tǒng)計結(jié)果相近，通過計算，其平均相對誤差為4.6%，相對誤差最小為1.5%，而線性回歸預測雖然在負載強度較小時呈現(xiàn)好的預測結(jié)果，但當負載強度達到120人以上，預測結(jié)果仍呈上升趨勢，而真實日志統(tǒng)計結(jié)果由于帶寬利用率達到上限已呈現(xiàn)出下降的趨勢。另外可以看到非線性回歸預測結(jié)果較好。圖5為服務(wù)器發(fā)送總字節(jié)數(shù)預測結(jié)果對比。同樣非線性回歸預測表現(xiàn)較好。對于線性回歸預測結(jié)果，隨著負載強度的增大，誤差相比網(wǎng)絡(luò)仿真預測越來越大，并且同樣不會由于負載強度過大導致帶寬利用率達到上限而出現(xiàn)與日志統(tǒng)計結(jié)果相似的趨勢。通過計算，網(wǎng)絡(luò)仿真預測的服務(wù)器發(fā)送總字節(jié)數(shù)平均相對誤差為3.3%，相對誤差最小為0.4%。結(jié)果說明網(wǎng)絡(luò)仿真的預測能力較好，且優(yōu)勢明顯，尤其對于發(fā)送總字節(jié)的預測更加準確，因此該方法很適合用于解決帶寬資源相關(guān)的預測問題。另外從圖中可以看到當人數(shù)為120～130時，預測結(jié)果出現(xiàn)下降的趨勢，這主要是由于此時帶寬消耗已超過5 Mb/s，出現(xiàn)了網(wǎng)絡(luò)擁塞和延遲等待的現(xiàn)象。

通過實驗和圖4以及圖5中的比較，相較于線性回歸預測模型，網(wǎng)絡(luò)仿真預測有以下幾點優(yōu)勢：1)預測結(jié)果更加準確，特別是當負載強度過大導致帶寬消耗達到上限時，其表現(xiàn)出與真實日志統(tǒng)計數(shù)據(jù)相近的結(jié)果；2)模型訓練需要更少的數(shù)據(jù)集，網(wǎng)絡(luò)仿真預測僅需要30人的實驗數(shù)據(jù)作為訓練集，而線性回歸預測至少需要30人和50人實驗數(shù)據(jù)作為訓練集，甚至更多；3)網(wǎng)絡(luò)仿真是對復雜網(wǎng)絡(luò)傳輸?shù)哪M，可以體現(xiàn)網(wǎng)絡(luò)傳輸?shù)耐暾^程，而線性回歸預測僅是對數(shù)值的預測；4)網(wǎng)絡(luò)仿真用一個模型一次實驗即可得到對總請求數(shù)、服務(wù)器發(fā)送總字節(jié)數(shù)以及頁面響應(yīng)時間的預測結(jié)果，而線性回歸需要構(gòu)建三個模型，且需要分別進行計算。

圖4 不同負載強度下總請求數(shù)預測結(jié)果比較Fig. 4 Prediction result comparison of total request number under different workload intensities

圖5 不同負載強度下總發(fā)送字節(jié)數(shù)預測結(jié)果比較Fig. 5 Prediction result comparison of total sent bytes under different workload intensities

對于非線性回歸方法，雖然其預測能力表現(xiàn)較好，但是該方法有兩大弊端：1)其模型的訓練需要30人至150人所有的實驗數(shù)據(jù)，難以實現(xiàn)以少量數(shù)據(jù)建模預測未知結(jié)果；2)該模型不能適用于演化場景。當系統(tǒng)場景演化，帶寬由5 Mb/s減小為4 Mb/s時，網(wǎng)絡(luò)仿真模型只需要將帶寬參數(shù)修改為4 Mb/s即可進行預測，而非線性回歸模型則無法繼續(xù)進行準確預測。圖6所示為系統(tǒng)帶寬為4 Mb/s時網(wǎng)絡(luò)仿真和非線性回歸兩種方法對總發(fā)送字節(jié)數(shù)的預測結(jié)果，可以看到非線性回歸預測出現(xiàn)很大誤差，而網(wǎng)絡(luò)仿真表現(xiàn)出較強的泛化能力，預測結(jié)果較好。綜上本文選擇網(wǎng)絡(luò)仿真進行帶寬需求及QoS預測。

圖6 演化場景下不同負載強度下總發(fā)送字節(jié)數(shù)預測結(jié)果比較Fig. 6 Prediction result comparison of total sent bytes under different workload intensities in evolutionary scenario

接下來進行QoS預測，本文假設(shè)云服務(wù)商可以根據(jù)服務(wù)協(xié)議提供穩(wěn)定的帶寬資源，即承諾達到的可利用帶寬均不低于用戶購買量。根據(jù)1.5節(jié)本文將頁面響應(yīng)時間作為主要的QoS度量進行預測，且僅比較平均響應(yīng)時間，即所有用戶對某一頁面請求的平均響應(yīng)時間。本實驗以Home頁面作為研究對象，首先根據(jù)30人實驗數(shù)據(jù)中所有用戶對Home頁面請求的平均響應(yīng)時間，適當微調(diào)局域網(wǎng)模型的位置，使得仿真結(jié)果接近真實結(jié)果，然后進行50人、70人、90人、100人、105人、110人、118人、122人、126人和130人的預測實驗，對比結(jié)果如圖7所示。該圖無法繼續(xù)用回歸方法來進行數(shù)據(jù)比較，因為低負載時，響應(yīng)時間的均值波動不大，使用低負載數(shù)據(jù)進行訓練并用回歸的方法來預測平均響應(yīng)時間不太可能，根本無法預知高負載時響應(yīng)時間均值逐漸升高的狀況。

圖7 負載強度增加下響應(yīng)時間預測結(jié)果比較Fig. 7 Prediction result comparison of response time with increased workload intensity

從圖7可以看出，預測結(jié)果與真實結(jié)果相近，趨勢相同，平均響應(yīng)時間在120人以后均呈明顯上升趨勢，且上升越來越快。通過查看性能監(jiān)控數(shù)據(jù)，發(fā)現(xiàn)在人數(shù)達到120至130之間時，帶寬消耗已達到5 Mb/s，已經(jīng)出現(xiàn)網(wǎng)絡(luò)擁塞甚至延遲重傳的現(xiàn)象，因此負載達到120人以后平均響應(yīng)時間迅速上升。通過上述對模型的驗證與測試實驗，可以看到訓練的模型預測結(jié)果具有較好的準確性，尤其對于帶寬需求的預測表現(xiàn)出色，故可將該方法用于對帶寬資源管理方案的評估。

3 帶寬伸縮方案評估實驗

為了進一步評估帶寬伸縮策略，本文以頁面平均響應(yīng)時間為主要評價指標。根據(jù)30人負載實驗獲得的基礎(chǔ)場景模型進行三種不同演化場景的仿真實驗。

3.1 實驗設(shè)置

三種演化場景實驗分別為帶寬增加、虛擬機增加和服務(wù)分離。三次實驗均基于帶寬消耗超過閾值，從2.2.2節(jié)可以看出當人數(shù)為130時已出現(xiàn)明顯響應(yīng)延遲，因此本文選取130人、140人和150人實驗作為基準，進行帶寬伸縮策略評估。本實驗仍采用home頁面平均響應(yīng)時間作為評價指標。帶寬增加場景即直接將帶寬從5 Mb/s升到6 Mb/s，系統(tǒng)結(jié)構(gòu)不發(fā)生變化；虛擬機增加場景為復制一個完全相同的虛擬機副本，帶寬同樣設(shè)置為5 Mb/s；服務(wù)分離場景為將圖片服務(wù)器分離出來，服務(wù)器集群總帶寬同樣升到6 Mb/s，并根據(jù)頁面圖片對象所占總字節(jié)數(shù)比例進行帶寬資源重組分配，以上場景均只需簡單修改基礎(chǔ)場景模型即可實現(xiàn)，而無需部署真實測試場景來評估這三種策略的好壞。

3.2 實驗結(jié)果及分析

仿真實驗分三次進行，負載強度分別為130人、140人和150人，仿真結(jié)果如表2所示。

從表2可以看出，相較于5 Mb/s帶寬，采取帶寬伸縮策略后平均響應(yīng)時間均明顯減小?？梢钥吹皆黾酉到y(tǒng)副本策略平均響應(yīng)時間最小，服務(wù)分離策略平均響應(yīng)時間最長。虛擬機增加減輕了對單一服務(wù)器的負擔，且總帶寬更大；服務(wù)分離雖減輕了單一服務(wù)器的壓力，但兩服務(wù)器之間仍然存在依存關(guān)系。方案選擇不僅需要考慮性能因素，且需要考慮成本。以阿里云服務(wù)器帶寬包年包月計費標準[20]為例，單位帶寬價格隨著帶寬的增加而增加，當帶寬超過5 Mb/s時，超出部分單位帶寬價格為原價格的3倍以上，因此最終選擇何種策略需要綜合考慮，比如要考慮增加服務(wù)器的費用。本文旨在提出進行帶寬伸縮策略評估的方法，對于不同的Web應(yīng)用、不同演化場景，均可采用該方法進行評估。

表2 帶寬伸縮策略平均響應(yīng)時間對比Tab. 2 Comparison of average response time under bandwidth scaling strategies

4 討論

本文主要面向?qū)eb應(yīng)用部署在云上的云用戶，而非云服務(wù)商，云用戶不能獲取其云上鄰居(其他租戶)的情況，因此本文并未考慮性能干擾等情況；但本文實驗均在真實云環(huán)境中進行，若存在虛擬機之間的性能干擾，其影響必然會在日志中有所體現(xiàn)，而本文模型參數(shù)均來自于日志，出于此種考慮，本文暫不單獨考慮云計算環(huán)境下的性能干擾等情況。

在本文所有實驗中，為簡化模型和處理過程，以及模型自身特點等原因，會導致實驗結(jié)果出現(xiàn)一些偏差，進而影響最后預測結(jié)果的精度。具體如下：在參數(shù)挖掘和仿真實驗過程中，忽略了對總發(fā)送字節(jié)數(shù)影響較小的用戶類別和服務(wù)組；對參數(shù)進行分布擬合時均為近似擬合；另外采用OPNET中的概率分布函數(shù)定義參數(shù)分布時，對數(shù)據(jù)進行了分段平均。在實驗結(jié)果的比較中，部分比較的結(jié)果是選取平均值進行比較，弱化了局部的數(shù)據(jù)特征。

5 結(jié)語

本文提出了一種基于網(wǎng)絡(luò)仿真的帶寬需求和QoS預測方法。其中包含一種簡化的并行負載模型，將串行請求路徑轉(zhuǎn)化為并行路徑，簡化了建模過程；運用自動化日志挖掘方法提取模型參數(shù)，從而加快模型建立；并利用TPC-W驗證了該方法的有效性和準確性，進一步評估了不同帶寬伸縮策略的好壞，為Web應(yīng)用管理人員提供參考。本文負載建模僅針對傳統(tǒng)事務(wù)型應(yīng)用，未考慮無狀態(tài)的Serverless服務(wù)、微服務(wù)架構(gòu)、批數(shù)據(jù)處理任務(wù)等負載建模，這些負載建模可以作為未來的研究內(nèi)容。后續(xù)，將會對本文方法中的參數(shù)挖掘過程進一步簡化并完善，并計劃將本文方法應(yīng)用到其他多種計算資源的研究中。