大資料/質量測試的實用DevOps

簡介

資料密集型應用程式的質量測試 (QT) 旨在驗證 DIA 原型是否能夠提供終端使用者期望的擴充套件性、效率和穩健性水平。Apache Storm、Spark、Hadoop、Cassandra 和 MongoDB 等常見的大資料技術彼此之間相當不同，因此必須認識到 QT 需要使用多種工具來測試複雜的 DIA。

例如，Cassandra 和 MongoDB 資料庫最近得到了 Apache JMeter 的支援，Apache JMeter 是開源領域最先進的負載生成工具。MongoDB 受到原生支援，而 Cassandra 則透過外部外掛支援。Apache Hadoop 和 HBase 也得到了部分支援，現在可以在 JMeter 中使用。這意味著與這些技術的負載注入相關的研究挑戰是有限的，因為 JMeter 作為壓力測試的主要開源解決方案已經存在。基於以上，我們在本章中主要討論流式 DIA 範圍內的 QT，這在開源社群中受到的關注有限。

動機

設計質量測試工具面臨著一些挑戰。在這方面，對於 DIA 還沒有正式的方法論，我們認為一些關鍵挑戰可以概括如下。

• 負載注入執行器設計。在傳統的負載注入中，工作負載提交依賴於客戶端-伺服器模型，其中外部工作執行緒將作業提交到應用程式。然而，這種模型對於 Storm 等平臺並不自然，在 Storm 等平臺中，訊息注入由專門的軟體元件（稱為 spout）完成，這些元件是應用程式本身的一部分，並且注入打包為訊息的特定工作單元，這些訊息流經系統。在這種系統中，負載注入執行器不應作為外部元素實現，而應作為應用程式的內部元素實現。因此，開發用於資料庫的 QT 工具與開發用於流式平臺的類似工具之間存在概念上的差異。例如，作為應用程式本身的內部元件，工作負載生成器在流式應用程式中的資源使用情況將累積到應用程式本身的資源消耗。這對於資料庫系統可能不可接受，但對於流式應用程式來說是必需的，在流式應用程式中，訊息的注入會消耗一個單獨的資源池。雖然也可以考慮外部實現，例如透過提供與 Twitter 用於將資料推送到外部方所用的服務等效的服務，但內部實現的一個顯著優勢是，負載注入執行器可以直接訪問 DIA 內使用的資料結構，包括開發人員定義的自定義訊息結構。這使得終端使用者可以使用 DIA 本身開發的相同 Java 類來更輕鬆地定義傳送到系統的流式工作負載，並自動執行實驗。但是，這種方法的一個重要含義是，負載注入需要提供為一個嵌入式庫，該庫可以連結到應用程式程式碼中，開發人員透過 IDE 定義測試工作負載。

• 可擴充套件性測試。任何負載注入工具的要求都是能夠測試系統擴充套件的能力，即在工作負載並行級別提高時（例如，更多使用者、更高的資料速度、更大的資料量等）提供效能和可擴充套件性方面的服務質量 (QoS)。因此，預計對 QT 工具的良好實現將能夠根據終端使用者的要求生成額外的負載，直到觀察到一個或多個資源的飽和。QT 可以做到這一點。

• 流式工作負載生成。基於流式的 DIA 通常側重於分析傳入訊息以查詢特定主題，並在滿足訊息有效負載上的預定義條件時觸發某些操作。因此，一個研究挑戰是提供足夠的工具支援，讓使用者可以輕鬆地生成時變工作負載和時變訊息內容。理想情況下，這些工作負載應該儘可能接近開發人員公司在生產環境中看到真實的工 作負載。例如，在 Twitter 流式資料的情況下，人們希望生成類似於普通 Twitter 提要的工作負載，但這些工作負載在單個訊息型別的到達速率方面是可控的（例如，原始推文的到達速率與轉發推文的到達速率，或者來自特定使用者的到達速率），以及觸發 DIA 特定操作的訊息出現的頻率。我們在整個 QT 研究活動部分系統地研究了這個問題，並且開發了一種專門的數學理論來解決這個問題。

現有解決方案

