Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
How to build high load balance architect in LINE NOW
Search
LINE Developers
PRO
March 29, 2019
Technology
0
7.3k
How to build high load balance architect in LINE NOW
LINE Developer Meetup 開發者小聚系列活動 #7
https://linegroup.kktix.cc/events/20190329
LINE Developers
PRO
March 29, 2019
Tweet
Share
More Decks by LINE Developers
See All by LINE Developers
LINEスタンプのSREing事例集:大きなスパイクアクセスを捌くためのSREing
line_developers
PRO
1
1.3k
Java 21 Overview
line_developers
PRO
6
770
Code Review Challenge: An example of a solution
line_developers
PRO
1
800
KARTEのAPIサーバ化
line_developers
PRO
1
360
著作権とは何か?〜初歩的概念から権利利用法、侵害要件まで
line_developers
PRO
5
1.7k
生成AIと著作権 〜生成AIによって生じる著作権関連の課題と対処
line_developers
PRO
3
1.7k
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
line_developers
PRO
9
2.3k
A/B Testing at LINE NEWS
line_developers
PRO
2
590
LINEのサポートバージョンの考え方
line_developers
PRO
2
760
Other Decks in Technology
See All in Technology
生成AI・LLM時代における 機械学習エンジニアとしてのキャリア戦略・開発戦略 / my-career-and-development-strategies-for-ml-engineer-2024
yuya4
4
880
AFTを運用していたらAWS Configの課金が急増していた件
msato
0
100
技術広報として2023年度に頑張ったこと / What we did well in FY2023 as a DevRel
pauli
5
490
MongoDB Atlas Vectorsearchではじめる生成AIアプリ開発
chie8842
3
510
KTC_DBRE.pdf
_awache
1
290
匠MethodとRDRAとICONIXとDDDで実現する一気通貫オブジェクト指向開発
haru860
4
2.1k
データマネジメントを支える武器としてのメタデータ管理
10xinc
2
900
Code Smells @Voxxed Bucharest 24
victorrentea
0
110
初心者が行く!サーバレスWebアプリ開発の道
nagaharutogawa
0
450
大規模なアジャイル開発の現場と技術負債 / Technical Debt
yoshiitaka
21
4.1k
データ化エンジニアとしての1年を振り返る
sansantech
PRO
3
260
LLM + RAG を使った SORACOM Support Bot の裏側の歴史
soracom
PRO
1
640
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
28
46k
No one is an island. Learnings from fostering a developers community.
thoeni
14
2k
Producing Creativity
orderedlist
PRO
335
39k
Design by the Numbers
sachag
274
18k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
153
14k
How To Stay Up To Date on Web Technology
chriscoyier
781
250k
Bash Introduction
62gerente
604
210k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
39
4.3k
Rails Girls Zürich Keynote
gr2m
91
13k
Scaling GitHub
holman
456
140k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
657
120k
Faster Mobile Websites
deanohume
296
30k
Transcript
從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
壓力測試 • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 微服務架構帶來的測試挑戰 •
單一服務的壓測不難 • 不易估算單一服務應該承受的流量規格 • 端到端的測試牽涉到太多服務及不同路徑, 測試不易全面 • 需虛擬單一服務故障時整體的狀況, 以防雪崩
今後的挑戰
謝謝