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
WinTicketにおける リアルタイム性と高負荷を考慮したアーキテクチャ/WinTicket...
Search
Hiroaki Egashira
October 18, 2019
Technology
4
3k
WinTicketにおける リアルタイム性と高負荷を考慮したアーキテクチャ/WinTicket Architecture
Hiroaki Egashira
October 18, 2019
Tweet
Share
More Decks by Hiroaki Egashira
See All by Hiroaki Egashira
レコメンドへの大規模アクセスを支えるGo製サーバーの裏側
_hiro511
7
3.5k
WinTicketにおけるライブ配信システムの実現
_hiro511
2
740
MicroServices and MonoRepo
_hiro511
2
1.2k
Other Decks in Technology
See All in Technology
急拡大する開発組織を支えるナレッジワークの E2E テスト基盤
kworkdev
PRO
1
490
「巨人の肩の上」で自作ライブラリを作る技術 / pyconjp2024
upura
2
290
オブザーバビリティの探求 〜性能劣化から始まった旅路〜
sansantech
PRO
3
360
LLMマルチエージェントのフローエンジニアリングを支えるLLM Ops
pharma_x_tech
4
1k
静的サイトのCI/CDでも侮るなかれ!Docs as Codeに沿ったセキュアな開発プロセスの実践/secure-docsascode-cicd-for-static-sites
mhrtech
11
2k
ダッシュボードが“使われる”ようにするための Tips を時間の限り紹介!
hanon52_
1
140
QAに対する超個人的な解釈 / Personal Take on QA
toma_sm
1
180
LLMの効率化を支えるアルゴリズム
taturabe
16
4.1k
What’s new in Keycloak, the open source IAM?
ahus1
1
120
XP matsuri 2024 - 銀河英雄伝説に学ぶ
kawaguti
PRO
2
260
不感対策ソリューション
jtes
0
220
コンポーネントテストの手法と その効果を考える
yotahada3
8
1.1k
Featured
See All Featured
Docker and Python
trallard
40
3k
The World Runs on Bad Software
bkeepers
PRO
64
11k
Why Our Code Smells
bkeepers
PRO
334
57k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.8k
We Have a Design System, Now What?
morganepeng
48
7.1k
Mobile First: as difficult as doing things right
swwweet
221
8.8k
Unsuck your backbone
ammeep
667
57k
How to name files
jennybc
75
98k
Practical Orchestrator
shlominoach
185
10k
Being A Developer After 40
akosma
84
590k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
30
2.6k
Producing Creativity
orderedlist
PRO
340
39k
Transcript
WinTicketにおける リアルタイム性と⾼負荷を考慮した アーキテクチャ 株式会社サイバーエージェント 江頭 宏亮
江頭 宏亮 えがしら ひろあき • 2018年4⽉ 株式会社サイバーエージェント⼊社 CATS(CyberAgent Advanced Technology
Studio) • WinTicket - 公営競技事業 バックエンド テックリード hiro _hiro
本⽇の内容 • WinTicketとは • 全体アーキテクチャ • 情報のリアルタイム性の実現 • 投票券の購⼊‧精算時の負荷対策
WinTicketとは
WinTicket • オンライン競輪投票サービス • ウェブとiOS‧Androidアプリを提供 • いつでも投票券を購⼊可能 • 全国43会場のライブ映像を配信 •
AbemaTVの競輪チャンネルと連動
全体アーキテクチャ
技術選定
None
Kubernetes マイクロサービスアーキテクチャ • 36種類のマイクロサービスが稼働 • ゲートウェイ パターン • アンバサダー パターン
• オートスケール
• 可⽤性の向上に貢献 Outlier Detection, Circuit Breaking Load Balancing, Retry, etc
• ロギングなどを任せることで ロジックの開発に集中 Envoy サービスメッシュを構成
Cloud Spanner ⽔平スケール可能なリレーショナル データベース
• 選定理由 ⾦銭の取引があるのでトランザクション必須 購⼊できないと(ダウンタイムは)事業的損失が⼤きい レースの締切直前と結果確定直後に書き込み負荷が⼤きい • 性能(1インスタンスあたり) リード:最⼤10,000 QPS, ライト:最⼤2,000
QPS Cloud Spanner ⾼可⽤性 SLA . %
リアルタイム性
最新の情報を すぐに届ける必要がある
競輪決済システムのプロキシではない
投票システムのプロキシではない 購⼊‧払い戻しの全ての責任を負う • 競輪システムから取得できる情報は出⾛表とオッズと結果ぐらい • 取得できた情報をもとに販売可能な投票券と払い戻す投票券を判断 • 競輪システムには投票券の販売状況を定期的に報告 誤販売を防ぐために情報のリアルタイム性は重要
リアルタイム性 最新の情報をすぐにユーザーへ届ける必要がある • 変わりやすい‧すぐに届けたい情報 オッズ、出⾛表、レース結果 • 情報量が多い レース詳細情報を取得するAPIのレスポンスは約 KB
Fastly Instant Purgeが決め⼿ • ms以内にキャッシュをパージできる • レスポンスヘッダーにサロゲートキーを設定することで そのキー単位でパージできる • VarnishベースなのでVCLで設定できる
• 導⼊した結果 ⼿元の環境では 20KB超えAPIも20msほどのレイテンシに抑えられている データベースへの負荷も抑えられた
singleflight 関数の重複呼び出しを抑制するメカニズム • キャッシュミス時のオリジンアクセスの負荷を抑えられる • キーに対して同時に1つの実⾏しか⾏わない • 重複した関数呼び出しは最初の実⾏を待ち、その結果を返す • 時間的局所性がある場合に効果的
⾼負荷
負荷がかかるタイミング • レース締め切り直前 締め切りギリギリに購⼊が集中する • レースの結果確定直後 結果確定後にすぐにユーザーへ払い戻しを⾏わないといけない 最短で約20分おきにレースが発⾛する できるだけ早く払い戻し処理を完了させた⽅が良い
事業的な要件 • 購⼊リクエスト 1,000 rps を処理 • 3分以内に 30万ユーザーに払い戻し
⾼負荷 購⼊は Spannerのスケールアウトで対応 Spannerとsingleflightで問題なく捌けた
Queue-Based Load Leveling 払い戻しは キューイングしてワーカーで処理
Cloud PubSub GCPのフルマネージド メッセージング ミドルウェア • Topic/Subscription • At least
once 配信 • Ack/Nackでリデリバリー可能
Queue-Based Load Leveling メリット • ワーカーの数を調整することでDB負荷を抑えることができる • スケールアウト‧インが容易 • エラーが発⽣してもNackを返すことでリデリバリーされ⽋損しない
Queue-Based Load Leveling もしキューイングせずに処理すると… • DBなどへの負荷がスパイクして障害につがなるおそれがある • KubernetesはPodの再配置を⾃動的に⾏うので⻑時間の処理中にスケ ジューリングされると処理が中断され⽋損につながるおそれがある •
Podで処理するとそのリソースが性能限界になりスケールしにくい
Queue-Based Load Leveling 負荷試験の結果 • 1秒間に1,000ユーザー分 払い戻しできた → 3分間で18万ユーザーという結果に
Queue-Based Load Leveling 様々な処理で利⽤している • お知らせ送信(メール‧プッシュなど) • ユーザーステージの更新 • ポイント精算
など…
ありがとうございました