跳至主要內容
登雲學院 CloudOn 登雲學院.
ESC
🎮 遊戲產業 難度 ★★☆

Mountkirk Games

一句話描述:一家把旗艦遊戲搬上雲端、想用全球多區部署吸引海外玩家的遊戲公司,核心挑戰是在延遲、成本與玩家體驗之間找出 GCP 的最佳組合。

🏢 商業背景

線上遊戲這個產業的特性相當獨特:營收高度集中在少數爆款,一款遊戲能不能活下來,通常在上線前兩週的玩家體驗就決定了。一旦首發期卡頓、連線掉線或配對等太久,玩家轉台的速度比任何其他數位服務都快—因為替代品多到選不完。換句話說,遊戲後端不是一個「穩定就好」的系統,它必須在超高變動的流量下,維持毫秒級的體感回饋。

典型的線上遊戲公司規模會從數十到數百萬 DAU 不等,但玩家分佈幾乎是全球性的:北美、歐洲、東亞、東南亞都是主力市場,彼此時差讓流量曲線有多個尖峰。再加上玩家期待跟其他地區對手同場對戰,這讓「把伺服器放在哪」變成一個沒有標準答案的決策—放近玩家可以降延遲,但跨區對戰就變成協調噩夢。

從商業模式來看,遊戲公司普遍面臨兩個現實:一是遊戲生命週期越來越短,投資回收期被壓縮;二是營運成本浮動極大,週末與活動期可能是平日的 10 倍以上。這讓「能不能按使用量付費、能不能快速擴縮」直接連結到公司的毛利率。把架構搬上雲、換掉固定資本支出,通常不是為了新奇,而是被營收結構逼出來的選擇。

⚡ 主要技術挑戰

  • 全球玩家、在地延遲玩家散佈五大洲,但任何一個玩家在按下技能鍵到看到畫面反應之間,不能超過人腦可感知的閾值(約 80-100ms)。
  • 流量可以 10 倍爆衝新內容發布、週末活動、網紅直播都可能讓連線瞬間翻倍,autoscaling 必須在「秒」而不是「分鐘」內反應。
  • Session 狀態難處理玩家連線通常是長連結、有狀態,跟一般無狀態 web 請求完全不同;重開 instance 不能讓玩家被踢下線。
  • 即時排行榜與配對計分與匹配是毫秒級讀寫密集場景,傳統 RDBMS 會直接被打爆。
  • 分析需求同樣強營運團隊想即時看到玩家流失點、付費漏斗、關卡難度分布—這些都是遊戲改版的命脈。

🏗️ 建議 GCP 架構

這個案例我會採用「多區 GKE 遊戲伺服器 + Memorystore 為核心 session 儲存 + Pub/Sub 為事件匯流排 + BigQuery 為玩家行為倉儲」的混合模式。前端以 Global HTTP(S) Load Balancer 加 Cloud CDN 處理下載、更新與資產;遊戲伺服器本體跑在 GKE 的多個 regional cluster,用 Agones 管理遊戲 session pod 的生命週期;即時資料(排行榜、配對佇列)走 Memorystore for Redis 確保毫秒級回應;玩家行為事件先經 Pub/Sub 緩衝,再由 Dataflow 串進 BigQuery 做即時分析。 


        ┌──────────────────────────────────────────┐
        │          全球玩家（跨五大洲）            │
        └────────────────┬─────────────────────────┘
                         │
            ┌────────────▼─────────────┐
            │  Global External Load    │
            │  Balancer + Cloud CDN    │
            └────────┬─────────┬───────┘
                     │         │
          ┌──────────▼─┐    ┌──▼──────────┐
          │ GKE Region │    │ GKE Region  │
          │ (us)       │    │ (asia)      │
          │  + Agones  │    │  + Agones   │
          └──┬──────┬──┘    └──┬──────┬───┘
             │      │          │      │
             ▼      ▼          ▼      ▼
        ┌────────┐ ┌─────────┐ ┌────────┐
        │Memory- │ │ Cloud   │ │Pub/Sub │
        │store   │ │ Spanner │ │(events)│
        │(sessn) │ │(player) │ └───┬────┘
        └────────┘ └─────────┘     │
                                   ▼
                            ┌──────────┐
                            │ Dataflow │
                            └────┬─────┘
                                 ▼
                           ┌──────────┐
                           │ BigQuery │
                           └──────────┘

為什麼選 GKE 不選 Cloud Run?遊戲伺服器是長連結、有狀態、需要精確控制 pod 生命週期的工作負載,Cloud Run 的請求導向模型不適合。Agones 在 GKE 上補齊了「session 分配、warm pool、scale-to-zero」這些遊戲專屬需求。玩家帳號資料之所以選 Cloud Spanner,是因為玩家可能在任何地區登入,需要強一致 + 全球分布;用 Cloud SQL 會卡在單區主從複製的瓶頸。

🎯 關鍵設計決策

決策 選這個的理由 替代方案
多區 GKE + Agones 管遊戲 session 遊戲 server 需要精細控制生命週期,Agones 是專為此設計;GKE regional 配置也能扛區域故障 Compute Engine MIG(自行寫 orchestration 負擔重)、Cloud Run(不支援長連結有狀態場景)
Memorystore for Redis 放排行榜與 session Sorted Set + HSET 原生支援排行榜與即時排名,延遲穩定在 1ms 以下 Cloud Spanner(延遲高)、自架 Redis(要自行維運 HA)
Pub/Sub + Dataflow + BigQuery 事件管線 事件峰值高、需要 at-least-once 保證,Pub/Sub 能吸收流量;BigQuery 分析 PB 級資料不用煩惱 index Kafka on GCE(要自己維運)、直接寫 Cloud SQL(分析查詢會拖垮交易庫)

📝 PCA 考點拆解

考點 1:全球負載平衡與在地部署

看到「玩家遍布全球、延遲敏感」這類描述,第一反應應該是 Global External HTTPS Load Balancer + 多區 backend service。它會自動把流量導向最近的健康後端,這是區域型 LB 做不到的。

考點 2:Autoscaling 策略

遊戲場景的 autoscaling 不能只看 CPU 使用率,要看「活躍 session 數」或「配對佇列深度」。答題時留意題目有沒有提到「自訂 metric」,這通常是在暗示你用 Cloud Monitoring custom metric + HPA。

考點 3:選對儲存服務

玩家帳號(全球強一致)→ Spanner;即時 session 與排行榜 → Memorystore;玩家行為分析 → BigQuery。PCA 考試最愛考「哪種工作負載配哪種儲存」,只要記得「一致性 × 延遲 × 規模」三軸就不會錯。

考點 4:事件驅動解耦

題目只要出現「玩家行為分析」「即時儀表板」「事件數 PB 級」,答案幾乎就是 Pub/Sub → Dataflow → BigQuery 這條黃金管線,要能從描述倒推出這個結構。

📐

換你練習

讀完架構分析只是第一步。到 PCA 架構師設計工作坊 把 Mountkirk Games 當作你的情境,跟著 13 步驟從商業需求、SLI/SLO、服務拆分、DR 策略一路做到成本估算。動手寫一次,面對考試的情境題會快很多。

前往工作坊

🔗 延伸閱讀

徽章解鎖！