ゲーム業界で採用されているMySQL互換フルマネージドサービスのNewSQLデータベース「TiDB Cloud」

MySQLインターフェースのクラウドネイティブなNewSQLデータベース「TiDB（タイ・デー・ビー）」は、今まで苦労してきたデータベース運用を画期的に楽にすることが可能です。それは、機会損失を減らし、今まで出来なかったゲーム企画などにもチャレンジできる製品でもあります。特にクラウドサービスをご利用中の方は、本スライドにてより良さを感じて頂ければと思います。 また、実績としては、日本国内外ですでに多数のゲーム会社様で採用されており、多くのお客様が、フルマネージド型のTiDB Cloudを利用して頂いております。ぜひ、スライドにて今注目のTiDBについてご覧ください。

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

Transcript

1. ゲーム業界で採用されているMySQL互換フルマネージドサービスのNewSQL データベース「TiDB Cloud」 

2. こんな方におすすめ
 ・ NewSQLのフルマネージドサービスを探している
 ・ データベースのアプリでの水平分割をやめたい
 ・ 止まらないサービスを運用したい
 ・ 気軽に集計できる画面を作りたい

3. 自己紹介
 PingCAP株式会社
 シニアソリューションアーキテクト水戸 部 章生(mitobe akio)　 
 バックグラウンド
 • PingCAPの日本法人立ち上げの初期メンバー
 • 国内ゲーム会社のリードプログラマー
 • 外資系電子機器ベンダーのサーバ、ストレージ部 署のプロダクトマネージャー

4. 2015
 2016
 2018
 2019
 2020
 2017
 2022
 2021
 2015-9
 • TiDB available on GitHub 
 　 1ヵ月で2,700+ stars獲得 
 2015-4
 • PingCAP 設立 
 　　※3名のDBAによってスタート 
 2016-4
 • TiKV available on GitHub 
 　　※ Google Spannerから着想を得た 
 2016-8
 • シリーズAの資金調達 
 2017-10
 • シリーズBの資金調達（約2.5億円） 
 • TiDB 1.0 GA リリース 
 2017-12 • シリコンバレー（US）オフィス開設 
 2018-4
 • TiDB 2.0 GA リリース 
 2018-8
 • CNCF to Host TiKV in Sandbox 
 2018-9
 • InfoWorld 2018 Bossie Award受賞 
 • シリーズCの資金調達（約50億円） 
 2019-5
 • CNCF to host TiKV in incubato r
 2019-6
 • TiDB passed Jepsen test 
 2019-7
 • TiDB 3.0 GAリリース 
 2019-12
 • Chaos Mesh available on GitHub 
 
 2020-6
 • TiDB 4.0 GAリリース 
 2020-7
 • TiDB Cloud betaサービスの開始 
 • CNCF to host Chaos Mesh in Sandbox 
 2020-8
 • “TiDB, a Raft-based HTAP Database” published in VLDB 
 2020-11
 ・シリーズDの資金調達（約280億円） 
 2021-4
 • 日本法人 設立 
 東京オフィス開設 
 
 
 • TiDB 5.0 GAリリース 
 
 2022-2
 • TiDB Cloud 
 AWS Marketplaceに対応 
 
 
 
 
 2022-４
 • TiDB Cloud 
 GCP Marketplaceに対応 
 
 
 
 
 2022-4
 • TiDB Cloud 6.0 GA 
 
 
 PingCAP:創業〜現在まで 2015年から開発が始まり
 2000社以上導入されているデータベース

5. 2021/4/1
 Online event: 
 Cloud Native Database Meetup #1 
 Sakura Internet様 
 CyberAgent様 
 DMM様
 ・日本法人体制強化　＊現在23名＋1名 大規模案件常駐 
 営業/SE/テクニカルサポート（保守/技術問い合わせ）/TiDB Cloud R&D(1名) 
 Press Release: 
 さくらのクラウドEnhanced DB Offline event: 
 FIT2021
 Online event: 
 Cloud Native Days Tokyo 2021 
 Online event: 
 DB TECH SHOW CASE 
 2022/現在
 PingCAP Japanのご紹介
 Press Release: 
 U-NEXT様TiDB選定の理由 Online event: 
 Developers Summit 
 Press Release: 
 AWS marketplace対応 Press Release: 
 平野拓也 氏
 エグゼクティブアドバイザー就任 本社R&Dが常駐し積極的な日本展開
 日本国内でサポート完了できる体制を提供

