WinTicketにおける リアルタイム性と高負荷を考慮したアーキテクチャ/WinTicket Architecture

Transcript

1. WinTicketにおける リアルタイム性と⾼負荷を考慮した アーキテクチャ 株式会社サイバーエージェント 江頭 宏亮
2. 江頭 宏亮 えがしら ひろあき • 2018年4⽉ 株式会社サイバーエージェント⼊社 CATS(CyberAgent Advanced Technology Studio)
 • WinTicket - 公営競技事業 バックエンド テックリード hiro _hiro
3. 本⽇の内容 • WinTicketとは • 全体アーキテクチャ • 情報のリアルタイム性の実現 • 投票券の購⼊‧精算時の負荷対策
4. WinTicketとは
5. WinTicket • オンライン競輪投票サービス • ウェブとiOS‧Androidアプリを提供 • いつでも投票券を購⼊可能 • 全国43会場のライブ映像を配信 • AbemaTVの競輪チャンネルと連動
6. 全体アーキテクチャ
7. 技術選定
9. Kubernetes マイクロサービスアーキテクチャ • 36種類のマイクロサービスが稼働 • ゲートウェイ パターン • アンバサダー パターン • オートスケール
10. • 可⽤性の向上に貢献 Outlier Detection, Circuit Breaking Load Balancing, Retry, etc • ロギングなどを任せることで ロジックの開発に集中 Envoy サービスメッシュを構成
11. Cloud Spanner ⽔平スケール可能なリレーショナル データベース
12. • 選定理由
 ⾦銭の取引があるのでトランザクション必須
 購⼊できないと（ダウンタイムは）事業的損失が⼤きい
 レースの締切直前と結果確定直後に書き込み負荷が⼤きい • 性能（1インスタンスあたり）
 リード：最⼤10,000 QPS, ライト：最⼤2,000 QPS Cloud Spanner ⾼可⽤性 SLA . %
13. リアルタイム性
14. 最新の情報を すぐに届ける必要がある
15. 競輪決済システムのプロキシではない
16. 投票システムのプロキシではない 購⼊‧払い戻しの全ての責任を負う • 競輪システムから取得できる情報は出⾛表とオッズと結果ぐらい • 取得できた情報をもとに販売可能な投票券と払い戻す投票券を判断 • 競輪システムには投票券の販売状況を定期的に報告 誤販売を防ぐために情報のリアルタイム性は重要
17. リアルタイム性 最新の情報をすぐにユーザーへ届ける必要がある • 変わりやすい‧すぐに届けたい情報
 オッズ、出⾛表、レース結果 • 情報量が多い
 レース詳細情報を取得するAPIのレスポンスは約 KB
18. Fastly Instant Purgeが決め⼿ • ms以内にキャッシュをパージできる • レスポンスヘッダーにサロゲートキーを設定することで
 そのキー単位でパージできる • VarnishベースなのでVCLで設定できる • 導⼊した結果 ⼿元の環境では 20KB超えAPIも20msほどのレイテンシに抑えられている データベースへの負荷も抑えられた
19. singleflight 関数の重複呼び出しを抑制するメカニズム • キャッシュミス時のオリジンアクセスの負荷を抑えられる • キーに対して同時に１つの実⾏しか⾏わない • 重複した関数呼び出しは最初の実⾏を待ち、その結果を返す • 時間的局所性がある場合に効果的
20. ⾼負荷
21. 負荷がかかるタイミング • レース締め切り直前 締め切りギリギリに購⼊が集中する • レースの結果確定直後 結果確定後にすぐにユーザーへ払い戻しを⾏わないといけない 最短で約20分おきにレースが発⾛する できるだけ早く払い戻し処理を完了させた⽅が良い
22. 事業的な要件 • 購⼊リクエスト 1,000 rps を処理 • 3分以内に 30万ユーザーに払い戻し
23. ⾼負荷 購⼊は Spannerのスケールアウトで対応 Spannerとsingleflightで問題なく捌けた
24. Queue-Based Load Leveling 払い戻しは キューイングしてワーカーで処理
25. Cloud PubSub GCPのフルマネージド メッセージング ミドルウェア • Topic/Subscription • At least once 配信 • Ack/Nackでリデリバリー可能
26. Queue-Based Load Leveling メリット • ワーカーの数を調整することでDB負荷を抑えることができる • スケールアウト‧インが容易 • エラーが発⽣してもNackを返すことでリデリバリーされ⽋損しない
27. Queue-Based Load Leveling もしキューイングせずに処理すると… • DBなどへの負荷がスパイクして障害につがなるおそれがある • KubernetesはPodの再配置を⾃動的に⾏うので⻑時間の処理中にスケ ジューリングされると処理が中断され⽋損につながるおそれがある • Podで処理するとそのリソースが性能限界になりスケールしにくい
28. Queue-Based Load Leveling 負荷試験の結果 • 1秒間に1,000ユーザー分 払い戻しできた
 → 3分間で18万ユーザーという結果に
29. Queue-Based Load Leveling 様々な処理で利⽤している • お知らせ送信（メール‧プッシュなど） • ユーザーステージの更新 • ポイント精算 など…
30. ありがとうございました