有各種各樣的負載測試工具可用於分散式系統，包括商業工具（例如，IBM Rational、HP LoadRunner、Quali、Parasoft 等）和開源工具（例如，Grinder、JMeter、Selenium 等）。但是，所有這些工具主要都是為傳統的 Web 應用程式開發的，在傳統的 Web 應用程式中，傳入的負載是 Web 流量，使用者與應用程式前端（網站）互動。在 DIA 的情況下，傳入資料（例如資料庫、流）是主要的工作負載驅動因素。雖然資料庫測試相當普遍，但用於將資料流注入 DIA 的開源解決方案卻很缺乏。在介紹 DICE 解決方案來解決這個問題之前，我們將更詳細地討論現有的負載測試工具。

• Grinder。這是一個用於對 Java 應用程式進行分散式測試的框架。除了測試 HTTP 埠外，它還可以測試 Web 服務（SOAP/REST），以及透過 JMS、JDBC、SMTP、FTP 和 RMI 等協議公開的服務。該工具執行用 Java、Jython 或 Clojure 編寫的測試指令碼。測試可以是動態的，這意味著指令碼可以根據上一個操作的結果來決定要執行的下一個操作。該工具已經成熟，首次釋出是在 2003 年。它非常流行，每週下載量約為 400 次。Grinder 的一個侷限性是缺乏組織良好的志願者社群來支援該工具。

• Apache JMeter。這是一個分散式負載測試工具，在負載注入功能方面提供了與 Grinder 類似的功能。如果與 Markov4JMeter 結合使用，該工具還可以具有機率行為。有趣的是，該工具還具有對 MongoDB（一個 NoSQL 資料庫）的原生支援。該工具在可擴充套件性方面表現出色，這是透過外掛實現的。JMeter 的一個侷限性是，在 Javascript/AJAX 在效能方面起主要作用的網站上，Web 導航可能不具有代表性，因為 JMeter 不具備像複雜瀏覽器那樣的 Javascript 功能範圍。JMeter 得到了龐大的 Apache 基金會社群的支援。

• Selenium。這是一個流行的庫，它可以自動控制 Web 瀏覽器，例如 Internet Explorer 或 Firefox。它允許使用本機 Java API 執行測試。此外，可以透過向瀏覽器新增 Selenium 外掛並手動執行操作來記錄測試指令碼。一個擴充套件（以前稱為 SeleniumGrid，現在已整合到主 Selenium 工具的穩定分支中）允許執行分散式負載測試。

• Chaos Monkey。這是一項在 Amazon Web Services 上執行的開源服務。該工具用於在自動擴充套件組中建立故障，並幫助識別雲應用程式中的故障。設計靈活，可以擴充套件到與其他雲提供商合作並提供其他功能。該服務有一個完全可配置的時間表，用於執行操作的時間，預設情況下，該服務在非假日工作日上午 9 點到下午 3 點之間執行。在 .NET 中為 Microsoft Azure 開發了一個類似的工具，稱為 WazMonkey，它提供了與 Chaos Monkey 類似的功能，例如在給定的 Azure 部署中隨機重新啟動或重新映像角色例項。

工具的工作原理

DICE QT 工具是兩個獨立模組的組合

• QT-LIB：一個用於在基於 Storm 和基於 Kafka 的應用程式中定義負載注入實驗的 Java 庫。
• QT-GEN：一個用於生成工作負載跟蹤的工具，這些跟蹤可以使用 QT-LIB 注入到系統中。

QT-LIB 以 jar 檔案的形式提供，可以打包在任何基於 Java 的 Storm 拓撲中，提供用於負載注入和工作負載調節的自定義 spout。該工具可以透過 MongoDB 獲取要推送到 DIA 的外部資料（對於可以作為 JSON 檔案匯出的大型資料集），也可以透過外部文字檔案獲取。JSON 檔案使用與 MongoDB 相容的語法。下面，我們將更詳細地介紹各個模組。

QT-LIB

QT-LIB 模組提供了一組自定義的 spout，用於自動化在 DIA 中注入工作負載。這些 spout 的工作原理很簡單：一旦 DIA 部署，這些 spout 就會根據使用者指定的工作負載自動生成元組。負載生成介面可供終端使用者指定輸入資料來源（例如，CSV、MongoDB）；該介面為 spout 提供輸入元組以將負載注入系統，並且可以輕鬆地適應其他資料庫或其他文字或二進位制輸入源。即使 QT-LIB 成為被測拓撲的一部分（作為程式碼和邏輯架構），被測系統也是處理資料的 Bolts 集合。因此，Bolts 及其之間的關係嵌入在 DIA 程式碼中。

