共用方式為


使用 Azure Load Testing 和 Azure Chaos Studio 進行持續驗證

隨著雲端原生應用程式和服務變得更複雜,部署變更和新版本可能具有挑戰性。 中斷通常是因為部署或發行錯誤所造成。 但是 ,當應用程式開始接收實際流量時,也會在部署之後發生錯誤,特別是在在高度分散式多租用戶雲端環境中執行的複雜工作負載中,以及由多個開發小組維護的錯誤。 這些環境需要更多復原量值,例如重試邏輯和自動調整,這通常很難在開發程式期間進行測試。

這就是為什麼 在與生產環境類似的環境中持續驗證很重要的原因,因此您可以在開發週期中儘早找到並修正任何問題或錯誤。 工作負載小組應該在開發程式初期進行測試(左移),並方便開發人員在接近生產環境的環境中進行測試。

任務關鍵性工作負載具有高可用性需求,目標分別為 3、4 或 59 個(99.9%、99.99%或 99.999%) 。 請務必實作 嚴格的自動化測試 ,以達到這些目標。

持續驗證取決於每個工作負載和架構特性。 本文提供將 Azure 負載測試和 Azure Chaos Studio 準備和整合至一般開發週期的指南。

1 – 根據預期的閾值定義測試

持續測試是需要適當準備的複雜程式。 將測試的專案和預期的結果必須清楚。

PE:06 - 建議 用於效能測試和RE:08 - 建議 設計可靠性測試策略時,Azure Well-Architected Framework 建議您從識別關鍵案例、相依性、預期使用方式、可用性、效能和延展性目標開始

然後,您應該定義一組 可測量的臨界值 ,以量化關鍵案例的預期效能。

提示

臨界值的範例包括預期的使用者登入數目、指定 API 的要求每秒要求數,以及背景進程的每秒作業。

您應該使用臨界值來開發 應用程式的健全狀況模型,以便測試和在生產環境中操作應用程式。

Visualization of key system flows using green and red connected circles.

接下來,使用 值來定義 負載測試 ,以產生實際流量以測試應用程式基準效能、驗證預期的縮放作業等等。 在生產階段前環境中需要持續人工使用者流量,因為如果沒有使用方式,就很難顯示運行時間問題。

負載測試可確保對應用程式或基礎結構所做的變更不會造成問題,而且系統仍符合預期的效能和測試準則。 不符合測試準則的失敗測試回合表示您需要調整基準,或發生非預期的錯誤。

Load test run results screen showing failed load test run.

雖然自動化測試代表日常使用量, 但您應該定期 執行手動負載測試,以確認系統如何回應非預期的尖峰。

持續驗證的第二部分是 插入失敗 (混亂工程)。 此步驟會測試系統回應錯誤的方式,以驗證系統的復原能力。 此外,所有復原量值,例如重試邏輯、自動調整等,都會如預期般運作。

2 - 使用負載測試和 Chaos Studio 實作驗證

Microsoft Azure 提供這些受控服務來實作負載測試和混亂工程:

  • Azure 負載測試 會在應用程式和服務上產生綜合用戶負載。
  • Azure Chaos Studio 藉由有系統地將失敗插入應用程式元件和基礎結構,提供執行混亂實驗的能力。

您可以透過 Azure 入口網站 來部署和設定 Chaos Studio 和負載測試,但在持續驗證的內容中,您必須有 API 以程式設計及自動化的方式部署、設定及執行測試。 一起使用這兩個工具可讓您觀察系統對問題的反應,以及其自我癒合以響應基礎結構或應用程式失敗的能力。

下列影片顯示 整合在 Azure DevOps 中的 Chaos 和 Load Testing 實作:

如果您正在開發任務關鍵性工作負載,請利用參考架構、詳細指引、範例實作和程式代碼成品,作為 Azure 任務關鍵專案Azure 妥善架構架構的一部分。

任務關鍵實作會透過 Terraform 部署負載測試服務,並包含 PowerShell Core 包裝函式腳本 集合,以透過其 API 與服務互動。 這些腳本可以直接內嵌到部署管線中。

參考實作的其中一個選項是直接從端對端管線內執行負載測試,以用來啟動個別(分支特定)開發環境:

Run pipeline screen with the load testing checkbox ticked.

管線會自動執行負載測試,且不需混雜實驗(視選取專案而定) 平行執行:

Azure DevOps pipeline run with chaos and load testing.

注意

在負載測試期間執行混亂實驗可能會導致延遲較高、回應時間較高,並暫時增加錯誤率。 相較於沒有混亂實驗的執行,您將注意到較高的數位,直到向外延展作業完成或故障轉移完成為止。

Chart showing increased response time during chaos experiment.

視是否啟用混亂測試及選擇實驗而定,基準定義可能會有所不同,因為錯誤承受度在「正常」狀態和「混亂」狀態可能會有所不同。

3 – 調整閾值並建立基準

最後, 調整定期執行的負載測試臨界值 ,以確認應用程式 (仍然) 提供預期的效能,而且不會產生任何錯誤。 有個別的混亂測試基準,可容許預期的錯誤率尖峰和暫時降低的效能。 此活動是連續的,而且必須定期重複。 例如,在引進新功能之後,變更服務 SKU 和其他專案。

Azure 負載測試服務提供稱為 測試準則 的內建功能,可讓您指定測試需要通過的特定準則。 這項功能可用來實作不同的基準。

Test criteria screen with response time and error criteria marked as Failed.

此功能可透過 Azure 入口網站,以及透過負載測試 API 取得,以及作為 Azure 任務關鍵性一部分所開發的包裝函式腳本,提供交接 JSON 型基準定義的選項。

強烈建議將這些測試直接整合到 CI/CD 管線中,並在功能開發初期執行。 如需範例,請參閱 Azure 任務關鍵性參考實作中的範例 實作。

總而言之,在任何複雜的分散式系統中,失敗是不可避免的,因此解決方案必須經過架構(並經過測試)來處理失敗。 架構完善的架構任務關鍵性工作負載指引和參考實作可協助您設計和操作高度可靠的應用程式,以從 Microsoft 雲端衍生最大值。

後續步驟

檢閱任務關鍵性工作負載的部署和測試設計區域。