Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
雲端系統對爆量的測試與準備 -
以張惠妹秒殺售票為例
拓元售票
邱光宗
台灣第一的售票系統
運動 演唱會 影展
拓元售票與其子公司,元氣娛樂
自2012年起,每年銷售兩百萬張票
我們的發展歷史
拓連
成立於2000
網站資料庫專案製作
售票
系統
元氣娛樂
ibon售票系統供應商
授權 拓元
成立於2013
2003開始服務
2014成為子公司
以技術為股份
法人股東
增資
售票方式的變化
1996
年代售票系統啟用,開創網路/端點售票型態
10,000張/4~6小時
2011
ibon售票系統團隊初試啼聲,完成演唱會秒殺任務
100,000張/1小時
2014
智慧型手機使用率超越個人電腦後,售票系統的下一步?
...
Ver. 1 - 2003
Internet
Users
UI
Database
Web
Application
Database
Overloaded
Ver. 2 - 2007
UI
Database
API
Service
UI
Web
Application
Internet
Users
Web Server
Overloaded
2008年,台灣7-Eleven在近5,000
家店內,...
Ver. 3 - 2009
UI
Database
API
Service
UI
Web
Application
Internet
Users
全省5,000
家7-Eleven
店內
ibon
Intranet
In
CVS
POS
Over...
有些變化發生了
雲端服務成熟 行動裝置成長
Affordable large-size
structure
Kiosks to mobile
phones
Ver. 4 - 2014
Internet
Users
X10,000
UI
Database
?
UI
Web
Application
120,000 張票
在12 分鐘完售
我們的目標
• 售票越快越好,但是要保留消費者選擇的可能性
• 保護主要資料庫
• 讓UI伺服器可以無限制(?)擴充
• 所有伺服器的資訊保持同步
• 做好即時備援方案
tixCraft System - UI
Amazon S3
Amazon
Route 53
Elastic Load
Balancing
DynamoDB
Amazon EC2
UI Servers
Auto Scaling
CloudFro...
tixCraft System - API
DynamoDB
Amazon EC2
API Servers
Auto Scaling
Elastic Load
Balancing
tixCraft
Ticketing
Server
Ticket...
售票的任務
• 爆炸性的人流
▫ 自動擴展來不及,因此需要在開賣前估算出量
• 選區選位的即時性
▫ 目前仍有30~60秒的不完全同步,將利用其他服務
改善
• 金流與備案
▫ 線上刷卡是否撐得住? 備案為何?
壓力測試
• 模擬客戶數
▫ 以50,000個同時要求為單位
▫ 模擬方式:開多台機器同步
送出多個要求
• AWS限制
▫ EC2 instances:申請10,000
▫ DynamoDB: Throughput拉
至r/w各200,000
檢查清單
• 依使用者操作流程
• 依資料進入流程
• 依各連外接入點
• 障礙與備案討論
▫ UI→監控、加機器
▫ DynamoDB→拉高Throughput、table分配
▫ API→自動擴展、死命加
▫ Payment
 收單刷卡掛...
實際狀況
• 開賣前10 min – 檢視機器數
• 開賣前 1 min – 觀察session數
• 開賣後 3 min – 發現結帳問題
• 開賣後 10 min – 處理
• 開賣後 15 min – 完售與公告
金流狀況與改善方向
• 拓元訂單產生速度
▫ 每秒約200~300筆,最快每秒500+筆
• 銀行收單速度
▫ 一般銀行最多到每秒30筆
▫ 經改善後,目前收單行可拉到每秒75筆
▫ NCCC理論上可以到每秒100筆,但未經驗證
• 改善方法
...
拓元售票
邱光宗
ktchiu@tixCraft.com
雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
Prochain SlideShare
Chargement dans…5
×

雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例

10 478 vues

Publié le

拓元售票利用AWS的架構,在十二分鐘內,完成張惠妹十場小巨蛋、十二萬張票的售票服務。事前做了哪些準備及測試?架構上又如何調整?

Publié dans : Internet
  • Soyez le premier à commenter

雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例

  1. 1. 雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例 拓元售票 邱光宗
  2. 2. 台灣第一的售票系統 運動 演唱會 影展 拓元售票與其子公司,元氣娛樂 自2012年起,每年銷售兩百萬張票
  3. 3. 我們的發展歷史 拓連 成立於2000 網站資料庫專案製作 售票 系統 元氣娛樂 ibon售票系統供應商 授權 拓元 成立於2013 2003開始服務 2014成為子公司 以技術為股份 法人股東 增資
  4. 4. 售票方式的變化 1996 年代售票系統啟用,開創網路/端點售票型態 10,000張/4~6小時 2011 ibon售票系統團隊初試啼聲,完成演唱會秒殺任務 100,000張/1小時 2014 智慧型手機使用率超越個人電腦後,售票系統的下一步? 100,000張/10分鐘
  5. 5. Ver. 1 - 2003 Internet Users UI Database Web Application Database Overloaded
  6. 6. Ver. 2 - 2007 UI Database API Service UI Web Application Internet Users Web Server Overloaded 2008年,台灣7-Eleven在近5,000 家店內,建置了ibon機台,成為當 時國內數量最大的標準化末端設備
  7. 7. Ver. 3 - 2009 UI Database API Service UI Web Application Internet Users 全省5,000 家7-Eleven 店內 ibon Intranet In CVS POS Overloaded Customers Queue in Stores
  8. 8. 有些變化發生了 雲端服務成熟 行動裝置成長 Affordable large-size structure Kiosks to mobile phones
  9. 9. Ver. 4 - 2014 Internet Users X10,000 UI Database ? UI Web Application 120,000 張票 在12 分鐘完售
  10. 10. 我們的目標 • 售票越快越好,但是要保留消費者選擇的可能性 • 保護主要資料庫 • 讓UI伺服器可以無限制(?)擴充 • 所有伺服器的資訊保持同步 • 做好即時備援方案
  11. 11. tixCraft System - UI Amazon S3 Amazon Route 53 Elastic Load Balancing DynamoDB Amazon EC2 UI Servers Auto Scaling CloudFron t Static Files
  12. 12. tixCraft System - API DynamoDB Amazon EC2 API Servers Auto Scaling Elastic Load Balancing tixCraft Ticketing Server Ticketing database
  13. 13. 售票的任務 • 爆炸性的人流 ▫ 自動擴展來不及,因此需要在開賣前估算出量 • 選區選位的即時性 ▫ 目前仍有30~60秒的不完全同步,將利用其他服務 改善 • 金流與備案 ▫ 線上刷卡是否撐得住? 備案為何?
  14. 14. 壓力測試 • 模擬客戶數 ▫ 以50,000個同時要求為單位 ▫ 模擬方式:開多台機器同步 送出多個要求 • AWS限制 ▫ EC2 instances:申請10,000 ▫ DynamoDB: Throughput拉 至r/w各200,000
  15. 15. 檢查清單 • 依使用者操作流程 • 依資料進入流程 • 依各連外接入點 • 障礙與備案討論 ▫ UI→監控、加機器 ▫ DynamoDB→拉高Throughput、table分配 ▫ API→自動擴展、死命加 ▫ Payment  收單刷卡掛點 - 批次轉虛擬帳號+公告  無法進入刷卡頁 - 批次轉虛擬帳號+公告  AWS payment掛點 - 替換機器+人工對帳  虛擬帳號自動對帳異常 - 人工對帳 ▫ 其他伺服器異常→切換備援機 障礙發生
  16. 16. 實際狀況 • 開賣前10 min – 檢視機器數 • 開賣前 1 min – 觀察session數 • 開賣後 3 min – 發現結帳問題 • 開賣後 10 min – 處理 • 開賣後 15 min – 完售與公告
  17. 17. 金流狀況與改善方向 • 拓元訂單產生速度 ▫ 每秒約200~300筆,最快每秒500+筆 • 銀行收單速度 ▫ 一般銀行最多到每秒30筆 ▫ 經改善後,目前收單行可拉到每秒75筆 ▫ NCCC理論上可以到每秒100筆,但未經驗證 • 改善方法 ▫ 網站前端拉長導至收單行的時間 ▫ 利用ATM虛擬帳號收單,限制繳款時間在1小時內
  18. 18. 拓元售票 邱光宗 ktchiu@tixCraft.com

×