QT-GEN

我們討論 QT 最先進的功能，即從給定的 Storm 訊息跟蹤中自動生成人工工作負載的能力。其想法是在給定的工作負載跟蹤中區分一組訊息型別，並生成一個新的跟蹤，該跟蹤具有與初始跟蹤類似的特徵，但與初始跟蹤不同，並且具有任意使用者指定的到達率。QT 假設有一個 JSON 檔案可用，其中每個條目代表要序列化為元組的訊息。

QT-GEN 工具接受輸入一個 JSON 檔案，該檔案包含任意長的此類訊息序列，對其進行解析以提取問題時間戳序列，然後生成一個新的訊息序列，其中訊息以交替方式排列，以保留與原始跟蹤中定義的使用者型別之間類似的相關性，然後生成一個新的訊息序列，其中訊息以交替方式排列，以保留與原始跟蹤中定義的使用者型別之間類似的相關性，如原始跟蹤中所見。作為一個簡單的例子，對於 Twitter 跟蹤，QT 工具可以生成一個新的跟蹤，其中包含

• 與原始跟蹤中相同的推文和轉發比例，後者由 Twitter JSON 資料結構中的特定欄位標識。
• 推文和轉發之間統計上類似的時間間隔，以便推文和轉發的數量以及其峰值的頻率和相關性也在人工工作負載中得到複製。

QT 工具可以使用稱為標記馬爾可夫到達過程的一類流量模型對這種相關性進行統計分析並儘可能地在人工工作負載中複製它，標記馬爾可夫到達過程是隱馬爾可夫模型的一種特殊類別。馬爾可夫到達過程（MAP）是一類隨機過程，用於對來自流量流的到達進行建模。標記 MAP（MMAP）是 MAP 的擴充套件，允許對多種型別的流量到達進行建模。QT-GEN 庫為 QT 工具提供了後端，旨在使用 MMAP 擬合標記跟蹤，並隨後生成代表性跟蹤。由於標記跟蹤的統計描述符與 MMAP 的引數之間通常存在複雜的非線性關係，因此後一個問題非同小可。

QT 方法

下圖說明了針對參考 Storm 基應用的質量測試總體方法。

使用 DICE 測試大資料應用程式的質量

主要方法步驟如下

1. 將應用程式（即拓撲）提交到雲測試平臺
2. 使用代表性工作負載進行測試，並收集初始日誌（例如，JSON 格式）
3. 將日誌提交到 QT-GEN 工作負載生成器
4. 生成新的工作負載，以使用自定義 QT-LIB spout 注入系統
5. 提交啟用 QT 的拓撲，並使用 QT-LIB spout
6. 執行自動測試
7. 在監控平臺（D-MON）或交付服務（Jenkins 儀表板）上視覺化結果

開放挑戰

本章概述的解決方案負責在流處理系統中注入負載，目的是自動暴露效能和可靠性異常。雖然可以對標記資料進行建模，但目前流處理系統中使用的負載測試解決方案無法以程式設計方式指定訊息有效載荷的資料內容。顯然，流處理系統的響應也將取決於資料本身的內容，因此可以預見，可以定義更高階的工具來擴充套件所提出的方法，以涵蓋內容、資料概念等。

本章沒有探討的另一個方面是質量測試工具鏈的可擴充套件性，這與設計為在數十或數百個節點上執行的資料密集型應用程式相關。這種配置要求質量測試過程本身是分散式的，以避免輸入流生成中的瓶頸。有針對雲負載測試的商業解決方案，但它們在 Big data 技術環境中的使用仍處於起步階段。

應用領域：已知用途

生成用於負載測試的人工 Twitter 跟蹤

讓我們考慮一個從 Twitter 流中獲取資料的流處理系統。當然，為了測試系統，我們需要一些 Twitter 資料。不幸的是，Twitter 和其他社交媒體平臺需要付費才能獲取和使用其資料集。雖然我們可以購買一些或回放一些玩具資料集，但最好有一個免費的工具來生成類似於真實資料集的人工資料集。QT 提供了這種功能。

起點是考慮來自 Twitter 或類似平臺的訊息的 JSON 模板。例如，這可能類似於此 JSON 檔案