6. MySQLコアチーム コアメンバー/InnoDB R＆Dヘッド
 SunnyBainsがSoftware Architectとして4月よりPingCAPに入社
 今後のTiDB/TiDB Cloudの更なる品質向上と機能実装の加速にむけて本社開発チームの更なる強化
 本社開発チームの強化 超強力なメンバーの参加が確定

7. 目次
 1. ゲーム開発現場の課題
 2. PingCAP(TiDB Cloud)のアプローチ
 3. どのようなシナリオで活躍するのか
 4. ゲーム業界事例

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

9. 負荷が上がった際に
 アプリサーバ側はステートレスで簡単に増やせたが
 問題はデータベースサーバ
 簡単には増やせず
 水平・垂直分割に悪戦苦闘の日々
 Jmeterで負荷テストを実施して同時接続2000をクリア問題なしと思っていたら・・・
 ユーザが想定以上にきて、DBが応答を返さなくなりました・・・
 結果、サービス停止し、機会損失へ。
 リリース後・・・
 自分自身の実体験から少し
 ゲーム開発現場の課題

10. 結果：負荷をさばく為、大量のシャーディングが生まれた
 Primary Secondry P S S S DAUが増加し・・・
 P S S S P S S S P S S S P S S S P S S S P S S S P S S S P S S S P S S S ゲーム開発現場の課題

11. DBだけでは完結できない為、アプリ側に工数も発生
 ゲーム開発現場の課題
 アプリ側で実施した内容
 ・ 水平、垂直分割のクラス作成
 ・ テーブルをまたぐjoinの改修
 DB側で実施した内容
 ・ DBをユーザ単位で水平分割
 ・ DBをアイテム単位で垂直分割
 大量のシャーディングをしたことにより負荷対策は出来た。
 
 ただ、別の問題が発生した
 ① DBが分れることによりトランザクションでデータロストが起きる構成に
 ② 負荷や容量増減によるサイジングがしにくい構成に
 ③ 分析がワンクエリで出来なくなる

12. ゲーム開発現場の課題
 シャーディングをした場合、
 ・ 障害ポイントの増加、運用コスト、ランニング費用の増加
 ・ 負荷対策においては、事前に設計が必須
 ・ 想定以上のユーザが来た
 
 ・ DBが減らせない
 
 ・ どのクエリーが問題なのか分からない
 
 ・ プライマリーDBがダウンで障害
 
 ・ 急なコラボイベントで緊急対応
 
 ・ DBが落ちるとトランザクションレベルでデータがロスト
 インフラ・アプリ
 プロデューサー
 ・ 想定以上のユーザが来たら機会損失に・・・
 
 ・ インフラコストを抑えられないのか
 
 ・ ノーメンテナンスで稼働できないのか
 × × △ シャーディングでは、悩みが解決できない・・・ 
 負荷対策は出来たが、むしろ、悩みが増えた 
 × × × × △
13. 目次
 1. ゲーム現場の課題
 2. PingCAP(TiDB Cloud)のアプローチ
 3. どのようなシナリオで活躍するのか
 4. ゲーム業界事例

14. そもそもなにが課題でシャーディングが必要なのか
 書き込み性能の向上
 の追及
 PingCAP(TiDB Cloud)のアプローチ
 Primary Secondry Secondry Secondry Secondry 読み込みデータベースは容易に増やすことが可能
 書き込みは一台のみ ＝ スペックアップの限界が、システム全体の限界となる
 

15. これまでのDBのアプローチ
 書き込み性能の向上
 PingCAP(TiDB Cloud)のアプローチ
 Primary NVMe(PCIeSSD)の登場 
 [ メリット ]
 ・ 書き込み量が1000倍にアップ
 書き込みが、SAS HDD 200 iops ⇒ NVMe SATA 200,000 iopsに 
 ・ 読み込み量が4000倍にアップ
 読み込みが、SAS HDD 200 iops ⇒ NVMe SATA 800,000 iopsに 
 
 [ デメリット ]
 ・ RAID構成が組めない為、ディスク障害でサーバダウンになる
 アプローチ1 ： DiSKのスケールアップでの向上
 ただし、1000倍に上がってもスペックの上限あり
 ※ クラウドだとここまでは出ない事も多々 

16. これまでのDBのアプローチ
 書き込み性能の向上
 PingCAP(TiDB Cloud)のアプローチ
 [ メリット ]
 ・ ハッシュ（ブロックデータ）による細かいデータのシャーディング
 データを自動で分散してくれているので、 
 システム全体で大きなストレージとして見る事が可能 
 ノード追加で書き込みをスケールアウト 
 
 [ デメリット ]
 ・ MVCCやACIDなどのデータ整合性をアプリ側で実施しないといけない
 アプローチ2 ： ブロックデータのシャーディング
 アプリ側でのデータ整合性の管理が非常に大変に
 KVS,NoSQL
