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 LIN...
Search
LINE Developers
March 29, 2019
Technology
0
7.6k
How to build high load balance architect in LINE NOW
LINE Developer Meetup 開發者小聚系列活動 #7
https://linegroup.kktix.cc/events/20190329
LINE Developers
March 29, 2019
Tweet
Share
More Decks by LINE Developers
See All by LINE Developers
LINEスタンプのSREing事例集:大きなスパイクアクセスを捌くためのSREing
line_developers
3
2.3k
Java 21 Overview
line_developers
6
1.2k
Code Review Challenge: An example of a solution
line_developers
1
1.4k
KARTEのAPIサーバ化
line_developers
1
560
著作権とは何か?〜初歩的概念から権利利用法、侵害要件まで
line_developers
5
2.2k
生成AIと著作権 〜生成AIによって生じる著作権関連の課題と対処
line_developers
3
2.2k
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
line_developers
9
3.6k
A/B Testing at LINE NEWS
line_developers
3
1k
LINEのサポートバージョンの考え方
line_developers
2
1.3k
Other Decks in Technology
See All in Technology
AIAgentの限界を超え、 現場を動かすWorkflowAgentの設計と実践
miyatakoji
1
170
カンファレンスに託児サポートがあるということ / Having Childcare Support at Conferences
nobu09
1
530
AIツールでどこまでデザインを忠実に実装できるのか
oikon48
6
3.3k
後進育成のしくじり〜任せるスキルとリーダーシップの両立〜
matsu0228
7
3.3k
"プロポーザルってなんか怖そう"という境界を超えてみた@TSUDOI by giftee Tech #1
shilo113
0
180
これがLambdaレス時代のChatOpsだ!実例で学ぶAmazon Q Developerカスタムアクション活用法
iwamot
PRO
6
1k
Performance Insights 廃止から Database Insights 利用へ/transition-from-performance-insights-to-database-insights
emiki
0
240
Simplifying Cloud Native app testing across environments with Dapr and Microcks
salaboy
0
140
社内お問い合わせBotの仕組みと学び
nish01
1
580
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing Hiroshima 2025 Edition
tomzoh
0
130
コンテキストエンジニアリング入門〜AI Coding Agent作りで学ぶ文脈設計〜
kworkdev
PRO
1
490
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
6
1.1k
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Typedesign – Prime Four
hannesfritz
42
2.8k
Become a Pro
speakerdeck
PRO
29
5.5k
Why Our Code Smells
bkeepers
PRO
339
57k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
900
Side Projects
sachag
455
43k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
114
20k
Statistics for Hackers
jakevdp
799
220k
Context Engineering - Making Every Token Count
addyosmani
6
240
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
壓力測試 • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 微服務架構帶來的測試挑戰 •
單一服務的壓測不難 • 不易估算單一服務應該承受的流量規格 • 端到端的測試牽涉到太多服務及不同路徑, 測試不易全面 • 需虛擬單一服務故障時整體的狀況, 以防雪崩
今後的挑戰
謝謝