網(wǎng)易游戲海外AWS實踐分享

4 月 27 日，網(wǎng)易游戲?qū)W院受邀 AWS，作為主題演講分享的重磅嘉賓，參與了中國區(qū) AWS Game Tech Day- AWS 游戲開發(fā)者大會深圳站分享，網(wǎng)易游戲資深云解決方案工程師孫國良代表網(wǎng)易團隊帶來了《網(wǎng)易游戲海外 AWS 實踐分享》，技術(shù)內(nèi)容豐富，引起現(xiàn)場熱烈討論，與會人員收獲滿載。

孫國良，2013 年加入網(wǎng)易游戲，曾負責《天諭》《獵魂覺醒》《楚留香》等游戲項目運維工作，之后負責游戲出海對接公有云的運維架構(gòu)以及混合云管理平臺設(shè)計，專注于混合云上業(yè)務解決方案和最佳實踐的沉淀積累。

孫國良帶來的《網(wǎng)易游戲海外 AWS 實踐分享》，分享了網(wǎng)易游戲在《陰陽師》《荒野行動》《第五人格》《明日之后》等多款游戲出海運營過程中積累的實踐經(jīng)驗，這次分享以全球化的開放視野，與廣大游戲熱愛者共探云技術(shù)的實踐運用。

以下為分享實錄：

大家好，今天非常高興能夠 分享網(wǎng)易游戲海外在 AWS 云上的實踐情況，希望我分享的內(nèi)容能給大家提供一些線上最佳實踐優(yōu)化的思路，當然也非常歡迎大家對我分享的內(nèi)容提出建議幫助我們一起改進在云上的業(yè)務架構(gòu)。簡單自我介紹一下，我從 2013 年加入網(wǎng)易游戲，早期是做游戲運維的工作，是端游《天諭》、手游《楚留香》等游戲的運維負責人，后來我主要負責了網(wǎng)易游戲出海對接公有云的運維架構(gòu)，以及國內(nèi)外混合云解決方案方面的工作。

國內(nèi)發(fā)行 VS 海外發(fā)行

首先簡單介紹一下網(wǎng)易游戲出海的歷程，這里主要是指手游。 我們差不多是從 14 年底 15 年初開始做海外發(fā)行，比較典型的游戲有《陰陽師》《荒野行動》《終結(jié)者》《第五人格》等等， 今年我們也會有更多的游戲出海發(fā)行，比如最近發(fā)布的《明日之后》《量子特工》等，后續(xù)還會有更多的重磅游戲，敬請期待。

根據(jù)第三方統(tǒng)計，去年中國的游戲發(fā)行商在海外的收入排行榜中網(wǎng)易取得了第三的成績，并且中國出海手游收入榜單前 30 中我們有兩款游戲上榜——《荒野行動》和《終結(jié)者》。根據(jù) Sensor Tower 的統(tǒng)計，《荒野行動》2018 年在全球吸金 4.56 億美元，其中日本玩家貢獻了八成。當然我們也還有其它很多游戲在全球多個地區(qū)取得了不錯的成績。

我們回到剛開始出海的時間點，14 年底，從運維和基礎(chǔ)架構(gòu)層面出發(fā)，當時我們面臨了國內(nèi)發(fā)行和海外發(fā)行的一些根本性的差異：

第一點： 網(wǎng)易游戲在國內(nèi)是有 自建數(shù)據(jù)中心 的，但是游戲出海我們不可能去每一個發(fā)行的地方自建機房，所以會考慮引入 公有云 的基礎(chǔ)設(shè)施；
第二點：因為要引入公有云，海外使用的資源是 虛擬化的，而我們原來在國內(nèi)還有比較多的使用 物理資源；
第三點： 云上的資源是 彈性 的，而物理資源是 固定 的；
第四點： 國內(nèi)發(fā)行的游戲 只要覆蓋國內(nèi)網(wǎng)絡(luò)，但是發(fā)行到海外的話我們面臨的是 全球范圍的網(wǎng)絡(luò) 情況。

這些差異化給我們帶來了新的挑戰(zhàn)，總的來說就分為這幾點：

第一：性能。 國內(nèi)可以直接用物理網(wǎng)絡(luò)設(shè)備和服務器承載高性能的業(yè)務，如果在海外用公有云的虛擬網(wǎng)絡(luò)和服務器，這些虛擬化的資源能否滿足游戲業(yè)務需求，這對我們來說其實是一個未知數(shù)。