17. PingCAP TiDBのアプローチ
 書き込み性能の向上
 PingCAP(TiDB Cloud)のアプローチ
 アプローチ2 ： ブロックデータのシャーディング
 アプローチ1 ： Diskのスケールアップでの向上
 環境に依存してしまう
 特にクラウドでは、iopsの制限があり十分な書き込み速度が提供できない 
 ACIDやMVCCなどの処理をアプリが実装する必要あり 
 TiDBの選択 ＋
 アプローチ3 ： KVS、NoSQLが苦手な
 ACID、MVCCの実現
 ＝ NewSQL

18. TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB 負荷分散・領域管理 
 3ノードのみ必要 
 SQL解析レイヤー
 ( TiDB Cluster )
 PD Cluster
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD データストアレイヤー 
 ( TiKV Cluster )
 PingCAP(TiDB Cloud)のアプローチ
 アプリ側でやっていたMVCC管理をTiDBノードで実装 
 KVSなどで苦労した 整合性を悩まず、しかもMySQLプロトコルで使える 
 Raftを採用したKVSの バックアップを兼ね備えた データ分散
 PingCAPのNewSQLへのアプローチ
 複数Cluster（TiDB,TiKV,PD）で運用
 役割別でCluster化することによりリソース管理の容易さを実現
 TiDBの司令塔

19. PingCAP(TiDB Cloud)のアプローチ
 ・ QPS100万近い値まで可能 ※理論値では、QPS300万達成可能
 ・ 容量は無限大（性能考慮で600TiB程度目安）の拡張性
 複数のデータベースをひとつのTiDBで
 運用できる能力

20. PingCAP(TiDB Cloud)のアプローチ
 SQL解析レイヤーTiDB Clusterの特徴
 MySQLインターフェースに準拠、マルチマスター構成、TiKVへ処理をオフロード
 LB
 TiDB TiDB mysql > SELECT table_name,column_name FROM tableA WHERE column_name > [ 検索条件 ]; 
 全ノードでinsert,updateのSQL対応が可能な為、LBでまとめる事が可能
 SQLをKVのデータへ変換を行いTiKVへ処理、もしくは、検索条件をTiKVに処理 をオフロードさせる
 TiDB クエリの増加 
 ノード追加で対応 
 ノード追加は、ステートレスな役割のため、即座に追加可能

21. PingCAP(TiDB Cloud)のアプローチ
 並列度を高めSQLの処理を高速化
 TiDBがアグリゲーションする事によりデータ量が増えた場合、 
 TiKVノードが増える為、並列度を向上させ性能劣化させない事 
 が可能
 データ量が増えてもSQLの性能を高速化させる技術
 TiKV TiKV TiKV データ量が増えた場合もノードも増えるため、並列度が向上
 TiKV TiKV TiKV TiKV バッチ処理による書き込みSQLの高速化
 最大256KeyをバッチでまとめてTiKVとのネットワーク 
 往復回数を減らし一度で書き込みを実施し高速化 
 TiDB Batch(1⇒value1, 2⇒value2, 3⇒value3….256⇒value254)をまとめてワンリクエストでTiKVに 書き込みを実行
 column_name > [検索条件1/3]
 column_name > [検索条件1/3]
 column_name > [検索条件1/3]
 TiDB column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 column_name > [検索条件1/4]
 TiDB
22. PingCAP(TiDB Cloud)のアプローチ
 データストアレイヤーTiKV Clusterの特徴
 冗長構成、オンラインでの容量伸縮、ノーメンテナンス運用の実現
 TiKV A Region 3
 バックアップ 
 Region 1*
 読み書き可能 
 Region 2
 バックアップ 
 TiKV B Region 3
 バックアップ 
 Region 1
 バックアップ 
 Region 2*
 読み書き可能 
 TiKV C Region 3*
 読み書き可能 
 Region 1
 バックアップ 
 Region 2
 バックアップ 
 ユーザーテーブル
 データサイズは、デフォルト 96MB 
 ※小さいサイズにする事で柔軟性を確保
 Raftログによるコンセンサスアルゴリズム 
 ひとつの読込/書込ポイントと2つのバックアップ 
 ※ 圧縮を行っているので、バックアップありの状態でMySQL一台の容量とほぼ同じになる事も 
 96MB 96MB 96MB
