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

ゲーム業界におけるTiDBの有効活用、導入事例のご紹介 - TiDB User Day 202...

ゲーム業界におけるTiDBの有効活用、導入事例のご紹介 - TiDB User Day 2022 セッション

ユーザ動向の分析が昨今重要になっているゲームデータに対して、TiDBが、どのようにリアルタイムで情報を取得し、かつデータ分析を実現しているのかについて紹介します。すでにTiDBを導入されている複数社のゲーム会社様の事例を交え、大規模なキャンペーン、テレビCM、時限式のイベントなどによるデータベースへの高負荷なトラフィックへの解決策など、具体的に解説します。

アーカイブ動画:https://youtu.be/USajHzx1bJ8

PingCAP-Japan

July 13, 2022
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

Transcript

  1. TiDBで何を解決するのか For Game
 ゲーム開発の大きな悩み
 ・ 想定以上のユーザが来た
 ・ DBが減らせない
 ・ どのクエリーが問題なのか分からない


    ・ プライマリーDBがダウンで大規模障害
 ・ 急なコラボイベントで緊急対応 夜眠たい・・・
 インフラ・アプリ
 プロデューサー
 ・ 想定以上のユーザ来たら機会損失に・・・
 ・ インフラコストを抑えられないのか
 ・ ノーメンテナンスで稼働できないのか
 ゲーム開発に専念させたい
 もっと収益体質にしたい

  2. TiDBで何を解決するのか For Game
 の魅力
 高負荷に強い 
 自動シャーディング機能
 稼働率99.99%
 レプリカ数変更可能
 原因調査が容易に


    クエリのリアルタイムチェック
 運用の自動化と導入のしやすさ
 リアルタイムランキングが可能に
 HTAPでリアルタイム集計
 既存プログラムとの相性抜群
 MySQLプロトコルの利用

  3. TiDB Cloudで採用している分散型データベースTiDB
 だからこそ実現できる柔軟なリソース設計
 
 ・ 役割に応じたクラスターを採用 
 - ヘッド領域(クエリ解析)とデータ領域(データ保管場所)を分ける事により柔軟なリソース追加設計を実現 


    ・ 各TiKVに別々のデータを分散配置する設計 
 - 各ノードが書き込みをパラレルで実施できるため、 驚異的な書き込みスケール を実現
 - Raftアルゴリズムにより耐障害性の向上デフォルトで1台の故障まで担保 ※変更は可能 
  
 TiDB
 TiDB
 TiKV
 TiKV
 TiKV
 データ領域
 ヘッド領域
 オンラインスケールアウト 
 オンラインスケールアウト 
 トランザクションの増加
 容量の増加
 TiDBで何を解決するのか For Game

  4. TiDBで何を解決するのか For Game
 企画段 階
 コンセプト作成
 
 ・ ジャンルやストーリーなど 


    含めたモック作成 
 ・ ビジネスモデル作成 
 ゲームデザイン
 ・ ストーリー
 ・ グラフィック
 エンジニアリング ・ コーディング
 ・ インフラ設計
 開発
 段階
 最終
 段階
 リリース
 アジャイル
 承認
 事業の承認
 
 ・ 予算許可
 マーケティング
 ・ 広告
 ・ メディア露出
 QA(品質管理)
 ・ デバック
 ・ 負荷テスト
 ・ βテスト
 監視
 ・ コミュニティ監視
 ・ 負荷監視
 サイジング
 ・ スケールイン/アウト 
 ゲーム開発にフィットするポイント

  5. TiDBで何を解決するのか For Game
 エンジニアリング
 インフラ設計
 開発
 段階
 最終
 段階
 リリース


    ユーザ側でやる事は実はこれだけ アジャイル
 QA(品質管理)
 負荷テスト
 監視
 負荷監視
 MySQLプロトコルで実装 
 TiFlash導入の可否
 Dashboardでクエリ分析/カラム負荷の確認 
 Webコンソールでスケールアウト/イン対応 
 サイジング
 スケールイン/アウト 
 TiDB Cloudからのメールの受信 
 フルマネージドだからできる超簡単運用
 TiDBだからこそできる最高の運用の手離れ
 上記以外は、PingCAP運用で安心!!

  6. TiDBで何を解決するのか For Game
 - Analytics処理の有無 
 AnalyticsとトランザクションをTiDBプラットフォームで利用可能 
 コマンド一つで連携、構築可能 


    必要なテーブル単位でレプ リケート指定可能 カラム型配置 RowData RowData RowData RowData ロー型配置 すべてリアルタイムデータ 利用 ワンコマンドでカラム型へ同期可能、高速な分析クエリのレスポンスへ
 シナリオ1:APのみ検索
 TiDB
 TiFlash
 シナリオ2:TPのみ検索 
 TiDB
 TiKV
 シナリオ3:TP+AP検索
 TiDB
 TiKV
 TiFlash
 TiDBがクエリを自動判別し適切なストーレージノードを選択

  7. TiDBで何を解決するのか For Game
 最終
 段階
 QA(品質管理)
 負荷テスト
 運用で大活躍間違いない
 実行クエリのリスト化から全体的に遅いクエリを調査可能に
 ステートメント一覧


    標準出力項目
 トータル実行時間、平均レイテンシー、実行回数 
 インデックスの貼り忘れを見つけたり 
 マイページなどでループしすぎのクエリを見つけたりが可能に 

  8. TiDBで何を解決するのか For Game
 オンラインでスケールイン/アウト
 アジャイル
 サイジング
 スケールイン/アウト 
 時間
 QPS


    TiDB Nodes
 TiKV Nodes
 01:00
 37416
 2
 3
 08:00
 299328
 14
 3
 12:00
 449000
 20
 3
 13:00
 411576
 19
 3
 23:00
 37416
 2
 3
 常にアクセス量が一緒ではないケースに強いTiDB
 容量は変わらないけれどもクエリ量が増えたケース
 

  9. PDによる運用の自動化
 データの偏りや負荷を監視しルールに乗っ取り自動負荷分散を実施
 PDによるスケジューラー 例) 
 
 アクセス先の偏りを調整 
 balance-leader-scheduler 


    ◦ Balances the distribution of region leaders 
 データの偏りを調整 
 balance-region-scheduler 
 ◦ Balances the distribution of region peers 
 高負荷なデータを調整 
 hot-region-scheduler 
 ◦ Balances the distribution of hot regions 
 アップグレード時にデータを退避 
 evict-leader-scheduler 
 ◦ Evicts all leaders of a node (often used for rolling upgrades) 
 TiDB TiDB TiKV Cluster (Storage) Meta data TiKV TiKV TiKV MySQL プロトコル TiKV TiDB TSO/Data location TiDB Cluster TiDB ... ... P D P D P D PD Cluster TiKV TiKV TiDB 今まで手動でやっていた事を自動化 
 PDが司令塔として活躍 
 TiDBで何を解決するのか For Game
  10. Re TiDBで何を解決するのか For Game
 - データアクセスの自動負荷分散 
 負荷のかかっているブロックを分割して分散可能 set config

    tikv split.qps-threshold=3000 ※例) qps3000で分割(デフォルト) 
 ID
 item
 price
 1
 apple
 10
 2
 orange
 9
 Table A Table A ID
 item
 price
 2
 orange
 9
 3,000QPSを超えたら、 
 データ分割を行い
 リバランスを実施し性能担保 
 Table A ID
 item
 price
 1
 apple
 10
 Region
 (32MB程度のサイズ) RegionA RegionB 仮にこのデータに4,000QPSが来たと想定
 ※ ID1に2,000QPS, ID2に2,000QPS想定
 分割したRegionで 
 2,000QPSになり閾値以下に!! 

  11. TiDBで何を解決するのか For Game
 A - B B - C C

    - D Key Space Node A Region 1* Region 2 Node B Region 3 Region 2* Node C Region 3* Region 2 Resion1の
 バックアップ
 Resion2の
 バックアップ
 Resion2の
 バックアップ
 Resion3の
 バックアップ
 - レプリカ数の変更
 最大冗長数を変更 max-replicas=5 ※設定数はお客様次第で データセンターA
 データセンターB
 データセンターC
 データセンターC
 データセンターD
 Node C Node C Resion1の
 バックアップ
 Resion1の
 バックアップ
 Region 2 Resion2の
 バックアップ
 Region 3 Resion3の
 バックアップ
 Resion3の
 バックアップ
 Region 2 Resion2の
 バックアップ
 コピー数を増やす事で稼働率の向上アップへ 
 Resion1の
 バックアップ

  12. • 書き込みパフォーマンスの低下、および、容易な容量拡張ができない • 15億行のデータが格納されてリード /ライト性能に大きな影響が発生 • 通常のストレージでは、オンラインでのデータ容量拡張ができない • アプリ改修なしで、移行できること (MySQL互換)

    • ゲームのコアアプリケーション課 金アプリケーション 請求アプリケーション ゲーム事例 NetEase 『荒野行動』
 導入シナリオ 導入効果 導入理由 • キャパシティプランニングが不要により、 DBシャーデング不要 • 新しいノードのオンライン拡張が可能になった 急成長するゲームを支えるデータベースの選定 スタンドアローンMySQLの限界によるアプリ影響の懸念 一日当たり36億を超えるリクエスト処理、データベースへの数十ギガバイトのデータ書込による大量データ書き込み Act-Standbyで複数DBを分散運用 TiDBでシングルDBのように運用