第二，動態(tài)彈性。 因為云資源大都是按時收費的，所以從成本考慮會引入動態(tài)伸縮的方案，而動態(tài)伸縮對于游戲業(yè)務和基礎(chǔ)架構(gòu)來說也是一個全新的內(nèi)容。

第三，安全性。 國內(nèi)我們有自建的數(shù)據(jù)中心，安全性比較容易掌控。在公有云上我們就需要考慮很多安全方面的因素，除了網(wǎng)絡(luò)安全，還有數(shù)據(jù)安全等。

第四，全球通服。 游戲海外發(fā)行給我們帶來一個全新的需求就是全球通服，后面也會介紹我們在全球通服方面的一些實踐。

基于這些海外發(fā)行和國內(nèi)發(fā)行的差異和挑戰(zhàn)，從基礎(chǔ)架構(gòu)層面出發(fā)，我們一直在做的一件事情就是建立起一套標準化的云評測體系，來評估一個游戲是否能發(fā)行到公有云，以及哪個云能夠滿足需求標準，并且在實踐過程當中根據(jù)我們遇到的問題不斷迭代這套體系。

云測評標準

我們的評測大概分為這幾個方面，第一是基礎(chǔ)設(shè)施層面，例如對于計算、存儲的性能 / 可靠性 / 可用性方面的考量，還有對于網(wǎng)絡(luò)質(zhì)量的評估，會分為數(shù)據(jù)中心網(wǎng)絡(luò)以及玩家網(wǎng)絡(luò)兩方面。第二個就是安全性，剛才也已經(jīng)有提過。另外也會有技術(shù)支持，成本等多方位的評估，這次分享會集中講我們在計算性能以及網(wǎng)絡(luò)延遲方面是怎么做的。

性能測評

首先是計算性能的評測，對于 CPU 可能很多同學都已經(jīng)比較熟悉了，常規(guī)評估會從硬件架構(gòu) / 型號 / 核數(shù) / 主頻等指標出發(fā)，然后做一些 Benchmark 性能測試，但我今天要講的重點不是在這些方面。

我想先講一個案例，在 16 年底當時《陰陽師》有在海外部署兩個服，一個是日服，第二個是北美的全球華人服，兩個服都跑在 AWS，用了相同的機型，運行相同的操作系統(tǒng)和游戲程序代碼，但是很奇怪的一個現(xiàn)象是日服的性能只有美服的十分之一，日服在一開始完全無法支撐當時的發(fā)行需求。

從運維的角度，硬件 / 系統(tǒng) / 軟件代碼層面都沒有什么差異，就先從業(yè)務進程這邊先入手排查一下。這是當時陰陽師代碼壓測的情況，上面是日服，可以看到在空跑的狀態(tài)下 CPU 總體使用率就超過 60%，下面是美服，在空跑狀態(tài)下它 CPU 總體使用率不到 5%。

通過 Perf top 或者是 strace 之類的工具去分析進程到底消耗在哪些系統(tǒng)調(diào)用，我們發(fā)現(xiàn)大部分的調(diào)用在 hrtimer，這是獲取時鐘源的指令，其實對很多游戲引擎來說可能都會依賴這個調(diào)用，因為需要加程序插樁用于性能 profile，所以當時我們就懷疑到可能是時鐘源設(shè)置上的差異，一看果然是。

上面是性能有問題的時鐘源，設(shè)置成了 hpet，下面是正常服的時鐘源，它設(shè)置的是 xen，但是 Hpet 是讀主板的時鐘的，而 Tsc 這些是直接讀 CPU 寄存器的，兩者性能相差懸殊，而兩個服支持的時鐘源完全一樣。

這里其實引伸出另一個問題，網(wǎng)易游戲是有一套服務器初始化的自動化標準流程的，當時我們的流程沒有把 AWS 時鐘源統(tǒng)一設(shè)置為高性能 tsc 的原因是 AWS 的機型少支持某一個 cpu 指令，我們會根據(jù)有沒有這些指令 flag 去設(shè)置時鐘源，初始化流程沒有去設(shè)置就導致它用了 AWS 自動設(shè)置的時鐘源，而 AWS 會自動隨機設(shè)置成 hpet/xen/tsc 的任意一種；

