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.5k
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
550
著作権とは何か?〜初歩的概念から権利利用法、侵害要件まで
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
S3アクセス制御の設計ポイント
tommy0124
3
200
Snowflake Intelligence × Document AIで“使いにくいデータ”を“使えるデータ”に
kevinrobot34
1
110
バイブスに「型」を!Kent Beckに学ぶ、AI時代のテスト駆動開発
amixedcolor
2
580
AI時代を生き抜くエンジニアキャリアの築き方 (AI-Native 時代、エンジニアという道は 「最大の挑戦の場」となる) / Building an Engineering Career to Thrive in the Age of AI (In the AI-Native Era, the Path of Engineering Becomes the Ultimate Arena of Challenge)
jeongjaesoon
0
240
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
460
MagicPod導入から半年、オープンロジQAチームで実際にやったこと
tjoko
0
110
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
110
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
260
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
1.1k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
10
75k
「Linux」という言葉が指すもの
sat
PRO
4
140
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
190
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How to train your dragon (web standard)
notwaldorf
96
6.2k
Designing Experiences People Love
moore
142
24k
Statistics for Hackers
jakevdp
799
220k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Embracing the Ebb and Flow
colly
87
4.8k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
850
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
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
壓力測試 • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 壓力測試很重要!!!! • 微服務架構帶來的測試挑戰 •
單一服務的壓測不難 • 不易估算單一服務應該承受的流量規格 • 端到端的測試牽涉到太多服務及不同路徑, 測試不易全面 • 需虛擬單一服務故障時整體的狀況, 以防雪崩
今後的挑戰
謝謝