View a markdown version of this page

GAMEOPS05-BP01 選擇正確的階段、架構和負載測試架構以符合您的目標 - 遊戲產業鏡頭
實作指引

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

GAMEOPS05-BP01 選擇正確的階段、架構和負載測試架構以符合您的目標

載入測試遊戲的方法可能會因許多因素而有很大差異，包括其執行的開發程序 階段、負載產生系統本身的 架構，以及負載測試架構 的選擇。執行時機，無論是在早期階段、反覆衝刺期間、生產部署之前或部署後，都會塑造測試工作的目標和重點。不同的負載產生基礎設施設計有自己的優缺點，而負載測試架構的選擇會大幅影響測試程序可用的功能、易用性和整合。透過仔細調整這些元素， 開發團隊可以根據遊戲的獨特特性量身打造負載測試方法，擷取最有價值的效能洞察，並為玩家提供流暢的體驗。

未建立此最佳實務時的曝險等級：高

實作指引

不同開發階段的負載測試 

在開發階段的早期執行探索性負載測試，可以驗證基礎系統架構。這可協助開發人員在大量實作工作完成之前，做出有關遊戲基礎設施、資料庫設計和網路拓撲的明智決策。負載測試可識別風險並建立效能基準，從而可能最大限度地減少在開發生命週期稍後 需要昂貴的返工和技術負債。他們也可以促進團隊之間對遊戲效能需求的共同理解，從而實現更好的 協作和決策。 最終，初始階段的負載測試為高效能、可擴展性和彈性的遊戲奠定了堅實的基礎，有助於增強整體玩家體驗。

在每次衝刺或反覆運算結束時，負載測試可以評估新功能的效能影響、錯誤修正，以及最新週期中引入的其他變更。這種有針對性的方法可讓開發團隊快速識別最新更新引進的迴歸或效能降低，使其能夠在進一步向下傳播管道之前解決這些問題，並 維持一致的品質和效能水準。

在部署到生產環境之前，強大的負載測試可協助團隊 驗證系統處理預期實際流量和負載條件的能力。他們可以發現生產基礎設施中的可擴展性瓶頸或資源限制，並提供最佳化遊戲效能的機會，從第一天開始就建立順暢且回應靈敏的使用者體驗。從啟動前負載測試獲得的洞察可以緩解啟動日風險並通知持續的容量規劃，這為遊戲的長期永續性和可擴展性奠定了基礎。

負載測試已在生產環境中的遊戲，可讓團隊監控遊戲的效能，並識別一段時間內可能發生的效能迴歸或降級。這使他們能夠在問題影響玩家體驗之前主動解決問題，並對使用者保留率產生負面影響。此外，生產中的負載測試會驗證已實作的效能最佳化工作或基礎設施擴展的有效性。即使遊戲不斷發展和成熟，此程序也為玩家提供高品質、回應能力高且可擴展的遊戲體驗。

產生負載的架構

遊戲負載測試的負載產生架構設計可以採用各種形式，每個形式都有自己的一組優點和考量。 

在最基本的層級，可以佈建自我管理的 Amazon EC2 執行個體，並設定為充當負載產生器。 透過控制節點和工作者節點方法，您可以設定多個負載產生執行個體，每個執行個體都會執行自己的測試指令碼，並由單一控制執行個體整體管理。架構可以擴展並產生更多負載，而不會增加額外的工作者節點的複雜性，但這種實作方法需要團隊處理基礎基礎設施的 佈建、設定和管理。

對於更具可擴展性和協調性的方法，您可以使用 Amazon EKS Kubernetes 叢集來管理和分配容器型負載代理程式機群的負載測試工作負載。 Kubernetes 自動擴展功能可用於處理負載產生型 Pod 的擴展，而團隊本身則可在託管 Pod 的叢集中設定和管理基礎 EC2 執行個體。 

或者， 的無伺服器特性AWS Fargate可以透過抽象化基礎設施管理，同時仍提供必要的可擴展性和靈活性，來加速和簡化負載測試設定。對於現場部署、產生負載的 Kubernetes 叢集已存在，但可能需要額外容量的混合解決方案，EKS Anywhere 可以從 將兩個叢集管理為一個 AWS 管理主控台。

您也可以根據您的需求和目標使用 AWS Lambda 函數。Lambda 函數相對簡單，無需佈建和管理其他資源即可設定和擴展。由於與其他 AWS 服務的深度整合，它們也允許建立更複雜和動態的測試案例。不過，Lambda 函數對並行函數和執行時間 (15 分鐘） 有限制，這可能會限制可達到的負載測試規模和長度。冷啟動延遲也會影響結果的準確性，Lambda 的資源限制可能不適合高要求負載測試工作負載。

想要使用預先建置解決方案的 Studio 可以使用 上的分散式負載測試 AWS。此解決方案使用 上的 Amazon ECS AWS Fargate 來部署可以執行數萬個連線使用者的模擬的容器。您可以使用此功能，以 IAC 方式使用 快速啟動負載測試基礎設施 AWS CloudFormation。

負載測試架構

沒有兩個負載測試架構的建置方式相同。有些 具有直覺式圖形界面來建立測試，有些則完全以命令列為基礎。一個工具可能具有彈性和效能，但需要時間和精力來設定和管理，另一個工具可能沒有伺服器，但在可以建立和執行的測試中受到限制。一些人喜歡大型社群和大量的教學課程，同時在現場未經驗證，與在生產環境中可能經過戰鬥測試但缺乏社群支援或文件的社群形成強烈對比。選擇為您和團隊取得適當平衡的架構。一些熱門選項包括：

  • Apache JMeter：由於其強大的功能集和易用性，因此熱門的 Java 型開放原始碼負載測試架構。它能夠模擬複雜的使用者案例、各種支援的通訊協定、全面的報告和經過驗證的追蹤記錄，使得 JMeter 成為負載測試的可靠選擇。

  • Locust：在事件驅動型架構上建置的現代分散式負載測試架構，使其在具有資源效率的同時發揮效能。 測試是以 Python 撰寫，允許利用數千個強大的第三方程式庫的靈活測試案例，同時保持友好且易於閱讀。

  • Grafana K6：強大的負載測試架構，結合了易用性與進階功能。其支援分散式負載產生、彈性指令碼，以及與 Grafana 無縫整合以進行資料視覺化，讓 Grafana K6 成為吸引人的選擇。

  • 遊戲：開放原始碼負載測試架構以其效能和可擴展性著稱。其以 Scala 為基礎的網域特定語言 (DSL) 可讓開發人員建立簡潔、可維護的負載測試指令碼，其 強大的報告和分析功能可提供受測系統的詳細洞見。

實作步驟

  • 負載測試階段：在各種開發階段 （早期開發、衝刺、生產前和部署後） 執行負載測試，以驗證系統效能並識別問題。

  • 負載產生架構：根據可擴展性需求、管理偏好設定和特定測試需求，選擇適當的負載產生架構 (EC2、EKS、Fargate 或 Lambda)。

  • 負載測試架構：選取負載測試架構 （例如 JMeter、Locust、Grafana K6 或 Gatling)，在易用性、效能、彈性和社群支援之間取得平衡，以符合團隊的需求。