解決方案是很簡單的，我們在初始化流程里去定制 AWS 的機器要把它設(shè)置成我們想要的時鐘源。 在經(jīng)過這個問題之后我們就把 CPU 所支持的指令集以及時鐘源作為一個關(guān)鍵的評測指標，如果說新的平臺需要改用新的時鐘源，比如 5 系實例是一個新的 nitro 平臺，它引入了全新的時鐘源叫做 kvm-clock。那么針對這個時鐘源我們就需要做游戲引擎的壓測，確認這個時鐘源的性能能夠滿足業(yè)務的需求。

接下來再看另外一個案例，在 2018 年初 Intel 的兩個漏洞 Spectre&Meltdown 全面爆發(fā)，所有云商都跟進修復這個漏洞，當然 AWS 也很快修復了這個漏洞，修復這個漏洞需要底層打上幾個補丁，當時我們發(fā)現(xiàn)漏洞修復后 3 系，4 系的實例都出現(xiàn)不同程度的 CPU 性能損失，尤其是對于網(wǎng)絡(luò)密集型的業(yè)務，最多會出現(xiàn) 50% 的下降。

而《荒野行動》的游戲服恰好是網(wǎng)絡(luò)密集型的業(yè)務，并且 18 年初正好是《荒野行動》在春節(jié)期間人數(shù)一直上升的階段，所以這個性能下降導致了當時玩家承載量上不去，需要排隊。

這里截取了游戲壓測的 CPU 負載情況，最下面的那條線就是某一個 CPU 的 SI 的軟中段已經(jīng)到達瓶頸，pps 已經(jīng)撐不住了會開始丟包，玩家的體驗沒辦法保證，但整體的 CPU 性能并沒有達到瓶頸，大概是百分之四、五十還沒有被充分利用，但就是因為某一個 CPU 的 si 吃滿導致了網(wǎng)絡(luò)軟中段的性能瓶頸。

這里第一個想到的方案可能就是堆機器，是不是增加機器就可以提升承載量？這個方案不是很可行，或者是它的效果不佳。因為我一旦增加機器的話整個集群內(nèi)部的通信反而會增加，而且瓶頸仍然會在那個 CPU 核上。增加機器是一種提升效率不佳，而且成本又很高的方式。

接著我們就嘗試從系統(tǒng)層面去優(yōu)化，當時我們專門跟 AWS 的架構(gòu)師進行探討，4 系的實例是支持多少個網(wǎng)卡隊列？結(jié)論是應該有兩個隊列，然而我們在系統(tǒng)里面看到只有一個隊列，我們懷疑可能是因為用的網(wǎng)卡的驅(qū)動版本太老了，然后就把它做了升級，確實就有兩個隊列，并且開啟了 Irq，Irq 是從 linux 2.6.22 內(nèi)核開始引入的一個新特型，它可以把硬件多個網(wǎng)卡隊列的數(shù)據(jù)包處理分散到多個 CPU 核上去，這樣一來兩個隊列可以分散到兩個 CPU 核上，這個優(yōu)化可以提升約 50% PPS 承載量。

但是光靠這個還不夠，還沒有達到漏洞修復前的性能，我們繼續(xù)尋找其它的優(yōu)化方式，考慮引入 RPS 跟 RFS， 它是從 linux 2.6.35 開始進入 linux 內(nèi)核的，通過軟件模擬的方式實現(xiàn)更多多隊列的功能，把軟中斷負載分散到多個 CPU 核上去。但是默認情況下我們不會去開 RPS，因為它會造成額外 CPU 的開銷，這個分散本身就會消耗一定的 CPU?；趦蓚€隊列確實已經(jīng)不夠，那我們就選擇開啟，開了之后大概能提升 40% 左右的 PP。

這里也再提一下 RFS，雖然說我們把網(wǎng)卡分散到了多個 CPU，但是有可能出現(xiàn)這樣的情況，即給該數(shù)據(jù)流分發(fā)的 CPU 核和執(zhí)行處理該數(shù)據(jù)流的應用程序的 CPU 核不是同一個，這樣對于 CPU CACHE 的性能影響較大，RFS 就是保證應用程序處理的 cpu 跟軟中斷處理的 cpu 是同一個，從而保證 CPU CACHE，當然這兩個特性一般來說都是結(jié)合一起開的。

