這個案例的核心責任是說明「事件型不可預期峰值」的工程做法。體育博彩流量的形狀跟 Prime Day 不同 — 峰值會在賽事的特定瞬間（進球、最後一分鐘）爆量、單一賽事內可能有多次脈衝、跨賽事的時間點難以提前數月排程。GR8 Tech 在 2022 FIFA World Cup 期間達到零停機營運、是這類負載形狀的有效參考。

觀察

GR8 Tech 從本地基礎設施遷移到 AWS、重建為微服務架構後的關鍵數字（引自 GR8 Tech case study）：

指標遷移前狀況遷移後峰值
投注延遲賽事高峰期額外延遲 2-3 秒25 ms p95
結算吞吐（未公開）每分鐘 100 萬次投注結算
交易吞吐（未公開）54000 TPS @ 25ms p95
同時在線-200,000+ 同時使用者
投注吞吐-每分鐘 80,000 次體育投注
可用性-99.95% uptime
成本彈性固定預配置需求降低時成本下降 25%

服務組合：Amazon EKS（Kubernetes 容器編排、跨雲端與本地）、Amazon EC2（compute）、Amazon S3 與 Amazon EBS（儲存）、AWS Auto Scaling 結合 GR8 Tech 自家 AI 預測模型、AWS Infrastructure Event Management（重大賽事支援）。

擴展範圍：「Scaled to 15 markets using AWS」。事件覆蓋：2022 FIFA World Cup 期間零停機。

判讀

GR8 Tech 的工程做法揭露三個事件型峰值的判讀重點。

  1. 不可預期 ≠ 不可預測：賽事「何時開打」是已知的（schedule 提前公告）、「賽事內何時爆量」是未知的（進球、加時、最後一分鐘）。AI 預測模型不是預測「會不會有峰值」、而是預測「峰值在 60 秒內可能多大」、把擴容窗口縮短到反應時間之內。對應 9.11 高峰事件準備 跟 9.6 容量規劃模型 的「預測時間尺度」軸。
  2. 延遲是業務指標、不是技術指標：「2-3 秒額外延遲」直接造成「投注失敗、客戶流失」。25ms p95 是收入 KPI 而不是 SLO 漂亮數字。對應 9.8 效能可觀測性 把 latency 翻成業務 metric 的責任。
  3. 微服務 + 容器編排是擴容粒度的前置：遷移前的單體系統「擴容」只能複製整套系統、成本曲線陡峭。EKS 拆解後可以針對熱點服務（投注引擎、結算引擎）獨立擴容、跟 9.5 瓶頸定位流程 的逐層定位直接對齊。

需要警惕的判讀盲點：54000 TPS @ 25ms 是 公開的成功數字、不是「永遠都這樣」的承諾。AI 預測模型必然有預測誤差、AWS Infrastructure Event Management 也是事件型服務、不是平台預設。這類案例適合作為「目標可達性」的存在證明、不適合直接套用為自家服務的容量假設。

策略

可重用的工程做法：

  1. 把賽事 schedule 灌進 capacity forecast：在事件已知的條件下、預先把 baseline 拉高、避免 AI 模型在零起跑時擴容。對應 EC2 Auto Scaling 的 scheduled scaling + predictive scaling 雙模。
  2. AI 模型輸入要包含領域訊號：通用 ML autoscaler 用 CPU / latency 預測、領域 autoscaler 還會用 賽事重要性、投注量歷史曲線、下注玩家集中度 等業務訊號。這層讓擴容時機從反應式變成預測式。
  3. 熱點服務獨立擴容、不是整體擴容：投注引擎跟結算引擎的峰值時間不一致（投注集中在賽前 + 比賽中、結算集中在賽後）、單獨擴容比整體擴容省 25%+ 成本。
  4. AWS Infrastructure Event Management 等廠商支援服務：在年度重大事件可以申請（World Cup、Olympic、Black Friday 等）、提供 pre-scaling 與專屬監控通道。這在 GCP / Azure 也有對等服務（GCP Customer Care Premium、Azure Event Management Support）。

跨平台等效：GCP GKE + Vertical Pod Autoscaler + 自家 ML 預測、Azure AKS + KEDA + Azure ML 預測、自建 Kubernetes + Karpenter + Prometheus 推導模型都可以實作同樣的「預測 + 擴容」模式。

下一步路由

引用源