大資料實用 DevOps/迭代增強

簡介

DICE 的目標是提供一個新的 UML 配置檔案和工具，幫助軟體設計師分析資料密集型應用程式的質量，例如效能、可靠性、安全性以及效率。此外，DICE 開發了一種新的方法，涵蓋質量評估、架構增強、持續測試以及敏捷交付，依託於新興 DevOps 正規化的原則。特別是，DICE 的目標之一是構建工具和技術來支援資料密集型應用程式質量特性的迭代改進，透過向開發者提供反饋來引導架構設計變更。

為了實現這一目標，DICE 增強工具被開發出來，以向 DICE 開發者提供關於應用程式執行時行為的反饋，利用來自 DICE 監控平臺 (DMon) 的監控資料，幫助他們迭代地增強應用程式設計。DICE 增強工具引入了一種新方法和一個原型，以彌合測量和 UML 圖表之間的差距。它將監控資料與 DICE UML 模型相關聯，旨在彌合 UML 抽象與具體系統實現之間的語義差距。基於獲取的資料，DICE 增強工具允許開發者在 DICE IDE 中進行更精確的模擬和最佳化，可以依賴於實驗資料，而不是未知引數的猜測。DICE 增強工具還支援開發者進行重構場景，旨在以 DevOps 方式迭代地提高應用程式質量。據我們所知，在資料密集型應用程式 (DIA) 的研究文獻中，沒有成熟的方法可以解決從測量返回軟體模型、註釋 UML 以幫助分析應用程式設計的難題。DICE 增強工具旨在填補這一空白。

DICE 增強工具的核心元件是兩個模組

• DICE 彌合差距 (FG) 模組，一個專注於用於模擬 和最佳化工具 的 UML 引數統計估計工具。該工具透過依賴於執行時收集的監控資訊，為引數化應用程式設計時 UML 模型提供資料。目標是增強和自動化將應用程式效能資訊傳遞給開發者的流程。
• DICE 反模式與重構 (APR) 模組，一個用於反模式檢測和重構的工具。該工具根據觀察到的和預測的效能和可靠性指標，為 DIA 的設計師提供建議改進。目標是最佳化一個參考指標，例如最大化延遲或最小化平均故障間隔時間 (MTTF)。

動機

我們開發了 DICE 增強工具，它源於根據測試和執行期間獲取的資料（尤其是效能資料）推斷軟體設計中的不良實踐（即效能反模式）的問題。由於系統執行時和設計時之間的抽象級別不同，開發者必須獲得執行時資訊，尤其是效能指標，並將它們反映到設計時模型中，才能分析應用程式設計的質量並推斷重構決策。

為了在設計時模型中支援效能分析，開發者需要依賴於軟體效能模型進行進一步的分析和評估。但是，為了提供可靠的估計，輸入引數必須不斷更新並準確估計。準確估計具有挑戰性，因為某些引數沒有被日誌檔案明確跟蹤，需要進行深度監控儀器，這會造成很大的開銷，在生產環境中是不可接受的。此外，效能反模式 (AP) 是透過不正確的軟體決策識別的反覆出現的問題。軟體 AP 在行業中得到了廣泛的研究。軟體專案的規模和複雜性不斷增加，會導致新障礙更頻繁地出現。因此，在專案生命週期的早期階段識別 AP 可以節省資金、時間和精力。為了檢測 DIA 的效能反模式，首先需要指定設計時模型（即架構模型）和效能模型，以及模型到模型的轉換規則。架構模型作為系統的設計時模型，在 DICE 中由 UML 指定。在實踐中，開發者通常使用 UML 的活動圖和部署圖來建模系統行為和基礎設施配置。作為最先進的技術，UML 是一種通用的軟體工程建模語言，它提供了一種標準化的方法來視覺化系統的設計。儘管它很受歡迎，但 UML 不適合自動分析（例如效能評估）。因此，模型分析階段需要將帶註釋的 UML 圖表轉換為效能模型，例如 Petri 網、分層排隊網路 (LQN)；我們的工作也考慮將 LQN 作為效能模型。就效能指標而言，LQN 比 UML 更有優勢，因為 LQN 不僅以簡潔易懂的方式描述了這些指標，而且還支援各種分析和模擬工具，例如 LINE、lqns，因此允許自動化系統性能分析以進一步檢測效能反模式，並進一步檢測 AP。

為了實現上述目標，我們開發了 DICE 增強工具，以彌合執行時效能測量與設計時模型之間的差距，用於反模式檢測和重構。

現有解決方案

DICE-FG 最初是依賴於 MODAClouds 專案提供的基線開發的，該基線稱為 FG，它是一種彌合開發和運維之間差距的方法。在 DICE 中，該工具經歷了重大修訂，正在整合和調整以在 DIA 資料集上執行。與原始 FG 相比，DICE-FG 中引入了架構變更。與 DICE-FG 不同，APR 沒有基線軟體可以開始使用，因為此領域中唯一可用的工具不適用於 UML。因此，據我們所知，它是 DICE 的一項原創貢獻，在 UML 領域是新穎的。

