雷亞遊戲技術長鐘志遠表示,Kubernetes已經先行將硬體資源抽象化,進行封裝。因此,資料庫此類相當依賴硬體的服務,現階段該技術的支援仍然不足。(攝影/洪政偉)

從去年開始,雷亞遊戲(簡稱雷亞)就已經開始利用容器作為基礎架構,在Google雲端平臺GCP上,使用容器引擎GKE來建置Kubernetes叢集,作為旗下遊戲的後端系端環境之用,例如目前已經推出的音樂遊戲Voez,正在開發中的卡牌遊戲伊甸之魂,或是新款角色扮演遊戲Sdorica未來的上線正式環境,也都會部署在Kubernetes叢集上執行。

雷亞遊戲技術長鐘志遠表示,每一款遊戲都需要部署4套獨立的容器叢集,用於開發環境、Alpha環境、Beta環境以及正式環境等不同階段的執行需求,再加上這些遊戲系統採用了微服務架構的設計,一款遊戲包含了3至4個微服務所組成,因此光是一款遊戲的運作,都需要布建至少10套容器叢集,「雷亞目前已經在GCP平臺上運作了近50個Kubernetes叢集。」

複雜度是微服務必定面對的挑戰

鐘志遠舉例,以基本網路服務為主的公司,可能只需要研發一兩款產品,長期提供穩定服務至終端消費者,但是遊戲公司的挑戰在於,每1至2年就得釋出一款全新遊戲。甚至,他說,日後遊戲的使用人數增加後,帶來的挑戰就是必須要管理更多的微服務。而叢集數量越多,對微服務架構而言,管理者面臨的系統複雜度挑戰也更大。

「一款遊戲需要許多不同的API叢集、微服務才能運作,而它們都必須要具備水平擴充能力」,鐘志遠舉例,像是雷亞部署在GCP平臺的遊戲底層叢集,除了前端使用原廠負載平衡服務,還會部署Nginx元件處理終端系統發送的需求。

除了執行遊戲邏輯運算的服務,雷亞也設計了一套玩家行為校驗系統,檢測是否有可疑的作弊行為。「而Kubernetes最大的好處就是,封閉叢集內的環境互不影響」,他表示,在GCP上透過Kubernetes,就可以調度叢集內使用容器打包的微服務。

除此之外,雷亞也常碰上自家系統或遊戲API改版衍生的相容性問題。鐘志遠舉例,例如角色扮演遊戲Sdorica的開發過程,經歷過兩次API改版,開發團隊得要在新版系統上架前,先使用舊版API,等待新版應用程式上架之後,再切換成新版API,覆蓋掉舊版API,「挑戰在於,在短時間內部署新版本的API叢集。」

讓Kubernetes與既有CI流程整合

所幸,雷亞內部有一套用來支援新遊戲開發需求的數位資產管理服務,可以針對不同的開發專案,分別部署獨立的Instance,「這個資產管理服務,也整合了CI流程,直接與Kubernetes連接」,鐘志遠解釋,過去雷亞已經花費許多心力整合CI工作流程,加速自動化流程。因此,如果開發者想要增加新的Kubernetes叢集,只需稍微修改自動化腳本程式,就可以靠CI流程自動化部署一套容器叢集,來執行新版API,解決新舊版API的相容性問題。

目前雷亞遊戲的後端系統CI流程是靠GitLab搞定,主要用於部署程式碼。不過鐘志遠表示,遊戲除了後端系統外,與玩家進行互動的前端系統,「還包含大量圖檔、影音這類的數位美術資產」,而GitLab並非處理此類檔案的最佳工具。相比之下,Jenkins讓使用者隨需修改的自由度更高,「讓大量資料部署變得更有效率。」

整合GCP平臺工具Stackdriver監控Kubernetes

不過經營一家遊戲公司,面臨的挑戰不單只有遊戲的開發,還要確保應用程式上線之後也能維持一定營運品質。雷亞也直接使用GCP提供的Log監控服務Stackdriver,來監控Kubernetes叢集的執行狀況。鐘志遠解釋,維運人員所要注意的不單只有容器節點、Pod的運作狀況,「更主要的是監控應用程式,根據使用者行為,回過頭判定系統服務是否正常運作。」