{ "className" : "gr.iti.mklab.framework.abstractions.socialmedia.items.TwitterItem",
"reference" : "Twitter#00000000000000000",
"source" : "Twitter" ,
"title" : "@YYY: 4 DAYS TO GO #WorldCups",
"tags" : [ "WorldCups"],
"uid" : "Twitter#000000000",
"mentions" : [ "Twitter#111111111" , "Twitter#22222222222"],
"referencedUserId" : "Twitter#138372303",
"pageUrl" : "https://twitter.com/CinemaMag/statuses/123456789123456789",
"links" : [ "http://fifa.to/xyxyxyxy"],
"publicationTime" : 1401310121000,
"insertionTime" : 0,
"mediaIds" : [ "Twitter#123456789123456789"],
"language" : "en",
"original" : false,
"likes" : 0,
"shares" : 0,
"comments" : 0,
"_id" : "Twitter#123456789123456789"}

特別要注意 JSON 檔案包含一個時間戳欄位，此處為“publicationTime”，以及幾個可用於對推文型別進行分類的欄位，例如“original”，它將推文分成兩類：推文和轉發。

在基於 Twitter 的真實 DIA 中，此類訊息在釋出後立即收到。我們的目標是從給定的 Twitter 跟蹤中生成一個新的 JSON 跟蹤，並具有以下屬性

• Twitter 跟蹤中的推文到達率與新跟蹤中的推文到達率相同
• 人工跟蹤和原始跟蹤具有類似的推文突發生成機率

QT-GEN 工具確保了這兩個屬性。給定跟蹤、時間戳欄位（例如，“publicationTime”）和分類欄位（例如，“original”），它輸出一個類似於原始 Twitter 跟蹤的新 JSON 跟蹤，但並不完全相同。

負載測試 Kafka 管道

我們現在將說明 QT-LIB 在 Kafka 中的實際應用。下面我們展示了一個緊湊的 示例，該示例包含在 QT-LIB 發行版中。最初，與 Storm 一樣，我們構造一個 QTLoadInjector 工廠，該工廠將組裝負載注入器。此外，我們指定輸入跟蹤檔案的名稱，該檔案假定已打包在資料密集型應用程式的 jar 檔案中。

package com.github.diceproject.qt.examples;

import com.github.diceproject.qt.QTLoadInjector;
import com.github.diceproject.qt.producer.RateProducer;

public class KafkaRateProducer {
	
	public static void main(String[] args) {
		QTLoadInjector QT = new QTLoadInjector();
		String input_file = "test.json"; // this is assumed to be a resource of the project jar file

我們現在準備為 Kafka 例項化一個 QT 負載注入器，稱為 RateProducer

		RateProducer RP;
		RP=QT.getRateProducer();
		String topic = "dice3"; // topic get created automatically
		String bootstrap_server = "localhost:9092";

這裡我們假設我們的目標主題稱為 *dice3*，並且它由本地計算機上的埠 *9092* 上的 Kafka 例項公開。這對應於所謂的 Kafka 引導伺服器的埠，不應與與 Kafka 關聯的 Zookeeper 例項的埠混淆。我們現在可以使用 run() 方法立即啟動負載測試實驗。

		RP.setMessageCount(101);
		RP.run(bootstrap_server, topic, input_file);

這些將讀取類似於 QT-GEN 建立的 JSON 訊息，這些訊息來自之前宣告的 *test.json* 檔案。該檔案必須與應用程式 JAR 一起釋出，以便 QT-GEN 可以將其開啟為本地資源。生成的示例生成了 101 條訊息來說明 QT-LIB 在跟蹤執行時超過時的行為，因為在這種情況下，跟蹤由 100 條訊息組成。QT-LIB 將從頭開始迴圈重啟跟蹤，將第一條 JSON 訊息重新發送為第 101 條訊息。

結論

DICE QT 的主要成就如下

• DICE QT 允許在基於 Storm 的應用程式中注入負載，使用自定義 spout，這些 spout 可以重現訊息的表格到達率，或者以受控方式將儲存在文字檔案或外部資料庫（即 MongoDB）中的訊息注入。
• DICE QT 可以分析由不同型別訊息組成的負載跟蹤，並將這些訊息的觀察到的到達間隔時間擬合到稱為 MMAP 的隱馬爾可夫模型的特殊類別中，從中可以生成新的統計上類似的跟蹤來評估不同負載情況下的系統。
• DICE QT 還可以將負載注入 Kafka 主題，因此支援各種各樣的目標，包括 Spark 應用程式。