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
3.4k
WinTicketにおける リアルタイム性と高負荷を考慮したアーキテクチャ/WinTicket Architecture
Hiroaki Egashira
October 18, 2019
Tweet
Share
More Decks by Hiroaki Egashira
See All by Hiroaki Egashira
レコメンドへの大規模アクセスを支えるGo製サーバーの裏側
_hiro511
7
3.7k
WinTicketにおけるライブ配信システムの実現
_hiro511
2
820
MicroServices and MonoRepo
_hiro511
2
1.3k
Other Decks in Technology
See All in Technology
Backlog ユーザー棚卸しRTA、多分これが一番早いと思います
__allllllllez__
1
120
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
950
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
420
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
120
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
250
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
410
論文紹介:LLMDet (CVPR2025 Highlight)
tattaka
0
290
OPENLOGI Company Profile for engineer
hr01
1
33k
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
170
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
150
Tech-Verse 2025 Global CTO Session
lycorptech_jp
PRO
0
1.5k
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
770
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
680
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Done Done
chrislema
184
16k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Bash Introduction
62gerente
614
210k
A Tale of Four Properties
chriscoyier
160
23k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
810
Fireside Chat
paigeccino
37
3.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
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 様々な処理で利⽤している • お知らせ送信(メール‧プッシュなど) • ユーザーステージの更新 • ポイント精算
など…
ありがとうございました