View a markdown version of this page

實驗規劃文件 - AWS 方案指引
穩定狀態可觀測性要求實驗定義假設實驗程序實驗時間軸實驗結果已識別的瑕疵

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

實驗規劃文件

穩定狀態

程序名稱 寵物採用網站

實體架構

（連結至架構圖）。

邏輯架構

（邏輯圖的連結。)

定義穩定狀態

對於寵物採用網站，使用最大有內容繪圖 (LCP) 測量的平均頁面載入時間為 2.5 秒或更短，99 個百分位數延遲 (P99) 為 4.0 秒或更短，基準為 5000 個並行使用者。

穩定狀態指標

跨使用者基礎擷取的 LCP 指標，以及黃金指標 （延遲、輸送量、錯誤率、飽和度）。

穩定狀態可觀測性

LCP 將由使用者的瀏覽器擷取、傳送至 Amazon CloudWatch，並使用 CloudWatch RUM 進行檢查。在 60 秒期間內，將會彙總該期間內所有請求的平均和 P99 LCP 時間。最上層黃金指標是使用 CloudWatch 擷取。

達到穩定狀態的程序

Grafana K6 將用於建立負載，模擬大約 5K 個並行使用者的正常生產流量層級。

可觀測性要求

團隊應該能夠檢視下列項目：

  • 穩定狀態：將觀察哪些內容來驗證應用程式是否處於正常狀態？

  • 失敗條件：失敗條件將如何顯示在儀表板中？ 例如：

    • 應觸發的警示

    • 應該產生的日誌

  • 失敗影響：應觀察哪些項目來檢視預期會受到影響的元件 （影響範圍）？

  • 復原：如何檢視和測量復原以擷取 MTTR？

  • 偵錯：針對實驗失敗的詳細資訊進行故障診斷。

下表提供可觀測性需求圖表的建議和範例。您應該根據您的特定實驗來定義應該觀察的內容。

需要觀察的項目 連結至可觀測性工具 正在觀察到的內容

輸入來源

Grafana K6 儀表板

  • 執行容器計數

  • 每秒請求數

整體應用程式運作狀態

  • 寵物採用 CloudWatch 儀表板

  • 寵物採用使用者體驗儀表板 (RUM)

  • Amazon EKS 運作狀態良好的節點計數

  • Amazon EKS 節點 CPU 使用率

工作流程運作狀態

寵物採用 CloudWatch 儀表板

LCP 時間，黃金指標

追蹤

寵物採用 X-Ray 儀表板

  • 請求延遲

  • 請求計數

  • 失敗計數

日誌

寵物採用 CloudWatch Logs

Pod 遇到的任何錯誤都會發佈至 CloudWatch Logs。

實驗定義

實驗名稱 Amazon EKS PetSite Pod CPU 壓力

實驗原始程式碼

（實驗來源儲存庫的連結。)

實驗描述

此實驗探索 PetSite 應用程式 Pod 的 CPU 使用量增加將如何影響整體客戶體驗。透過將 CPU 壓力注入每個執行中的 PetSite Pod，我們將能夠了解是否對客戶造成影響，以及影響的程度。

實驗需求或參數

應用程式負載：生產平均值

Pod 標籤選擇器： app=petsite

實驗持續時間

10 分鐘

環境

Alpha 測試環境

實驗目標資源

PetSite 應用程式 Pod

透過負載產生工具引入的實驗基準

  • 54% 的請求具有 <2.5 秒的 LCP。

  • 46% 的請求具有 <4 秒的 LCP。

  • 未觀察到錯誤。

退避條件

無

假設

如果 影響 復原

如果在正常生產層級流量下，PetSite 應用程式裝置遇到或導致 CPU 使用率超過 60% 達 10 分鐘，穩定狀態會發生什麼情況？

 

對於 P99 為 4.0 秒或更短的 P50 使用者，LCP 時間將維持在 2.5 秒以下。 P99 消費者應該能夠載入 PetSite 登陸頁面。

偵測：

  • 在 CloudWatch 中設定的警示會偵測到 CPU 壓力。

  • LCP 指標也會針對使用者體驗的降級產生警示。

自我修復：

  • 微服務架構的分散式性質表示許多 Pod 執行個體正在多個可用區域上執行。 

  • EKS 叢集控制平面會將流量移離受影響的 Pod，並在工作者節點上啟動新的 Pod。

復原： 

當 CPU 使用率恢復正常時，LCP 應會自動復原。

實驗程序

為您的特定實驗量身打造下列step-by-step程序：

  1. 驗證所有 Amazon CloudWatch、CloudWatch RUM 和 AWS X-Ray 儀表板的存取權和功能。

  2. 驗證應用程式環境的運作狀態：

    1. 使用 CloudWatch 儀表板確認 EKS 叢集運作狀態良好。

    2. 請造訪範例 URL 的測試寵物採用網站應用程式部署。

  3. 啟動負載以達到穩定狀態：

    1. 確認負載產生器正在執行，每秒傳送 5000 個請求。

    2. 等待 5 分鐘，讓應用程式達到穩定狀態。

    3. 使用 CloudWatch RUM 儀表板確認應用程式的穩定狀態。

  4. 啟動錯誤 （實驗）：

    1. 開啟 AWS FIS 主控台。

    2. 執行 pet-adoption-pod-stress 實驗。

    3. 確認實驗正在 主控台中執行。

  5. 觀察故障對應用程式的影響：

    1. 從 CloudWatch RUM 和 CloudWatch 儀表板擷取螢幕擷取畫面，並記下任何異常的資料點。

    2. 實驗完成後 AWS FIS，請擷取其他螢幕擷取畫面，以記錄應用程式是否在沒有壓力的情況下返回穩定狀態，並記下資料點中的任何異常。

    3. 如果穩定狀態未繼續，請採取步驟來復原應用程式，並記錄採取的步驟。

  6. 驗證環境已恢復正常：

    • 檢閱所有業務、使用者體驗、應用程式和基礎設施指標，以確認系統已返回已知狀態。如果有幫助，請擷取儀表板螢幕擷取畫面。

實驗時間軸

請確定您擷取end-to-end實驗的時間軸，從負載產生開始、注入錯誤、觀察影響和應用程式復原，以及在停止負載產生時結束。這會在下列範例中說明。

混沌實驗的時間軸範例。

實驗結果

實驗執行 ID 實驗結果

PET-ADOPT-EXP-23

（實驗結果的連結。)

已識別的瑕疵

  • Kubernetes 叢集未偵測到 PetSite Pod 的 CPU 受損，因此未排程其他部署。

  • 此實驗不會增加 4XX 或 5XX 錯誤率。

  • 我們需要調整 Pod 的運作狀態檢查，以便在有資源限制時考慮對 LCP 的影響。