在我們進行桌面研究的過程中，我們發現了以下解決方案，可以被認為是我們 DICE 增強工具的直接競爭對手。

LibReDE：一個包含用於線上和離線分析的資源需求估計方法的實現庫。LibReDE 用於一般分散式系統，而 DICE-FG 專門針對資料密集型應用程式設計；LibReDE 主要關注效能模型的資源需求估計，而 DICE-FG 則關注效能和可靠性估計；LibReDe 的估計輸入的測量資料是從標準 CSV 檔案中讀取的，而 DICE-FG 的輸入資料的格式是更流行的 JSON 檔案，透過 DMon 傳遞；LibReDE 無法將估計結果反映到設計時模型中，而 DICE-FG 則不斷地使用估計的效能和可靠性指標對設計時模型（用 DICE 配置檔案註釋的 UML 模型）進行引數化，這可以告知開發者如何重構軟體架構。

KieKer：是一個可擴充套件的框架，用於監控和分析併發或分散式軟體系統的執行時行為。KieKer 支援應用程式級別的效能監控，包括允許選擇資料以進行進一步分析的過濾器。然而，DICE-FG 可以分析設計時模型，以從執行時監控資料中提供更準確的模型引數推斷。因此，DICE-FG 工具不僅僅是簡單的監控，它被設想為一個機器學習元件，它瞭解應用程式軟體架構，並可以利用它來改進引數學習。

PANDA：它是一個框架，用於透過效能反模式來解決結果解釋和反饋生成問題。DICE-APR 遵循類似的方法來自動檢測和解決效能問題。PANDA 和 DICE-APR 之間的共同點是它們都利用 UML 模型作為它們的設計時模型（即架構模型），而 DICE-APR 的輸入 UML 模型則用特定配置檔案（DPIM、DTSM 和 DDSM）進行註釋，這些配置檔案指定了大資料應用程式和平臺的獨特屬性。PANDA 使用排隊網路作為其效能模型，而 DICE-APR 可以考慮 Petri 網或分層排隊網路模型。DICE-APR 的重構處理專注於大資料應用程式，並將改進以前關於重構雲應用程式的工作，它將考慮大資料應用程式的硬體和軟體知識。

PAD: PAD 是一個基於規則的效能診斷工具，名為效能反模式檢測（PAD）。PAD 僅關注基於元件的企業系統，針對 EJB 應用程式，而 DICE-APR 則關注大資料應用程式和平臺。它們都基於對執行系統的監控資料，但 PAD 的範圍僅限於特定領域，而 DICE-APR 的起點是更通用的資料密集型應用程式的 UML 模型。

工具的工作原理

DICE 增強工具旨在迭代地增強 DIA 的質量。增強工具旨在提供大資料應用程式的效能和可靠性分析，使用分析結果更新 UML 模型，並在檢測到效能反模式時提出設計重構建議。下圖顯示了增強工具的工作流程。它涵蓋了其所有預期功能，這些功能將在下面詳細討論。

DICE 增強工具

DICE-FG

作為增強工具的核心元件，DICE-FG 工具扮演著兩個角色

• 更新設計時模型的引數（使用 DICE Profile 註釋的 UML 模型）
• 在 UML 中提供資料密集型應用程式的資源使用細分資訊

這些功能共同為 DICE 設計師提供了以下可能性：

• 受益於模擬和最佳化模型的半自動化引數化。這支援 DICE 的狀態目標，即降低 DICE 平臺的學習曲線，以便那些在效能和可靠性工程方面技能有限的使用者能夠使用。
• 在 Eclipse 中檢查 DICE-FG 自動放置的註釋，以瞭解工作負載在軟體和基礎設施資源上的資源使用情況。

DICE-FG 工具的主要邏輯元件是分析器和執行器。下面我們將描述每個元件。

• DICE-FG 分析器：DICE-FG 分析器執行必要的統計方法以獲得性能模型引數的估計值，依賴於輸入檔案上可用的監控資訊。
• DICE-FG 執行器：DICE-FG 執行器更新 UML 模型中的引數，例如資源需求、思考時間，這些引數是從 DICE-FG 分析器獲取的。

DICE-APR

DICE-APR 模組旨在實現以下目標

• 將使用 DICE Profile 註釋的 UML 圖轉換為效能模型，以進行效能分析。
• 以正式的方式指定選定的流行 DIAs AP。
• 從效能模型中檢測潛在的 AP。
• 生成重構決策以更新架構模型（手動或自動），以根據 AP 解決方案修復設計缺陷。

