Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Hiroaki Egashira

October 18, 2019
Tweet

More Decks by Hiroaki Egashira

Other Decks in Technology

Transcript

  1. WinTicketにおける
    リアルタイム性と⾼負荷を考慮した
    アーキテクチャ
    株式会社サイバーエージェント
    江頭 宏亮

    View full-size slide

  2. 江頭 宏亮 えがしら ひろあき
    • 2018年4⽉ 株式会社サイバーエージェント⼊社
    CATS(CyberAgent Advanced Technology Studio)

    • WinTicket - 公営競技事業
    バックエンド テックリード
    hiro
    _hiro

    View full-size slide

  3. 本⽇の内容
    • WinTicketとは
    • 全体アーキテクチャ
    • 情報のリアルタイム性の実現
    • 投票券の購⼊‧精算時の負荷対策

    View full-size slide

  4. WinTicketとは

    View full-size slide

  5. WinTicket
    • オンライン競輪投票サービス
    • ウェブとiOS‧Androidアプリを提供
    • いつでも投票券を購⼊可能
    • 全国43会場のライブ映像を配信
    • AbemaTVの競輪チャンネルと連動

    View full-size slide

  6. 全体アーキテクチャ

    View full-size slide

  7. 技術選定

    View full-size slide

  8. Kubernetes
    マイクロサービスアーキテクチャ
    • 36種類のマイクロサービスが稼働
    • ゲートウェイ パターン
    • アンバサダー パターン
    • オートスケール

    View full-size slide

  9. • 可⽤性の向上に貢献
    Outlier Detection, Circuit Breaking
    Load Balancing, Retry, etc
    • ロギングなどを任せることで ロジックの開発に集中
    Envoy
    サービスメッシュを構成

    View full-size slide

  10. Cloud Spanner
    ⽔平スケール可能なリレーショナル データベース

    View full-size slide

  11. • 選定理由

    ⾦銭の取引があるのでトランザクション必須

    購⼊できないと(ダウンタイムは)事業的損失が⼤きい

    レースの締切直前と結果確定直後に書き込み負荷が⼤きい
    • 性能(1インスタンスあたり)

    リード:最⼤10,000 QPS, ライト:最⼤2,000 QPS
    Cloud Spanner
    ⾼可⽤性 SLA . %

    View full-size slide

  12. リアルタイム性

    View full-size slide

  13. 最新の情報を
    すぐに届ける必要がある

    View full-size slide

  14. 競輪決済システムのプロキシではない

    View full-size slide

  15. 投票システムのプロキシではない
    購⼊‧払い戻しの全ての責任を負う
    • 競輪システムから取得できる情報は出⾛表とオッズと結果ぐらい
    • 取得できた情報をもとに販売可能な投票券と払い戻す投票券を判断
    • 競輪システムには投票券の販売状況を定期的に報告
    誤販売を防ぐために情報のリアルタイム性は重要

    View full-size slide

  16. リアルタイム性
    最新の情報をすぐにユーザーへ届ける必要がある
    • 変わりやすい‧すぐに届けたい情報

    オッズ、出⾛表、レース結果
    • 情報量が多い

    レース詳細情報を取得するAPIのレスポンスは約 KB

    View full-size slide

  17. Fastly
    Instant Purgeが決め⼿
    • ms以内にキャッシュをパージできる
    • レスポンスヘッダーにサロゲートキーを設定することで

    そのキー単位でパージできる
    • VarnishベースなのでVCLで設定できる
    • 導⼊した結果
    ⼿元の環境では 20KB超えAPIも20msほどのレイテンシに抑えられている
    データベースへの負荷も抑えられた

    View full-size slide

  18. singleflight
    関数の重複呼び出しを抑制するメカニズム
    • キャッシュミス時のオリジンアクセスの負荷を抑えられる
    • キーに対して同時に1つの実⾏しか⾏わない
    • 重複した関数呼び出しは最初の実⾏を待ち、その結果を返す
    • 時間的局所性がある場合に効果的

    View full-size slide

  19. 負荷がかかるタイミング
    • レース締め切り直前
    締め切りギリギリに購⼊が集中する
    • レースの結果確定直後
    結果確定後にすぐにユーザーへ払い戻しを⾏わないといけない
    最短で約20分おきにレースが発⾛する
    できるだけ早く払い戻し処理を完了させた⽅が良い

    View full-size slide

  20. 事業的な要件
    • 購⼊リクエスト 1,000 rps を処理
    • 3分以内に 30万ユーザーに払い戻し

    View full-size slide

  21. ⾼負荷
    購⼊は Spannerのスケールアウトで対応
    Spannerとsingleflightで問題なく捌けた

    View full-size slide

  22. Queue-Based Load Leveling
    払い戻しは キューイングしてワーカーで処理

    View full-size slide

  23. Cloud PubSub
    GCPのフルマネージド メッセージング ミドルウェア
    • Topic/Subscription
    • At least once 配信
    • Ack/Nackでリデリバリー可能

    View full-size slide

  24. Queue-Based Load Leveling
    メリット
    • ワーカーの数を調整することでDB負荷を抑えることができる
    • スケールアウト‧インが容易
    • エラーが発⽣してもNackを返すことでリデリバリーされ⽋損しない

    View full-size slide

  25. Queue-Based Load Leveling
    もしキューイングせずに処理すると…
    • DBなどへの負荷がスパイクして障害につがなるおそれがある
    • KubernetesはPodの再配置を⾃動的に⾏うので⻑時間の処理中にスケ
    ジューリングされると処理が中断され⽋損につながるおそれがある
    • Podで処理するとそのリソースが性能限界になりスケールしにくい

    View full-size slide

  26. Queue-Based Load Leveling
    負荷試験の結果
    • 1秒間に1,000ユーザー分 払い戻しできた

    → 3分間で18万ユーザーという結果に

    View full-size slide

  27. Queue-Based Load Leveling
    様々な処理で利⽤している
    • お知らせ送信(メール‧プッシュなど)
    • ユーザーステージの更新
    • ポイント精算 など…

    View full-size slide

  28. ありがとうございました

    View full-size slide