例如,當系統運作正常時,都可以對使用者請求做出回應。但是,每當系統開始出現HTTP Error 500、HTTP Error 404的訊息,即代表玩家無法正常存取服務;或是有不肖玩家反覆鍵入密碼,試圖盜用他人帳號時,監控系統都會蒐集相關Log資訊。

鐘志遠表示,目前雷亞已經將Kubernetes叢集的Log紀錄與Stackdriver進行介接,「當異常事件超過一定程度,系統就會透過Slack,發送通知給維運人員」,而Stackdriver與Docker的整合程度也相當不錯,容器執行的行為,亦可透過Stackdriver進行監控。不僅如此,Stackdriver還可以將監控資料,匯入至GCP平臺的數據分析倉儲Big Query做後續分析,「在GCP上可以建構整套的工作流程。」

一鍵升級風險高,仍自行實測新版Kubernetes後再升級

但是,Kubernetes的使用者都得面臨官方一年推出3至4個新版的升級壓力,雖然GCP平臺有提供一鍵升級Kubernetes的服務,不過,目前有兩個問題,第一是無法確定一鍵升級作業所需花費的更新時間。其次是無法保證,使用一鍵更新後,會不會造成雷亞系統當機,「官方所提供的說明並不明確。」再加上現階段Google還未提供一鍵更新的SLA保證,一旦發生故障,也不會提供理賠。一鍵更新的高度不可預測性,「雷亞的營運模式不適合這樣的機制。」所以,他們還是得自行解決一年多次的Kubernetes升版議題。

「在正式上線前,我們得先在新版Kubernetes叢集內進行測試。」鐘志遠表示,現在雷亞遊戲採取的Kubernetes升級策略,會先額外部署一組運作最新版本的Kubernetes叢集,所幸,「只需要大約10分鐘就可建置新叢集」,接著將遊戲部署於該叢集進行封閉測試,當確定運作正常時,再將使用者導向新叢集,同時關閉執行舊版本的Kubernetes叢集。

資料庫應用支援還有待加強

雷亞導入Kubernetes一年來,「大多可用Kubernetes執行的應用程式都已上線」,雷亞也透過這些導入經驗,來精進Kubernetes的操作熟悉度。

不過,鐘志遠表示,目前GCP上的GKE服務,仍有兩大不足,一個是Kubernetes對資料庫支援程度不足,另一個是GKE無法在單一容器叢集中支援多種異質的硬體規格。這是雷亞還無法將所有系統都放到GKE上執行的原因。

在資料庫支援度上,鐘志遠解釋:「資料庫應用得自行修改許多底層(作業系統層)的參數」,例如需要調整OS存取記憶體的時間來優化資料庫效能等,但是Kubernetes已經先行將硬體資源抽象化,進行封裝,「所有應用程式都得靠容器執行,因此資料庫管理人員不能直接修改底層設定。」所以,雷亞並未將任何資料庫部署到Kubernetes環境上執行,

他解釋,當企業要將容器技術導入正式環境時,遇到特別講究效能表現的系統服務,往往需要進行精密的調校,但是,「目前容器技術對這類高度依賴硬體的服務,支援度還不足。」。

雷亞遇到的第二個問題是,GKE服務的不足,無法在單一Kubernetes叢集內,搭配多種硬體規格不同的運算節點。鐘志遠舉例,像是資料庫服務必須搭配大量記憶體和高I/O的運算節點,而同一個遊戲的叢集中,也會有另一個處理玩家需求的系統服務,這就需要使用CPU效能高的運算節點,「但在GKE建立Kubernetes叢集時,只能使用同樣規格的節點」,導致不容易在單一叢集內,支援異質性運作需求(高CPU或高I/O)的多種服務。因應此狀況,目前雷亞的解決方法,也只能額外加開使用特殊硬體規格的叢集,再將同性質的服務集中到單一Kubernetes叢集上執行。

熱門新聞

Advertisement