digiRunner壓測大師之路 - 三部曲GKE測試經驗分享
前言
二部曲我們介紹本機環境在壓力測試的環境設定，你看完之後，是否想過那雲端呢？沒錯！本篇就要跟大家分享雲端環境上進行壓力測試，並觀察服務的負載情況與狀況排查。如果你是第一次看到這個系列的文章，可以先滑到底查看前兩篇內容。小提醒一下，本篇會聚焦在GKE環境進行壓測的過程，故環境安裝與digiRunner(以下簡稱dgR)的設定也就不在本篇贅述囉。
測試環境架構
首先，本次分享GKE環境壓力測試的環境部署架構如下圖所示，該架構為模擬某個實際專案的需要進行配置。依照專案需要、預算或業務情境，環境架構會有不同的配置方式，後續呈現出的tps表現也會有所不同。再者，壓力測試當下也許還會有其他的變數比如說網路服務是否順暢也是影響因素之一。
壓測前準備
在了解環境架構後，我們來找一下壓力測試指令要執行的環境。在導覽列或搜尋欄輸入關鍵字找到VM執行個體，列表中會顯示部署同事建立的環境。
找到對應的VM名稱點選右方的SSH連線進入站台，並輸入sudo su 以管理員身份執行指令，接著就可以將要執行的指令貼上去。(補充：部署同事環境建立好也需提供給你可以進入該站台的帳號密碼)
再來，這次我們壓力測試的對象是企業版digiRunner，先確認目前是否正常運作中。使用探針的api可以快速確認目前運作狀況與系統資訊。的在瀏覽器網址列輸入https://{your digirunner domain:port}/liveness，如果正常運行中那麼我會看到顯示如下
liveness
以及目前digiRunner的一些系統資訊，在瀏覽器網址列輸入https://{your digirunner domain:port}/readiness，再勾選美化排版即可以檢視目前的系統資訊。
readiness
壓測指令執行環境確認OK，digiRuner環境也確認OK，接著說明本次的壓測情境與條件：
1.以30支隻API總共tps1000進行五小時的壓力測試，api有3支為回應時間較長。
2.digiRunner開啟ES_log寫入(Setting的選項ES_LOG_DISABLE設定值為false)。
壓測進行中
開始執行壓測指令時，除了dgR裡面的dashboard、監控管理或Online Console可以進行監控；GoogleCloud上我們可以在導覽列或搜尋欄輸入關鍵字找到Kubernetes Engine。
在導覽列點選工作負載 > 選擇dgR對應的節點 > 點選觀測能力。在這個區塊我們可以監控壓測執行期間的tps(rps)、錯誤率與對物類型、CPU與記憶體的使用率。
壓測結果檢視
在連續5小時以每秒1000個請求的條件下進行壓測tps的表現為992.57/每秒而測試過程期間的請求皆成功無失敗，在digiRunner儀表板的資源監控看到資源使用釋放穩定。
壓測狀況查詢
看到這邊會想到整個系統表現得穩定輸出的效能也不錯，壓測執行的很順利很棒，準備可以回報成果，本次的測試就結束啦！但是但是，現實在進行過程總是會遇到些大大小小的問題，這個時候是否有工具協助我們呢？沒錯，在GoogleCloud上我們可以在導覽列或搜尋欄輸入關鍵字找到Log Explorer，筆者進行壓測時的習慣是螢幕開兩個瀏覽器頁籤：一個顯示dgR的負載狀況，另一個則是Log Explorer，查詢問題可以一起看。
在Log Explorer的功能中，可以依照關鍵字、時間區間或是下拉清單調整查詢條件，查詢結果可以再展開詳細內容，依照紀錄的資訊可以協助我們判斷錯誤發生的當下或是前後來釐清問題發生的原因，繼續提供給研發團隊參考或是讓對應的部署同事進行下一步動作。
結語
看完本篇的經驗分享，相信大家對於 GKE 環境的壓力測試流程已有基本了解。測試流程與本機環境大同小異，差別在於環境建置的位置與監控方式。雲端平台提供的觀測能力與 log 記錄功能，讓你也可以隨時掌握壓測狀況。當然，雲端雖然方便，但也伴隨建置知識與流量費用的門檻，因此選擇哪種環境沒有絕對好壞，依實際需求彈性選擇就好啦。當然如果你對於雲端環境建置不是那麼了解，串流媒體或是生成式AI工具會是你的好幫手！
本篇就分享到這裡啦！下一篇是本系列的最後一篇，我們將主題轉回本機環境，在壓測過程中使用效能剖析工具觀察服務行為，找出潛在瓶頸讓研發團隊進行優化，敬請期待！
系列文章
參考資料
