從LINE刮刮卡淺談高流量負載服務架構設計 Julian Shen 

Julian Shen Dev Lead, LINE NOW Team Joined LINE from 2017, Major works: Backend engineer Dev Lead of LINE NOW Team @jlnshen julianshen 

QA Julian Hsueh -Min Yu-mei Alex Denny Shiang-Yu Deann Johnny Kay Ting-yu Team • 5 後端, 3 前端, 3 QA • 喜歡使用新武器 • Java/node.js/Typescript/Scala/Kotlin/Go • Spring/Finagle • Docker/K8S/Rancher • Mongo/Redis/Mysql/Kafka • Vue.js/Framework 7 • SOA/Micro services • 樂於接受挑戰與改變 • Running as a scrum team • 產品 • LINE NOW/Scratch card • LINE SPOT (Location based/O2O service platform) • 招募中喔 (都缺喔) John 

什麼是LINE刮刮卡? • 用於行銷活動的贈獎的一個新服務 • 透過這個遊戲, 使用者可以獲得 • 貼圖 • 折價券 • LINE Points • 可讓第三方服務介接 • 介面採用LIFF開發 (https://developers.line.me/en/docs/liff/o verview/ ) • 案例 • 2018 中秋貼圖活動 • 2019 過年, LINE 系列活動? 

來看看它是怎麼運作的 抽卡 發送卡片給 使用者 使用者打開 卡片頁面 使用者刮開 卡片 兌獎/發獎 第三方系統 發送卡片連 結給使用者 第三方系統 呼叫API抽卡 使用者打開 LINE LIFF的頁 面 刮開卡片的 同時也需要 把紀錄回傳 不能讓客人 有獎拿不到 呀！ 

可以怎麼設計? API WEB 發獎系統 API 使用者 活動服務 系統 刮刮卡系統 負責前端網頁 monolithic system • 資料庫讀取 • 這張卡可以得什麼 獎? • 資料庫寫入 • 刮卡軌跡 • 誰得獎了 • 發送獎品是在別的 系統 LIFF WebView Restful api LINE Profile API 驗證user token 

這有什麼難的? 會碰到什麼樣的挑戰嗎? 

哪些地方會有瓶頸? API WEB 發獎系統 API 使用者 活動服務 系統 刮刮卡系統 負責前端網頁 LIFF WebView Restful api LINE Profile API 驗證user token 1 2 3 1 進入流量 (發卡, 刮卡紀錄, 兌獎) 2 輸出流量 3 資料庫 外部依賴 • 每個節點(node)能夠服務的連線數有限 • 外部系統也可能承受不了高流量 • 資料庫寫入是不快的 

如果瞬間有大量流量湧入? • 為什麼會突然有大量流量湧入? • 促銷 (像是雙十一) • Banner 推廣 • 蓋版廣告 • 會發生什麼事? • 同時連線數增加, 如超過所能負荷的連線, 會導致前端呼叫API失敗 • 同時寫入資料庫次數增加, 大量的同時寫入可能導致資料庫效能低落, 進 而影響每個API請求的處理時間 • 對外部系統呼叫API次數增加 • 對外部系統連接的connection pool被用完 • 外部系統也可能被打趴 

對於這服務, 誰在貢獻流量 • 發卡API – 每張卡一次 (資料寫入) • 讀取卡片資訊API – 1~N (資料讀取) • 刮卡紀錄 – 每張卡約3~4 (資料寫入) • 兌獎 – 每張卡一次 (資料寫入) 

那我加開機器不就好了? 

API WEB 發獎系統 API 使用者 活動服務 系統 刮刮卡系統 負責前端網頁 LIFF WebView Restful api LINE Profile API 驗證user token API API API 可是瑞凡, 這邊還是瓶頸呀~~~~ (可能還死更快) WEB WEB 

我們實際怎麼做? 

LIFF Frontend Scratch API Reward agent 抽卡 取得卡片資訊 寫入抽卡資訊 Generator Meta DB CMS Kafka connect Operator Customer Care Admin tool HAProxy 活動服務 系統 CDN 使用者 LIFF WebView 刮卡, 兌獎 發獎系統 API LINE Profile API 發獎 記錄發獎資訊 記錄刮卡資訊 抄寫 Micro services scalable CMS API 

這樣做的好處是? • 使用微服務 • 各服務負載不同, 可以分別擴增 • 使用反向代理, CDN可減輕連線壓力 • 資料來自Redis, 相較於傳統資料庫來的快速 • 抽卡資訊不直接寫入資料庫, 降低IO的影響 • 大部分的資料寫入都是延後及非同步 • API呼叫的處理時間不受資料庫寫入效能影響 • 對外部系統的壓力可被控制 • Kafka只要沒掛, 萬一其他系統出問題, 該寫入的資料都還會在 • Redis, Kafka 可以處理大流量資訊 

系統是部署在K8S上 Easy to scale 

還是被打到了 orz 

事件 • Kafka 炸了 • 設定問題 • 低估刮卡log需求的容量 • Event的內容設計應盡可能精簡 • 蓋版廣告及人人有獎帶來瞬間且持續的大流量 • 7000+rps • 初期系統設計並不是考量人人有獎 • 過度低估CMS API的抗壓需求 Reward agent Meta DB Kafka connect CMS API 

壓力測試 • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 微服務架構帶來的測試挑戰 • 單一服務的壓測不難 • 不易估算單一服務應該承受的流量規格 • 端到端的測試牽涉到太多服務及不同路徑, 測試不易全面 • 需虛擬單一服務故障時整體的狀況, 以防雪崩 

今後的挑戰 

謝謝