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

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

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

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

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社以上導入されているデータベース 

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が常駐し積極的な日本展開  日本国内でサポート完了できる体制を提供 

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

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

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

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

結果：負荷をさばく為、大量のシャーディングが生まれた  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 ゲーム開発現場の課題 

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

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

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

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

これまでの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倍に上がってもスペックの上限あり  ※ クラウドだとここまでは出ない事も多々  

これまでのDBのアプローチ  書き込み性能の向上  PingCAP(TiDB Cloud)のアプローチ  [ メリット ]  ・ハッシュ（ブロックデータ）による細かいデータのシャーディング  データを自動で分散してくれているので、
  システム全体で大きなストレージとして見る事が可能   ノード追加で書き込みをスケールアウト     [ デメリット ]  ・ MVCCやACIDなどのデータ整合性をアプリ側で実施しないといけない  アプローチ2 ：ブロックデータのシャーディング  アプリ側でのデータ整合性の管理が非常に大変に  KVS,NoSQL

PingCAP TiDBのアプローチ  書き込み性能の向上  PingCAP(TiDB Cloud)のアプローチ  アプローチ2 ：ブロックデータのシャーディング  アプローチ1 ：
Diskのスケールアップでの向上  環境に依存してしまう  特にクラウドでは、iopsの制限があり十分な書き込み速度が提供できない   ACIDやMVCCなどの処理をアプリが実装する必要あり   TiDBの選択＋  アプローチ3 ： KVS、NoSQLが苦手な  ACID、MVCCの実現  ＝ NewSQL 

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の司令塔 

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

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 クエリの増加   ノード追加で対応   ノード追加は、ステートレスな役割のため、即座に追加可能 

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

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

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   バックアップ   昇格(リーダ)   まず、このノードをアップグレードしリーダを移動しながら順に対応  

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からのハートビートによりデータの状態を把握 

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スケジューラによる自動シャーディングの技術 

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

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

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

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がコストベースでクエリを判別し、適切なクラスターを選択 

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

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

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

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

PingCAP(TiDB Cloud)のアプローチ  マルチAZで環境配置でデータセンター障害にも対応  

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

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

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

各フェーズにあった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テクニカルサポートでの概算算出 (※上記は参考価格となります。詳しくは [email protected] までお問い合わせください) 

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

Thank You !  [email protected]  

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

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

More Decks by PingCAP-Japan

Other Decks in Technology

Featured

Transcript