做了這兩個提升之后系統(tǒng)的網(wǎng)絡(luò)包處理性能差不多已經(jīng)達到了之前說的因漏洞修復以前的狀態(tài)，但是這個狀態(tài)仍然沒辦法滿足需求，因為當時《荒野行動》在日本的人數(shù)一直新高，數(shù)據(jù)流的量級其實已經(jīng)超出了我們所用的 4 系實例的極限，我們開始思考當前的 4 系列虛擬化體系的性能可能已經(jīng)無法滿足現(xiàn)在的業(yè)務需求。

這時候剛好離 AWS 推出 5 系 Nitro 新平臺不久，這個平臺本身它有很多重大升級，包括硬件底層，hypervisor 層等都是全新的，尤其需要注意的一個是網(wǎng)絡(luò)性能優(yōu)化從 SRIOV 改成了 ENA，第二個是磁盤驅(qū)動改成了 NVMe。這兩個改變理論上來說是能夠本質(zhì)的提升網(wǎng)絡(luò)處理性能，所以我們開展了測試：

可以看到上面是 4 系，下面是 5 系。5 系最多有 8 個網(wǎng)卡隊列，它的網(wǎng)卡軟中斷負載可以更均衡的分散到多個核上去，所以能更加均衡的承載業(yè)務網(wǎng)絡(luò)數(shù)據(jù)，整體的實例性能也是可以繼續(xù)往下壓榨的，可以去到 70-80% 的總利用率。

我們還對比了他們的成本，4 系到 5 系實例的替換比例接近 2：1，可以節(jié)省不少成本。于是我們就進行了升級操作，包括操作系統(tǒng)、驅(qū)動、軟件依賴包等都做了升級，然而升級并沒有那么的順利，我們在 1 個月內(nèi)就遭遇了 8 次各種類的故障，其中有硬件底層的，有 hypervisor 層的，也有上層應用兼容性的問題。

所以這里也想提一點，對于一個新技術(shù)或者新平臺，我們還是需要用敬畏的心態(tài)面對它，而不是說好像覺得很厲害很牛，就去用它。其中有一個疑難問題我們也通過 AWS 的 enterprise support 跟 EC2 產(chǎn)品團隊直接進行了溝通。

我們定制了一個調(diào)試用的 linux 內(nèi)核，并且 EC2 團隊為我們定制了一個調(diào)試用的 hypervisor，加了很多的 debug 設(shè)置，然后在 dedicated host 上綁定這個 hypervisor 去跑應用來定位到底這個問題是什么，雖然最后還是沒有能定位到精確的問題，不過好在我們找到了一個 workaround，線上暫時來說可以有解決辦法，當然我們也仍然在尋找更優(yōu)雅的解決方案。

經(jīng)過這次實踐之后我們就實例支持的隊列數(shù) / 網(wǎng)卡數(shù)，包括支持的 IP 數(shù)都把它加到了我們的評測體系里面，以及它的帶寬和 PPS 指標，其中多網(wǎng)卡，多 IP 是有一些其他的應用場景需要的。

儲存測評

第二方面是存儲，主要就是可用性，IOPS，吞吐量等方面的評測。

這里要說一點的就是我們會更加追求性價比， 舉一個例子，假設(shè)有一個數(shù)據(jù)庫的應用它的需求是需要一個 600G 大小的快存儲，IOPS 要求是 10000，吞吐量要求是 200MB/s。因為這是一個高 IOPS 的應用，我們第一個想到的方案可能就是用 IO1 EBS，因為 IOE 是一個可以制定 IOPS 的高性能方案。

但其實還有一個方案是用一個很大的 GP2 的磁盤，GP2 是一種 IOPS 隨容量增大的 EBS，比如這里寫的 3.3T 這么大的磁盤，它的 IOPS 也能夠達到 10000，但是它的價格不到 IO1 的一半，這時候我們可能就傾向于用 GP2 去承載存儲密集型的業(yè)務。

網(wǎng)絡(luò)測評

接下來是網(wǎng)絡(luò)評測，這一塊分為兩方面：一個是 IDC 網(wǎng)絡(luò)，一個是玩家網(wǎng)絡(luò)。