23. PingCAP(TiDB Cloud)のアプローチ
 冗長構成
 ノードが分かれているので、ＤＣを超えて配置可能 
 データベース単体でＤＲも実現可能 
 （クエリーの応答が断ではなく） 
 デフォルト 20sの応答遅延のみ ※設定により変更可能 
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 オンラインでの容量伸縮
 96MBという小さいサイズで管理している為、 
 ノード追加した瞬間からデータ移行が開始 
 バックアップが読み書きを引き継ぐ機能により様々な問題を解決
 昇格（リーダ） 
 ノーメンテナンス運用を実現
 ファームウェアアップデート時にリーダーを 
 別ノードへ移動しローリングアップグレードが可能 
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 TiKV バックアップデータを移動し 
 リーダーに昇格 
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 昇格(リーダ) 
 まず、このノードをアップグレードしリーダを 移動しながら順に対応 

24. PingCAP(TiDB Cloud)のアプローチ
 TiDBの司令塔 PD Clusterの特徴
 データ配置の完全自動化、クエリ情報の収集
 3ノードによる冗長構成 
 PD Cluster
 PD PD PD スケジューラーによるデータの自動運用
 アクセス先の偏りを調整 
 balance-leader-scheduler 
 データの偏りを調整 
 balance-region-scheduler 
 高負荷なデータを調整 
 hot-region-scheduler 
 アップグレード時にデータを退避 
 evict-leader-scheduler 
 データ量が減ったregionのマージ 
 region merge schedule 
 データ量が増えたregionの分割 
 region split schedule 
 heartbeats
 clusterCache
 coordinator
 balance leader 
 balance region 
 hot region 
 TiKV PD TiKVからのハートビートによりデータの状態を把握

25. PingCAP(TiDB Cloud)のアプローチ
 Re - データアクセスの自動負荷分散 
 負荷のかかっているブロックを分割して分散可能 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になり閾値以下に！！ 
 PDスケジューラによる自動シャーディングの技術

26. PingCAP(TiDB Cloud)のアプローチ
 - データアクセスの自動負荷分散 
 全ての実行クエリの詳細情報の取得が可能に
 クエリの劣化や異常なクエリの発見に役立つ 
 ステートメント一覧
 標準出力項目
 トータル実行時間、平均レイテンシー、実行回数 
 該当のクエリをクリックすると実行計画、各種ステータスの状況確認が可能

27. PingCAP(TiDB Cloud)のアプローチ
 - データアクセスの自動負荷分散 
 プロデューサー
 ・ 想定以上のユーザが来たら機会損失に・・・
 → TiDB,TiKVのオンライン拡張で回避
 
 ・ インフラコストを抑えられないのか
 → TiKVのオンライン縮小が可能
 
 ・ ノーメンテナンスで稼働できないのか
 → ローリングアップグレード、DDLのオンライン変更対応
 ・ 想定以上のユーザが来た
 → TiDB,TiKVのオンライン拡張で回避
 
 ・ DBが減らせない
 → TiKVのオンライン縮小が可能
 
 ・ どのクエリーが問題なのか分からない
 → リアルタイムクエリ分析
 
 ・ プライマリーDBがダウンで障害
 → ノードダウンでも20秒の応答遅延のみ(※設定で1sにすることも可能)
 
 ・ 急なコラボイベントで緊急対応
 → TiKVのオンライン拡張が可能
 
 ・ DBが落ちるとトランザクションレベルでデータがロスト
 → （性能考慮で）600TiBで一つのデータベースで管理可能
 インフラ・アプリ
 TiDBでゲーム業界における今までのすべての問題を解決する事が可能に

28. PingCAP(TiDB Cloud)のアプローチ
 - データアクセスの自動負荷分散 
 ・ ランキングをリアルタイムに出したい
 ・ マイページがどんどん重くなってきている
 ・ 運用から解放されたい
 インフラ・アプリ
 ゲーム開発の次の一歩

29. PingCAP(TiDB Cloud)のアプローチ
 - Analytics処理の有無 
 AnalyticsとトランザクションをTiDBプラットフォームで利用可能 
 コマンド一つで連携、構築可能 
 必要なテーブル単位でレプ リケート指定可能 TiFlash RowData RowData RowData RowData TiKV すべてリアルタイムデータ 利用 ワンコマンドでクラスターへの同期可能、高速な分析クエリのレスポンスへ
 シナリオ1:APのみ検索
 TiDB
 TiFlash
 シナリオ2:TPのみ検索 
 TiDB
 TiKV
 シナリオ3:TP+AP検索
 TiDB
 TiKV
 TiFlash
 TiFlash Cluster追加で簡単リアルタイム分析が可能
 TiDBがコストベースでクエリを判別し、適切なクラスターを選択

