雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
?
31 likes?11,092 views
拓元售票利用础奥厂的架构，在十二分鐘内，完成张惠妹十场小巨蛋、十二万张票的售票服务。事前做了哪些準备及测试？架构上又如何调整？
雲端系統對爆量的測試與準備 - 以張惠妹秒殺售票為例
- 4. 我們的發展歷史 拓連 成立於2000 網站資料庫專案製作 售票 系統 元氣娛樂 ibon售票系統供應商 授權 拓元 成立於2013 2003開始服務 2014成為子公司 以技術為股份 法人股東 增資
- 7. Ver. 1 - 2003 Internet Users UI Database Web Application Database Overloaded
- 8. Ver. 2 - 2007 UI Database API Service UI Web Application Internet Users Web Server Overloaded 2008年，台灣7-Eleven在近5,000 家店內，建置了ibon機台，成為當 時國內數量最大的標準化末端設備
- 9. 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
- 10. 有些變化發生了 雲端服務成熟 行動裝置成長 Affordable large-size structure Kiosks to mobile phones
- 11. Ver. 4 - 2014 Internet Users X10,000 UI Database ? UI Web Application 120,000 張票 在12 分鐘完售
- 13. 我們的目標 ? 售票越快越好，但是要保留消費者選擇的可能性 ? 保護主要資料庫 ? 讓UI伺服器可以無限制(?)擴充 ? 所有伺服器的資訊保持同步 ? 做好即時備援方案
- 14. tixCraft System - UI Amazon S3 Amazon Route 53 Elastic Load Balancing DynamoDB Amazon EC2 UI Servers Auto Scaling CloudFron t Static Files
- 15. tixCraft System - API DynamoDB Amazon EC2 API Servers Auto Scaling Elastic Load Balancing tixCraft Ticketing Server Ticketing database
- 17. 售票的任務 ? 爆炸性的人流 ? 自動擴展來不及，因此需要在開賣前估算出量 ? 選區選位的即時性 ? 目前仍有30~60秒的不完全同步，將利用其他服務 改善 ? 金流與備案 ? 線上刷卡是否撐得住? 備案為何?
- 18. 壓力測試 ? 模擬客戶數 ? 以50,000個同時要求為單位 ? 模擬方式：開多台機器同步 送出多個要求 ? AWS限制 ? EC2 instances:申請10,000 ? DynamoDB: Throughput拉 至r/w各200,000
- 19. 檢查清單 ? 依使用者操作流程 ? 依資料進入流程 ? 依各連外接入點 ? 障礙與備案討論 ? UI→監控、加機器 ? DynamoDB→拉高Throughput、table分配 ? API→自動擴展、死命加 ? Payment ? 收單刷卡掛點 - 批次轉虛擬帳號+公告 ? 無法進入刷卡頁 - 批次轉虛擬帳號+公告 ? AWS payment掛點 - 替換機器+人工對帳 ? 虛擬帳號自動對帳異常 - 人工對帳 ? 其他伺服器異常→切換備援機 障礙發生
- 20. 實際狀況 ? 開賣前10 min – 檢視機器數 ? 開賣前 1 min – 觀察session數 ? 開賣後 3 min – 發現結帳問題 ? 開賣後 10 min – 處理 ? 開賣後 15 min – 完售與公告
- 21. 金流狀況與改善方向 ? 拓元訂單產生速度 ? 每秒約200~300筆，最快每秒500+筆 ? 銀行收單速度 ? 一般銀行最多到每秒30筆 ? 經改善後，目前收單行可拉到每秒75筆 ? NCCC理論上可以到每秒100筆，但未經驗證 ? 改善方法 ? 網站前端拉長導至收單行的時間 ? 利用ATM虛擬帳號收單，限制繳款時間在1小時內