网易游戏海外AWS实践分享
4 月 27 日，網易游戲學院受邀 AWS，作為主題演講分享的重磅嘉賓，參與了中國區 AWS Game Tech Day- AWS 游戲開發者大會深圳站分享，網易游戲資深云解決方案工程師孫國良代表網易團隊帶來了《網易游戲海外 AWS 實踐分享》，技術內容豐富，引起現場熱烈討論，與會人員收獲滿載。
孫國良，2013 年加入網易游戲，曾負責《天諭》《獵魂覺醒》《楚留香》等游戲項目運維工作，之后負責游戲出海對接公有云的運維架構以及混合云管理平臺設計，專注于混合云上業務解決方案和最佳實踐的沉淀積累。
孫國良帶來的《網易游戲海外 AWS 實踐分享》，分享了網易游戲在《陰陽師》《荒野行動》《第五人格》《明日之后》等多款游戲出海運營過程中積累的實踐經驗，這次分享以全球化的開放視野，與廣大游戲熱愛者共探云技術的實踐運用。
以下為分享實錄：
大家好，今天非常高興能夠 分享網易游戲海外在 AWS 云上的實踐情況，希望我分享的內容能給大家提供一些線上最佳實踐優化的思路，當然也非常歡迎大家對我分享的內容提出建議幫助我們一起改進在云上的業務架構。簡單自我介紹一下，我從 2013 年加入網易游戲，早期是做游戲運維的工作，是端游《天諭》、手游《楚留香》等游戲的運維負責人，后來我主要負責了網易游戲出海對接公有云的運維架構，以及國內外混合云解決方案方面的工作。
國內發行 VS 海外發行首先簡單介紹一下網易游戲出海的歷程，這里主要是指手游。 我們差不多是從 14 年底 15 年初開始做海外發行，比較典型的游戲有《陰陽師》《荒野行動》《終結者》《第五人格》等等， 今年我們也會有更多的游戲出海發行，比如最近發布的《明日之后》《量子特工》等，后續還會有更多的重磅游戲，敬請期待。
根據第三方統計，去年中國的游戲發行商在海外的收入排行榜中網易取得了第三的成績，并且中國出海手游收入榜單前 30 中我們有兩款游戲上榜——《荒野行動》和《終結者》。根據 Sensor Tower 的統計，《荒野行動》2018 年在全球吸金 4.56 億美元，其中日本玩家貢獻了八成。當然我們也還有其它很多游戲在全球多個地區取得了不錯的成績。
我們回到剛開始出海的時間點，14 年底，從運維和基礎架構層面出發，當時我們面臨了國內發行和海外發行的一些根本性的差異：
第一點： 網易游戲在國內是有 自建數據中心 的，但是游戲出海我們不可能去每一個發行的地方自建機房，所以會考慮引入 公有云 的基礎設施；第二點：因為要引入公有云，海外使用的資源是 虛擬化的，而我們原來在國內還有比較多的使用 物理資源；第三點： 云上的資源是 彈性 的，而物理資源是 固定 的；第四點： 國內發行的游戲 只要覆蓋國內網絡，但是發行到海外的話我們面臨的是 全球范圍的網絡 情況。
這些差異化給我們帶來了新的挑戰，總的來說就分為這幾點：
第一：性能。 國內可以直接用物理網絡設備和服務器承載高性能的業務，如果在海外用公有云的虛擬網絡和服務器，這些虛擬化的資源能否滿足游戲業務需求，這對我們來說其實是一個未知數。
第二，動態彈性。 因為云資源大都是按時收費的，所以從成本考慮會引入動態伸縮的方案，而動態伸縮對于游戲業務和基礎架構來說也是一個全新的內容。
第三，安全性。 國內我們有自建的數據中心，安全性比較容易掌控。在公有云上我們就需要考慮很多安全方面的因素，除了網絡安全，還有數據安全等。
第四，全球通服。 游戲海外發行給我們帶來一個全新的需求就是全球通服，后面也會介紹我們在全球通服方面的一些實踐。
基于這些海外發行和國內發行的差異和挑戰，從基礎架構層面出發，我們一直在做的一件事情就是建立起一套標準化的云評測體系，來評估一個游戲是否能發行到公有云，以及哪個云能夠滿足需求標準，并且在實踐過程當中根據我們遇到的問題不斷迭代這套體系。
云測評標準我們的評測大概分為這幾個方面，第一是基礎設施層面，例如對于計算、存儲的性能 / 可靠性 / 可用性方面的考量，還有對于網絡質量的評估，會分為數據中心網絡以及玩家網絡兩方面。第二個就是安全性，剛才也已經有提過。另外也會有技術支持，成本等多方位的評估，這次分享會集中講我們在計算性能以及網絡延遲方面是怎么做的。
性能測評首先是計算性能的評測，對于 CPU 可能很多同學都已經比較熟悉了，常規評估會從硬件架構 / 型號 / 核數 / 主頻等指標出發，然后做一些 Benchmark 性能測試，但我今天要講的重點不是在這些方面。
我想先講一個案例，在 16 年底當時《陰陽師》有在海外部署兩個服，一個是日服，第二個是北美的全球華人服，兩個服都跑在 AWS，用了相同的機型，運行相同的操作系統和游戲程序代碼，但是很奇怪的一個現象是日服的性能只有美服的十分之一，日服在一開始完全無法支撐當時的發行需求。
從運維的角度，硬件 / 系統 / 軟件代碼層面都沒有什么差異，就先從業務進程這邊先入手排查一下。這是當時陰陽師代碼壓測的情況，上面是日服，可以看到在空跑的狀態下 CPU 總體使用率就超過 60%，下面是美服，在空跑狀態下它 CPU 總體使用率不到 5%。
通過 Perf top 或者是 strace 之類的工具去分析進程到底消耗在哪些系統調用，我們發現大部分的調用在 hrtimer，這是獲取時鐘源的指令，其實對很多游戲引擎來說可能都會依賴這個調用，因為需要加程序插樁用于性能 profile，所以當時我們就懷疑到可能是時鐘源設置上的差異，一看果然是。
上面是性能有問題的時鐘源，設置成了 hpet，下面是正常服的時鐘源，它設置的是 xen，但是 Hpet 是讀主板的時鐘的，而 Tsc 這些是直接讀 CPU 寄存器的，兩者性能相差懸殊，而兩個服支持的時鐘源完全一樣。
這里其實引伸出另一個問題，網易游戲是有一套服務器初始化的自動化標準流程的，當時我們的流程沒有把 AWS 時鐘源統一設置為高性能 tsc 的原因是 AWS 的機型少支持某一個 cpu 指令，我們會根據有沒有這些指令 flag 去設置時鐘源，初始化流程沒有去設置就導致它用了 AWS 自動設置的時鐘源，而 AWS 會自動隨機設置成 hpet/xen/tsc 的任意一種；
解決方案是很簡單的，我們在初始化流程里去定制 AWS 的機器要把它設置成我們想要的時鐘源。 在經過這個問題之后我們就把 CPU 所支持的指令集以及時鐘源作為一個關鍵的評測指標，如果說新的平臺需要改用新的時鐘源，比如 5 系實例是一個新的 nitro 平臺，它引入了全新的時鐘源叫做 kvm-clock。那么針對這個時鐘源我們就需要做游戲引擎的壓測，確認這個時鐘源的性能能夠滿足業務的需求。
接下來再看另外一個案例，在 2018 年初 Intel 的兩個漏洞 Spectre&Meltdown 全面爆發，所有云商都跟進修復這個漏洞，當然 AWS 也很快修復了這個漏洞，修復這個漏洞需要底層打上幾個補丁，當時我們發現漏洞修復后 3 系，4 系的實例都出現不同程度的 CPU 性能損失，尤其是對于網絡密集型的業務，最多會出現 50% 的下降。
而《荒野行動》的游戲服恰好是網絡密集型的業務，并且 18 年初正好是《荒野行動》在春節期間人數一直上升的階段，所以這個性能下降導致了當時玩家承載量上不去，需要排隊。
這里截取了游戲壓測的 CPU 負載情況，最下面的那條線就是某一個 CPU 的 SI 的軟中段已經到達瓶頸，pps 已經撐不住了會開始丟包，玩家的體驗沒辦法保證，但整體的 CPU 性能并沒有達到瓶頸，大概是百分之四、五十還沒有被充分利用，但就是因為某一個 CPU 的 si 吃滿導致了網絡軟中段的性能瓶頸。
這里第一個想到的方案可能就是堆機器，是不是增加機器就可以提升承載量？這個方案不是很可行，或者是它的效果不佳。因為我一旦增加機器的話整個集群內部的通信反而會增加，而且瓶頸仍然會在那個 CPU 核上。增加機器是一種提升效率不佳，而且成本又很高的方式。
接著我們就嘗試從系統層面去優化，當時我們專門跟 AWS 的架構師進行探討，4 系的實例是支持多少個網卡隊列？結論是應該有兩個隊列，然而我們在系統里面看到只有一個隊列，我們懷疑可能是因為用的網卡的驅動版本太老了，然后就把它做了升級，確實就有兩個隊列，并且開啟了 Irq，Irq 是從 linux 2.6.22 內核開始引入的一個新特型，它可以把硬件多個網卡隊列的數據包處理分散到多個 CPU 核上去，這樣一來兩個隊列可以分散到兩個 CPU 核上，這個優化可以提升約 50% PPS 承載量。
但是光靠這個還不夠，還沒有達到漏洞修復前的性能，我們繼續尋找其它的優化方式，考慮引入 RPS 跟 RFS， 它是從 linux 2.6.35 開始進入 linux 內核的，通過軟件模擬的方式實現更多多隊列的功能，把軟中斷負載分散到多個 CPU 核上去。但是默認情況下我們不會去開 RPS，因為它會造成額外 CPU 的開銷，這個分散本身就會消耗一定的 CPU?；趦蓚€隊列確實已經不夠，那我們就選擇開啟，開了之后大概能提升 40% 左右的 PP。
這里也再提一下 RFS，雖然說我們把網卡分散到了多個 CPU，但是有可能出現這樣的情況，即給該數據流分發的 CPU 核和執行處理該數據流的應用程序的 CPU 核不是同一個，這樣對于 CPU CACHE 的性能影響較大，RFS 就是保證應用程序處理的 cpu 跟軟中斷處理的 cpu 是同一個，從而保證 CPU CACHE，當然這兩個特性一般來說都是結合一起開的。
做了這兩個提升之后系統的網絡包處理性能差不多已經達到了之前說的因漏洞修復以前的狀態，但是這個狀態仍然沒辦法滿足需求，因為當時《荒野行動》在日本的人數一直新高，數據流的量級其實已經超出了我們所用的 4 系實例的極限，我們開始思考當前的 4 系列虛擬化體系的性能可能已經無法滿足現在的業務需求。
這時候剛好離 AWS 推出 5 系 Nitro 新平臺不久，這個平臺本身它有很多重大升級，包括硬件底層，hypervisor 層等都是全新的，尤其需要注意的一個是網絡性能優化從 SRIOV 改成了 ENA，第二個是磁盤驅動改成了 NVMe。這兩個改變理論上來說是能夠本質的提升網絡處理性能，所以我們開展了測試：
可以看到上面是 4 系，下面是 5 系。5 系最多有 8 個網卡隊列，它的網卡軟中斷負載可以更均衡的分散到多個核上去，所以能更加均衡的承載業務網絡數據，整體的實例性能也是可以繼續往下壓榨的，可以去到 70-80% 的總利用率。
我們還對比了他們的成本，4 系到 5 系實例的替換比例接近 2：1，可以節省不少成本。于是我們就進行了升級操作，包括操作系統、驅動、軟件依賴包等都做了升級，然而升級并沒有那么的順利，我們在 1 個月內就遭遇了 8 次各種類的故障，其中有硬件底層的，有 hypervisor 層的，也有上層應用兼容性的問題。
所以這里也想提一點，對于一個新技術或者新平臺，我們還是需要用敬畏的心態面對它， 而不是說好像覺得很厲害很牛，就去用它。其中有一個疑難問題我們也通過 AWS 的 enterprise support 跟 EC2 產品團隊直接進行了溝通。
我們定制了一個調試用的 linux 內核，并且 EC2 團隊為我們定制了一個調試用的 hypervisor，加了很多的 debug 設置，然后在 dedicated host 上綁定這個 hypervisor 去跑應用來定位到底這個問題是什么，雖然最后還是沒有能定位到精確的問題，不過好在我們找到了一個 workaround，線上暫時來說可以有解決辦法，當然我們也仍然在尋找更優雅的解決方案。
經過這次實踐之后我們就實例支持的隊列數 / 網卡數，包括支持的 IP 數都把它加到了我們的評測體系里面，以及它的帶寬和 PPS 指標，其中多網卡，多 IP 是有一些其他的應用場景需要的。
儲存測評第二方面是存儲，主要就是可用性，IOPS，吞吐量等方面的評測。
這里要說一點的就是我們會更加追求性價比， 舉一個例子，假設有一個數據庫的應用它的需求是需要一個 600G 大小的快存儲，IOPS 要求是 10000，吞吐量要求是 200MB/s。因為這是一個高 IOPS 的應用，我們第一個想到的方案可能就是用 IO1 EBS，因為 IOE 是一個可以制定 IOPS 的高性能方案。
但其實還有一個方案是用一個很大的 GP2 的磁盤，GP2 是一種 IOPS 隨容量增大的 EBS，比如這里寫的 3.3T 這么大的磁盤，它的 IOPS 也能夠達到 10000，但是它的價格不到 IO1 的一半，這時候我們可能就傾向于用 GP2 去承載存儲密集型的業務。
網絡測評接下來是網絡評測，這一塊分為兩方面：一個是 IDC 網絡，一個是玩家網絡。
IDC 網絡就會比較直觀了，比如說要在新加坡部署一個服，那新加坡的服跟日本的服互相之間可能需要交互，例如跨服戰斗。那這時候就需要評估新加坡到日本這些地方的數據中心的網絡延遲能否滿足游戲需求？
通常來說不同的游戲可能會有不一樣的需求，這個游戲是 100 毫秒，那個游戲可能是 200 毫秒，所以就需要我們有這樣的評測數據作為決策支撐。圖里是舉例在 AWS 上面的一個評測案例，我們評測了 AWS 新加坡到日本和韓國 AWS 節點之間的網絡情況；當然實際的評測會更加復雜和龐大一些。
對于玩家網絡評測，這個也很直白，比如說還是在新加坡部署一個服，但是面向的玩家可能是東南亞地區，越南，泰國，馬來，印尼，菲律賓等。
那這些地方的玩家到數據中心的網絡是否能夠滿足到我們游戲需要的延遲 / 丟包的要求，這就需要我們做一個全面的評測。通過我們在各地玩家客戶端 SDK 中加入探針去探測這些地區的玩家到數據中心網絡的延遲和丟包情況，一般的會測游戲本身流量基于的協議，比如說 TCP 或者是 UDP 或者是其它自研協議，圖中就是一個玩家網絡評測樣例。
數據為偽數據，僅作示例，請勿參考
其他測評其它我們也會有很多方面的標準化評測，包括剛才提到的安全性是一個非常重要的方面，因為我們多款游戲在 DDOS 上吃過很多虧，也做了一些優化方案，其他的還有例如基礎設施可編程，因為我們有數十上百款游戲，光在 AWS 上面可能就有成千上萬臺服務器，我們需要用到云的 API 或者是 SDK 來開發我們的自動化管理工具。
還有技術支持方面，除了售前的架構咨詢，還有就是售后的 7*24 故障響應等等。另外成本也會做一個綜合的評估，包括收費模式，費用對比等；網易游戲對云的標準化評測大概就是這一些方面。
經過評測之后 AWS 是一個符合業務需求的選擇，因為 AWS 有廣泛的全球基礎設施，在計算存儲網絡等方面都有高性能的方案，所以很自然 AWS 成為我們海外發行比較重要的選擇之一。
實踐心得最后我想分享一下經過這幾年海外上云實踐的心得總結：
第一點：實踐永遠是檢驗技術的唯一標準，一項新的技術是否值得引入需要評估測試，經過線上實踐驗證，能明確它能夠對我們業務產生價值我們才會認為它是一項很好的技術。
第二點：我們會在滿足業務需求的前提下不斷尋求成本優化的解決方案。
第三點：不管是云還是游戲，每天都在快速發展，這就需要我們不斷學習，尋找業務的切入點， 切實滿足業務需求或優化線上服務，我覺得這是我們做云架構或云解決方案的核心價值。
希望能對大家有所啟發。
中國區首次舉辦的 AWS Game Tech Day- AWS 游戲開發者大會深圳站已與 2019 年 4 月 27 日完滿落幕，作為目前為止規模最大的 AWS 游戲行業會議, 內容豐富更勝以往。對于行業未來發展，網易游戲學院與 AWS 擁有同樣的愿景，希望游戲能夠在運行流暢之余不斷創新，也希望借助這個平臺，與全球游戲熱愛者自由交流，碰撞出思想和技術的火花，攜手探索出更多的可能性。
（附活動照片如下）
如大家想獲悉更多網易分享內容，了解更多網易資訊，那么機會來了！
2019 AWS Game Tech Day?
上海站即將拉開帷幕
“中國智造”的游戲也大有風靡世界的潛力各位游戲行業大佬們，歡迎來這里交流嬉戲 :)
關于 AWS Game Tech Day在 AWS Game Tech Day 上，我們特別為客戶精選了游戲行業云端議程，內容將涵蓋多個重點主題：
?云上的游戲數據湖及機器學習在游戲開發中的應用；深入探討游戲全球同服架構構建部署；DDOS 防護方法實踐；
我們還將與全球的游戲行業客戶一起，分享和探討這些寶貴的經驗以及最新的技術，除此之外，還將特別企劃一場 “Amazon GameLift 動手實戰訓練營”，為學員提供真實的 GameLift 服務管理與操作環境，從實驗中學習，輔以講師要點精講，快速上手 GameLift 服務！
現在掃碼，即刻報名！
會議時間：2019 年 5 月 28 日（星期二）, 08:30-17:30
現在就加入 AWS 中國游戲開發者大會2019 AWS Game Tech Day
總結
以上是生活随笔為你收集整理的网易游戏海外AWS实践分享的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 电脑技巧：分享常用的电脑快捷键
- 下一篇： 小程序画布之CanvasContext