IDC 網(wǎng)絡(luò)就會比較直觀了，比如說要在新加坡部署一個服，那新加坡的服跟日本的服互相之間可能需要交互，例如跨服戰(zhàn)斗。那這時候就需要評估新加坡到日本這些地方的數(shù)據(jù)中心的網(wǎng)絡(luò)延遲能否滿足游戲需求？

通常來說不同的游戲可能會有不一樣的需求，這個游戲是 100 毫秒，那個游戲可能是 200 毫秒，所以就需要我們有這樣的評測數(shù)據(jù)作為決策支撐。圖里是舉例在 AWS 上面的一個評測案例，我們評測了 AWS 新加坡到日本和韓國 AWS 節(jié)點之間的網(wǎng)絡(luò)情況；當然實際的評測會更加復雜和龐大一些。

對于玩家網(wǎng)絡(luò)評測，這個也很直白，比如說還是在新加坡部署一個服，但是面向的玩家可能是東南亞地區(qū)，越南，泰國，馬來，印尼，菲律賓等。

那這些地方的玩家到數(shù)據(jù)中心的網(wǎng)絡(luò)是否能夠滿足到我們游戲需要的延遲 / 丟包的要求，這就需要我們做一個全面的評測。通過我們在各地玩家客戶端 SDK 中加入探針去探測這些地區(qū)的玩家到數(shù)據(jù)中心網(wǎng)絡(luò)的延遲和丟包情況，一般的會測游戲本身流量基于的協(xié)議，比如說 TCP 或者是 UDP 或者是其它自研協(xié)議，圖中就是一個玩家網(wǎng)絡(luò)評測樣例。

數(shù)據(jù)為偽數(shù)據(jù)，僅作示例，請勿參考

其他測評

其它我們也會有很多方面的標準化評測，包括剛才提到的安全性是一個非常重要的方面，因為我們多款游戲在 DDOS 上吃過很多虧，也做了一些優(yōu)化方案，其他的還有例如基礎(chǔ)設(shè)施可編程，因為我們有數(shù)十上百款游戲，光在 AWS 上面可能就有成千上萬臺服務器，我們需要用到云的 API 或者是 SDK 來開發(fā)我們的自動化管理工具。

還有技術(shù)支持方面，除了售前的架構(gòu)咨詢，還有就是售后的 7*24 故障響應等等。另外成本也會做一個綜合的評估，包括收費模式，費用對比等；網(wǎng)易游戲?qū)υ频臉藴驶u測大概就是這一些方面。

經(jīng)過評測之后 AWS 是一個符合業(yè)務需求的選擇，因為 AWS 有廣泛的全球基礎(chǔ)設(shè)施，在計算存儲網(wǎng)絡(luò)等方面都有高性能的方案，所以很自然 AWS 成為我們海外發(fā)行比較重要的選擇之一。

實踐心得

最后我想分享一下經(jīng)過這幾年海外上云實踐的心得總結(jié)：

第一點：實踐永遠是檢驗技術(shù)的唯一標準，一項新的技術(shù)是否值得引入需要評估測試，經(jīng)過線上實踐驗證，能明確它能夠?qū)ξ覀儤I(yè)務產(chǎn)生價值我們才會認為它是一項很好的技術(shù)。

第二點：我們會在滿足業(yè)務需求的前提下不斷尋求成本優(yōu)化的解決方案。

第三點：不管是云還是游戲，每天都在快速發(fā)展，這就需要我們不斷學習，尋找業(yè)務的切入點， 切實滿足業(yè)務需求或優(yōu)化線上服務，我覺得這是我們做云架構(gòu)或云解決方案的核心價值。

希望能對大家有所啟發(fā)。

中國區(qū)首次舉辦的 AWS Game Tech Day- AWS 游戲開發(fā)者大會深圳站已與 2019 年 4 月 27 日完滿落幕，作為目前為止規(guī)模最大的 AWS 游戲行業(yè)會議, 內(nèi)容豐富更勝以往。對于行業(yè)未來發(fā)展，網(wǎng)易游戲?qū)W院與 AWS 擁有同樣的愿景，希望游戲能夠在運行流暢之余不斷創(chuàng)新，也希望借助這個平臺，與全球游戲熱愛者自由交流，碰撞出思想和技術(shù)的火花，攜手探索出更多的可能性