進化中的遊戲產業：以微服務架構、全球布局與現代化資料庫策略來打造高成長遊戲

這個議程很多資訊量，我只節錄筆記抄的和聽錄音檔的內容。

議程引言人講的遊戲產業上下游新的趨勢。引言人常會趁機介紹 AWS 提供的服務。

1. micro services
2. global gaming marketing and distribution
3. 手遊變得更熱門
4. 因為手機設備變得更好，手遊玩家追求更好的遊戲品質和流暢度
5. 用先進技術，例如 cloud native 打造遊戲服務

三個角度看遊戲產業的需求

• backend 角度 -> 需要 reliable 的 hosting service provider , 主要在日常營運, 附帶使用服務提供者具備的其他工具, 例如 AI, deep learning
• 即時資料分析
• 開發流程中使用 CI/CD
• tool chain 大量使用cloud native 服務

議程引言人講的各種挑戰

• 挑戰一：From monolithic to micro service

  • 拆分應用元件，例如遊戲大廳和遊戲房間，一個開啟不了的遊戲對使用者就是沒有用
  • 流行 event-driven design pattern，改用容器甚至是 Serverless ，所以服務之間的溝通介面很重要，例如： restful api, queue-pub-consumer pattern

• 挑戰二：Global gaming marketing 推廣的難度

  • 全球市場, AWS 在全球有很多 region
  • 中國市場, 在北京和寧夏有兩個 region

• 挑戰三：Modern DB strategy

  • 以前常使用關連式資料庫 RDBMS
  • In memory(Elastic Cache), NOSQL, Document DB -> 技術配合業務需求來選型，例如：追求更高效的存取效率、時序資料、區塊鏈…..等等。
  • 追求如何做 zero downtime 遷移資料

客戶案例分享 FourDesire:

• 是目前臺灣一家 Gamification 概念 app 起家的公司，平均每日15 萬人在線上，超過 4 億筆遊戲資料，發展到現在台灣使用者只佔約 8 ％，其他是國外使用者，總使用者數是2300多萬；目前公開出了 4 款遊戲(Fortune city記帳城市、Walkr 鼓勵大家走路、Plant Nanny鼓勵大家喝水、植物保姆)，都以 App 類型為主。
• 拆分 micro services 要考量的內容： 服務之間的 latency ，以及處理回應的時間、各地使用者收到回應的時間。舉例：按個按鈕四秒後才得到回應，使用者認為這是糞game。

• 服務模組化：
  1. 使用者帳號 Authentication，1User, Multiplayer ，因為這公司出多個遊戲。由暴風雪公司出的遊戲，都要先連線到遊戲大廳而聯想到的概念，想像成 single-sign on。
  2. 商城和付款服務。出到三個遊戲做三個商城時，感到很奇怪，所以拆成微服務。
  3. 成就系統。例如：做什麼事就會得到什麼勳章或道具。
  4. 營運人員後台 console 介面，一次看到所有支撐遊戲產品的各個服務元件狀態，方便管理
  5. 遊戲資料倉儲。用途是：儲存通用資料。
  6. 健康活動和金流 Kit。例如計步工具。
  7. 推播服務系統。例如排行榜、邀請好友、在遊戲中得到幾分。
  8. 行銷系統，例如發放折扣碼
  9. 每個遊戲的獨特資料倉儲。例如，每個遊戲產品各自定義的資料，不容易被儲存的特性。儲存成手機可定義的資料格式，使之存取方便。

拆分微服務的概念，分為兩大類

• Central servers

  1. 做各種微服務的 RESTful API，溝通介面很重要。
  2. Console 端監看各個服務，例如 access token，若拿到 token ，就可以管理和存取各種服務元件，及整合在 Webview 的介面上，用意是使用者更容易使用。
  3. Service 類別。例如：用戶端可以存取，讓使用者自己管理自己的資料，但還不會碰到商城的資料，相對安全。
  4. WebView，因為開發新產品手遊不保證都能上線，有時會需要設計華麗的畫面，例如排行榜，先用 WebView 解決問題。若受使用者喜愛，才下去做 Client 服務的元件。為了做 Prototype 快速推出市場試水溫，所以會先用 WebView 呈現，等到成果爆發之後，再做專屬遊戲 Client 端的工具。

• 做三種 Library 符合自己需求用途
  • Server to Server
  • Server to Client , 例如：平台 iOS, Unity, Android
  • WebView，為了做 Prototype 快速推出市場試水溫，所以會先用 WebView 呈現，等到成果爆發之後，再做專屬遊戲 Client 端的工具  

全球業務發展   

• 跨區域提供服務 -> Cross AWS region

  • 所有產品中，台灣使用者量平均是佔使用者總量的 8%，一些產品最多有 22 %台灣的使用者。
  • 當初寶可夢進來台灣時公司超害怕，因為公司有款遊戲 Walkr 概念很類似，但因為出的其他遊戲，在北美和歐洲很紅，所以產品在全球都有使用者，所以公司受到的影響還好。
  • 規劃各地用戶連到 server 的 AWS region：美東 region -> 美洲、歐洲的使用者，東京 region -> 泛亞洲區的使用者，剩下地區例如東南亞 -> 新加坡機房

• 額外考量到弱網路連結的情境。例如記帳軟體和計步器軟體，在弱網路或無網路連結時，Client端的遊戲也要持續運作，因為其他國家不像台灣行動通訊收訊好而且又有便宜吃到飽。這延伸出 Data warehouse Server 和 Client 端資料一致性的問題，偶爾會收到使用者抱怨或投訴它的道具怎麼不見了，所以我們的解決方法是，先將離線期間的資料存在使用者手機端的資料庫，下次連線時才傳回主機並同步資料。偶爾會發生這樣的情況，但發生機率很低。

面臨過的挑戰

• 在臺灣可以容易想像臺灣使用者的生活型態，但就不知道國外使用者型態和習慣輪廓。
  • 解決方式是用 AWS beanstalk 開 Metabase 畫出你想要的從資料庫取得資料的資料圖
• Data visualization

  1. 商業衡量指標，使用以下工具

     1. Klipfolio, 每個使用者正在做的事情，每個微服務正在處理的事情
     2. App Connect

  2. 效能評估指標，使用以下工具

     1. New Relic，因為公司技術層次使用 Rails，所以使用 New Relic
     2. Klipfolio
     3. AWS Cloudwatch 打開所有 alarm，當如果你不想使用其他服務。
• DB 策略(先考量要提供哪些功能，再選用哪種資料庫)
  1. 使用 RDS Aurora
     • Central Data
  2. Elastic Cache(Memory-based, 對遊戲類App 很有用的工具)
     • 暫存類型的資料，例如 shop、metadata
     • 再使用Elastic Cache Redis 的 long-polling、 slow job 的方式傳回 RDS
     • 也使用 ec2 開 background job 去傳資料回 RDS
  3. DynamoDB
     • 使用者活動的資料

公司未來的挑戰

• performance bottleneck，例如 每晚使用者記帳的時候，peek很快來，也很快就結束，根本來不及開伺服器
• 一個 micro service 混用兩個 DB
• 想要使用 AI machine 工具，用在理解消費者的理財習慣，讓我們的銷售更好
• 使用者行為的學習，因為想知道產品對使用者的幫助。
• 同步不同機器的資料(Synchronizer)，因為使用者在不同設備使用我們的產品，我們需要達到一致的資料，這非常困難，因為一般遊戲不會做到這功能。