APR 模組的元件是模型到模型 (M2M) 轉換 (Tulsa)、反模式檢測和架構重構 (APDR)，如下所述。

• 模型到模型 (M2M) 轉換 (Tulsa)：該元件提供將使用 DICE Profile 註釋的 UML 模型轉換為質量分析模型的功能。目標效能模型是分層排隊網路。
• 反模式檢測和重構 (APDR)：該元件依賴於 Tulsa 的分析結果。選定的反模式（即無限等待 (IW)、過度計算 (EC)）被正式指定，以識別模型中是否存在任何反模式問題。根據發現的反模式的解決方案，將提出重構決策（例如，元件替換或元件重新分配）來解決它們。架構模型將共享回 DICE IDE 以進行演示，以便使用者決定是否應該應用建議的修改。

開放挑戰

DICE 增強工具假設設計師使用 UML 來表示架構模型（即活動圖和部署圖），並使用 LQN 模型作為效能模型。如果沒有 UML 模型，使用者必須根據他們的架構模型手動定義 LQN 模型。這可能會導致額外的努力。此外，DICE-APR 目前可以檢測兩種效能反模式，其目標是基於 Storm 的大資料應用程式。

應用領域：已知用途

DICE FG

DICE-FG 已跨越各種技術，包括 Cassandra、Hadoop/MapReduce。例如，DICE-FG 為 hostDemands 提供了一種新穎的估算器，它能夠有效地解釋對大資料系統監控的所有狀態資料。大資料應用程式的 hostDemands 可以被看作是請求在資源上花費的時間。例如，Cassandra 查詢型別為 $c$ 在 Cassandra 叢集的節點 $r$ 上的執行時間。DICE-FG 分發中包含了一種名為 EST-LE（邏輯擴充套件）的新需求估算方法。此方法能夠使用機率最大似然估算器來獲得 hostDemands。這種方法比以前的方法 est--qmle 更具表現力，因為它除了透過監控獲得的狀態樣本外，還包含有關請求響應時間的資訊。為了提供這種方法而克服的一個障礙是，由此產生的最大似然方法在計算上難以處理，導致似然函式計算的執行時間非常慢。還開發了一種漸近逼近方法，它允許即使在具有多個資源、請求型別和高並行級別的複雜模型中也能有效地計算似然函式。

DICE-APR

DICE-APR 的實際應用是針對基於 Storm 的應用程式。DICE-APR 適合基於 Storm 的應用程式有兩個原因。首先，由於 Storm 拓撲可以被視為交換訊息的緩衝區和處理元素的網路，因此將它們對映到排隊網路模型中是很自然的。Storm 應用程式的核心元素（即 Spout 和 Bolt）之間的互動以及部署資訊也可以很容易地由 UML 活動圖和部署圖指定，這些圖在語義上類似於 LQN 模型。因此，DICE-APR 將基於 Storm 的應用程式的 UML 模型（使用 DICE 和 MARTE Profile 註釋）作為輸入，並生成一個性能模型（即分層排隊網路 (LQNs) 模型）以進行效能分析。其次，在軟體工程中，AP 是在不同層次結構級別（架構、開發或專案管理）中由不正確的軟體決策識別的反覆出現的問題。效能 AP 在行業中得到了廣泛的研究。然而，其中很少有人關注資料密集型應用程式的 AP。因此，我們研究了三種經典的 AP，即迴圈尋寶、Blob 和擴充套件處理，併為 DICE-APR 定義了基於 Storm 的應用程式的兩種反模式（即無限等待和過度計算）。以下是這些 AP 的問題陳述以及相應的解決方案。

• 無限等待 (IW)：當一個元件必須向多個伺服器請求服務才能完成任務時發生。如果每個服務都需要大量的時間，效能將受到影響。為了解決這個問題，DICE-APR 報告導致 IW 的元件，並向開發人員提供元件複製或重新設計建議。
• 過度計算 (EC)：當一個處理器執行應用程式的所有工作或儲存應用程式的所有資料時發生。表現為過度的計算，會降低效能。為了解決這個問題，DICE-APR 報告導致 EC 的處理器，並向開發人員提供新增新處理器以遷移任務的建議。

因此，DICE-APR 使用 LINE 求解器分析基於 Storm 的應用程式的效能模型，如果檢測到上述效能反模式 (AP)，則提供重構建議。

結論

DICE 增強工具的主要成果如下

DICE FG 提供統計估計算法來推斷應用程式的資源消耗，並提供擬合算法將監控資料與引數統計分佈相匹配，並使用上述演算法來引數化用 DICE 配置檔案註釋的 UML 模型。

DICE APR 有助於將用 DICE 配置檔案註釋的 UML 模型轉換為 LQN 模型，定義和指定兩個 AP 以及 DIA 的相應 AP 邊界，從模型中檢測上述 AP，並提供重構建議來指導開發人員更新架構。