30. PingCAP(TiDB Cloud)のアプローチ
 HTAPで実現できるリアルタイム集計
 米国運輸省からの航空機の離陸と着陸の1987年から現在までの定刻条件の集計処理
 OLTPだけでは苦手だった集計クエリが高速化にランキング集計やマイページの統計情報出力で活躍 
 MySQLでは、4～5分かかっていたクエリが1秒未満に

31. PingCAP(TiDB Cloud)のアプローチ
 で解決
 フルマネージドサービスの提供
 （サーバ・クラスター運用、高負荷対応、BigData解析、耐障害性 込み）
 
 フルマネージドリリース済みプラットフォーム
 Amazon Web Services
 Google Cloud Platform
 Microsoft Azure(2024年予定)
 サーバ・クラスター運用をPingCAPに丸投げ

32. PingCAP(TiDB Cloud)のアプローチ
 の特徴
 マルチプラットフォーム
 ・ ベンダーロックインを回避
 AWS、GCP、Azureで
 フルマネージドサービスを提供
 
 開発環境の提供
 ・ クラスターを組まずコマンド一つで自身のPC環境で構築可能 
 ワンコマンドで構築が可能
 
 
 ・ 開発/テスト環境向けミニマム構成の提供 
 TiDB Cloud上で、2core 200GB環境の提供 
 全てのオンプレミス環境で構築可能 
 パブリッククラウド上のフルマネージド
 自社運用に切り替える事が可能

33. PingCAP(TiDB Cloud)のアプローチ
 データベース管理を弊社スペシャリストがフルマネージドでサポート 
 各リージョン上で弊社が、デプロイした環境のご提供方式 
 
 アクセス方式は、VPC Peeringもしくは、PrivateLinkで接続後、 
 1つのエンドポイントを利用する方式 
 VPC Peering or PrivateLink mysql -u root -h <endpoint> -P 4000 -p
 VPC Peering or PrivateLink
34. PingCAP(TiDB Cloud)のアプローチ
 マルチAZで環境配置でデータセンター障害にも対応 

35. PingCAP(TiDB Cloud)のアプローチ
 - データアクセスの自動負荷分散 
 ・ ランキングをリアルタイムに出したい
 ⇒ HTAPの導入
 ・ マイページがどんどん重くなってきている
 ⇒ HTAPの導入
 ・ 運用から解放されたい
 ⇒ TiDB Cloudのフルマネージドの活用
 インフラ・アプリ
 データベースの更なる進化で対応

36. 目次
 1. ゲーム現場の課題
 2. PingCAP(TiDB Cloud)のアプローチ
 3. どのようなシナリオで活躍するのか
 4. ゲーム業界事例

37. どのようなシナリオで活躍するのか
 特に要望の多いシナリオ
 
 ・ オンプレからクラウド化したい
 ・ MySQL互換の製品でマルチマスタ製品が欲しい
 ・ HTAPでクエリの高速化をしたい
 
 ・ 日本法人のフルサポートが欲しい
 PoCからフルサポートでご好評いただいております。

38. 各フェーズにあったTiDB Cloudの利用
 用途
 開発
 ステージング
 本番環境
 QPS目安
 ～500QPS
 ～1,000QPS 
 20,000QPS～ 
 40,000QPS～ 
 インスタンスタイプ 
 2Core
 ディスクサイズ: 
 200GB ～ 500GB 
 4Core
 ディスクサイズ: 
 200GB ～ 2TB 
 8Core
 ディスクサイズ: 
 500GB ～ 600TB 
 16Core
 ディスクサイズ: 
 500GB ～ 600TB 
 目安コスト
 〜1,000ドル 
 2,000〜3,000ドル 
 5,500ドル
 9,000ドル
 特記事項
 
 ・TiDBの最大スケールが2台 
 ・Tiflash　利用不可 
 
 ※ 上記機能が必要になった場合 8coreモデルにスペックアップ 
 
 ・TiDBの最大スケールが2台 
 ・Tiflash　利用不可 
 
 ※ 上記機能が必要になった場合 8coreモデルにスペックアップ 
 
 
 必要なQPSに応じた
 豊富なインスタンスタイプのご提供
 ＊Enterpriseテクニカルサポートでの概算算出 (※上記は参考価格となります。詳しくは pingcapjp@pingcap.com までお問い合わせください)

39. 目次
 1. ゲーム現場の課題
 2. PingCAP(TiDB Cloud)のアプローチ
 3. どのようなシナリオで活躍するのか
 4. ゲーム国内事例

42. Thank You !
 info@pingcap.com