脱シャーディング！！ NewSQLのTiDBで実現~楽しいね！を世界中の日常へお届けするためにエンジニアリングで行ったこと

Slide 1

Slide 1 text

脱シャーディング！！ NewSQLのTiDBで実現 ~楽しいね！を世界中の⽇常へお届けするためにエンジニアリングで⾏ったこと⽇下太智 PingCAP株式会社シニアソリューションアーキテクト中⼭智義ワンダープラネット株式会社エンジニアリング＆デザインマネジメント室テックリード

Slide 2

Slide 2 text

アンケートのお願い QRコードを読み込んでアンケートにご回答ください。回答者にはTiDB資格試験無料パスをもれなく全員にプレゼントいたします。オンライン参加者の⽅は、資格試験パスの他に「PingCAPオリジナルTシャツ」または「Software Design 2023年8⽉号」の中から1点ご選択ください。※回答期限は2023年8⽉24⽇(⽊) 午後14:00まで。会場参加の⽅オンライン参加の⽅ TiDB資格試験無料パス

Slide 3

Slide 3 text

Agenda 【前半】TiDBについて（PingCAP） ● 会社/⾃⼰紹介 ● TiDBの特徴やアーキテクチャー、ユースケース【後半】TiDBの活⽤について（ワンダープラネット） ● 会社/⾃⼰紹介 ● 抱えていた課題 ● これまでの対策 ● TiDBの活⽤⽅法 ● 採⽤に関するワンポイントピンちゃん ※PingCAP⾮公式キャラクター

Slide 4

Slide 4 text

会社紹介 Our Mission エンジニアへの価値提供によってビジネスのスケール、スピード、アジリティに貢献します NewSQL MySQL互換の分散型SQLデータベースグローバル以上で採⽤ 3,000社

Slide 5

Slide 5 text

⾃⼰紹介⽇下太智（Taichi Kusaka） PingCAP株式会社シニアソリューションアーキテクトゲーム業界を中⼼に様々な業界のお客様にプリセールスや導⼊/移⾏⽀援を⾏っています

Slide 6

Slide 6 text

ゲーム業界の⽅々からよく聞くお話し

Slide 7

Slide 7 text

● 急なイベント対応続きで夜寝られない ● サイジングは難しい（当てるのが）そのための対策は何よりも⾯倒っ！！！ ● 極⼒、停めないためにどうするか‧‧‧ 某エンジニア

Slide 8

Slide 8 text

● 新規タイトル⼤ヒット！！！！でもDB拡張が追いつかず機会損失が‧‧‧ ● 事前サイジングから⼤きく下ぶれてしまった‧‧‧ DBのコストが思ってたより⾼くついてる某プランナー

Slide 9

Slide 9 text

● ワールドが違うユーザー同⼠など、すべてのユーザーでマッチング可能（パーティーを組む）にするのは、意外と難しいらしい ※ワンワールドの実現は難しい！！某プロデューサー

Slide 10

Slide 10 text

それ、DBを⼤量アクセスの対策としてやったものの‧‧‧ シャーディングしてますよね？いままでアプリケーション User1  User2  User3  ・・  User10001  User10002  ・・  User20000  ・・・  User90001  User90002  ・・  User99999  ● 実装の複雑化、メンテナンス⼤変 ● DBリソースの不均衡によるコスト⾼ ※インフラ費⽤に占める割合としても無視できない ● ゲーム性も限定される要因に

Slide 11

Slide 11 text

こうしたいアプリケーション User1  User2  User3  ・・  User10001  User10002  ・・  User20000  User90001  User90002  ・・  User99999  ・・・  どうやる？ → NewSQL

Slide 12

Slide 12 text

RDBMSとNewSQLの違い（1/2） - ストレージエンジン RDBMS NewSQL B+Tree ‧読取りに特化した平衡⽊ ‧上書き型 LSM-Tree ‧書込みに特化した構造 ‧追記型 ex. ⼀時的にメモリに書込み、ソート/マージしつつディスク保存ソート＆マージソート＆マージ

Slide 13

Slide 13 text

RDBMSとNewSQLの違い（2/2） - 拡張性を求めた構成 RDBMS NewSQL ‧マスターが更新ログを送って同期 ※もしくはStorage共有など ‧読取り:リードレプリカで負荷分散 ‧書込み:マスター ※ボトルネック ‧Shared-nothing:データを分割管理 ※各ノード(リーダー)で書込み/読取 ‧ノード追加により、読み書き共にスケール App マスターリードレプリカ Read Only Read/Write App マルチマスター Read/Write リーダーフォロワー

Slide 14

Slide 14 text

TiDBのアーキテクチャー⽔平⽅向にスケール ※垂直も可 ※ワンアクションで TiDB = コンピューティング ‧Parser / Optimizer etcを担う ※都合の良いストレージコンポーネントからデータを読む TiKV = ストレージ（Row型） ‧ACIDトランザクションを提供する分散KVS ※NewSQL的なStorage TiFlash = ストレージ（Column型） ‧列形式のデータストア ‧オプショナルで追加 ※HTAP PD = 司令塔 ‧データの物理的な配置情報管理 ‧グローバルで⼀意なタイムスタンプ発⾏

Slide 15

Slide 15 text

TiDBのアーキテクチャー⽔平⽅向にスケール ※垂直も可 ※ワンアクションで

Slide 16

Slide 16 text

データ管理の仕組み Autoシャーディング ∴設計‧実装の考慮不要 ● Raftグループを形成(Multi-Raft) ○ Leader ：読み書き対象（１つ） ○ Follower ：バックアップ（２つ） ○ Learner ：カラムナ側（１＋） ● Region単位で管理 ○ PKなどのRangeで分割 ○ デフォルト96MBを軸に⾃動分割

Slide 17

Slide 17 text

データ管理の仕組み Autoシャーディング ∴アプリケーション側での実装不要

Slide 18

Slide 18 text

こんなときは？障害起きた。。。バージョンアップしたい（しなきゃ）スケールさせたい Leaderの役割が移動ダウンタイムなし

Slide 19

Slide 19 text

TiDBのラインナップ ● Serverless ○ クラウド型フルマネージド ○ マルチテナント ● Dedicated ○ クラウド型フルマネージド ○ お客様毎の専⽤VPC内にTiDB構築 ● Self-Hosted ○ OSSバージョンのTiDB ○ 様々な環境/構成で構築可能マルチAZ 構成

Slide 20

Slide 20 text

プロデューサープランナーエンジニアつまり、ゲームの設計‧開発〜運⽤の過程でエンジニアリング的にもビジネス的にもメリットが？！今まで　※シャーディング TiDBならワールド限界 ※ゲーム性の幅サービスを停めたくない予想外れ機会損失/コスト⾼実装の複雑化メンテナンス⼤変シャーディング不要な実装 ※慣れ親しんだMySQL互換ワンポチで⾃在なスケール障害/バージョンアップ時もサービス継続

Slide 21

Slide 21 text

「脱シャーディング」とは少し違う⾓度から

Slide 22

Slide 22 text

こんなことにもお困りでは？プランナーさん（多数派：SQL書けない）ビジネス判断のためデータを早く欲しい ● 今⽉の売上げを⽇別にまとめて ● 継続率を1⽇・3⽇・7⽇・30⽇で⽇毎にまとめて ● 3万円以上課⾦して⼀週間以上ログインしていないユーザーのレベルを教えて ● 第三ステージのクリア時のLvと戦⼒を教えてエンジニアさん（多数派：SQL書ける）やるべきことはたくさん（正直めんどくさい）

Slide 23

Slide 23 text

これまでのやり⽅ではこんな懸念が？ ● DB負荷取得すべきデータが本番にしかない →よろしくないクエリを投げてしまう恐れ ∴ゲームユーザーに影響？！ ● データ DWHなどにETL通じて連携 ∴構築/運⽤コストかかる ∴データ鮮度も落ちる ● SQL ⾃然⾔語をSQLにエンジニアが変換 ∴⼿間

Slide 24

Slide 24 text

TiDBだと ● DB負荷 Resource Control機能 ∴影響気にしない ● データ ● SQL ● 活⽤するリソースをユーザー単位で制限 →分析クエリ発⾏者には制限をかけることで、ゲームユーザへの影響を減らす

Slide 25

Slide 25 text

TiDBだと ● DB負荷 Resource Control機能 ∴影響気にしない ● データ TiFlashに追加により ∴TiDBで完結 ∴データ鮮度良好 ● SQL Chat2Query機能で⾃然⾔語をSQLに変換 ∴プランナー⇔エンジニアのパス不要 ※APIもあり

Slide 26

Slide 26 text

デモンストレーションサイト Chat2QueryのAPIを活⽤した対話型ダッシュボード TiDBにGithubのデータ（現在60億超えのレコード数）を取り込み、Webページからクエリを発⾏、分析を可能としているサイトです。 Githubのリアルタイムイベントを取り込むOLTP を実⾏しながら、各種ダッシュボードなどの OLAPタスクを同時に実⾏するインターネット情報サイトのデモになっています。 OSS Insight https://ossinsight.io/ 

Slide 27

Slide 27 text

プロデューサープランナーエンジニアつまり、ゲーム運営に関わるビジネス的な判断のための分析においてやっぱりエンジニアリング的にもビジネス的にもメリットが？！今まで TiDBなら依頼した情報を早く確認して、⽅向性を早く決めたい依頼にすぐに答えたいけど、運⽤で⼿⼀杯‧‧‧ HTAPやAIなどTiDBの機能をフル活⽤で解決！！！

Slide 28

Slide 28 text

CONTINUE

Slide 29

Slide 29 text

脱シャーディング！！ NewSQLのTiDBで実現 ~楽しいね！を世界中の⽇常へお届けするためにエンジニアリングで⾏ったこと~ 中⼭智義ワンダープラネット株式会社エンジニアリング＆デザインマネジメント室テックリード

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© WonderPlanet Inc. 33 主要タイトル概要と注力分野アリスフィクションクラッシュフィーバージャンプチヒーローズ新規タイトル開発【タイトル概要】・2015/7リリース・運営8年目・日本版、海外版を運営中【タイトル概要】・2018/3リリース・運営5年目・日本版、繁体字版を運営中【タイトル概要】・2022/7リリース・全世界同時配信・同時運営全世界同時運営全世界1400万DL 全世界2000万DL ギネス記録認定自社開発タイトル（オリジナル）自社開発タイトル（IP）新規事業領域参入コンシューマー系ゲーム開発会社との共同事業新規タイトルを準備中

Slide 34

Slide 34 text

34 抱えている課題

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© WonderPlanet Inc. 39 そもそもデータベース分割は複雑で難度が高いどのように分割するかの設計が難しい - 分割の仕方が良くないとデータの取り回しが悪くなり処理が複雑になる - 全シャードを探索する必要があるとパフォーマンスが落ちるデータベースが分割されていることを念頭に置いた開発・実装が難しい - どのデータベースにどのデータが入っているかを把握する必要がある - Write - Readのレプリケーション遅延を考慮する必要がある分割されたデータベースを運用することが難しい - 想定通りのユーザー数にならず分割が無駄・負債になったり分割数を増やす必要が出る - データの偏りが発生しシャードの振り分け方法を最適化する必要が出る - 分析・集計処理やデータ修正が複雑・困難 - シャード分割起因の不具合や障害が発生する etc...

Slide 40

Slide 40 text

© WonderPlanet Inc. 40 そもそもデータベース分割は複雑で難度が高いどのように分割するかの設計が難しい - 分割の仕方が良くないとデータの取り回しが悪くなり処理が複雑になる - 全シャードを探索する必要があるとパフォーマンスが落ちるデータベースが分割されていることを念頭に置いた開発・実装が難しい - どのデータベースにどのデータが入っているかを把握する必要がある - Write - Readのレプリケーション遅延を考慮する必要がある分割されたデータベースを運用することが難しい - 想定通りのユーザー数にならず分割が無駄・負債になったり分割数を増やす必要が出る - データの偏りが発生しシャードの振り分け方法を最適化する必要が出る - 分析・集計処理やデータ修正が複雑・困難 - シャード分割起因の不具合や障害が発生するゲームの楽しさ作りに集中できない！ etc...

Slide 41

Slide 41 text

41 TiDBの期待と検証

Slide 42

Slide 42 text

© WonderPlanet Inc. 42 負荷分散・シャーディング周りの課題が解消できそう！内部的に分割されているだけで   外からは1つのデータベースとして扱える   TiDB Writeもスケールアウトが可能  - 簡単に負荷分散できる    自動シャーディング  - データ配置を意識しなくて良い     MySQL互換  - これまでの資産が無駄にならない     Cloudネイティブ  - サーバ管理から解放される    データベース分割周りの問題が解決！  

Slide 43

Slide 43 text

© WonderPlanet Inc. 43 TiDB Cloudの検証 TiDB Cloudはゲームサービスの運用に耐えられるのか？の観点でAuroraと比較検証 ● 処理性能 ○ 通信レイテンシはどうか ○ クエリ処理速度はどうか ○ 負荷耐性はどうか ● 拡張性 ○ 運用中に非停止でDDL適用することができるか ○ 運用中に非停止でスケールすることができるか ○ コネクション管理はどうか ○ スケールが許容できるコスト感か ● 機能 ○ MySQL互換性は十分か ○ 復旧機能（バックアップやリストア性能）は十分か ○ ログや統計情報など、運用のための情報を取得できるか

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© WonderPlanet Inc. 48 TiDBとAuroraの比較：拡張性 Amazon Aurora TiDB 非停止DDL適用 ◎: Fast DDLあり ◯ スケールアウト △: Readerのみ、Writeは不可 ◯ スケールイン ◯ ◯: コネクション再接続が必要スケールアップ / ダウン △: 停止が必要 ◯: コネクション再接続が必要コネクション数 △: メモリサイズ依存 ◯: 上限なし 1ノードあたりの費用 △: 高め △: 高め最小コスト 1ノード分の費用 Serverless：従量、Freeあり Dedicated：TiDB x1, TiKV x3 ストレージ拡張 ◎: 自動 ◯: 容量指定

Slide 49

Slide 49 text

© WonderPlanet Inc. 49 コスト面について - 1 * コンピューティング Aurora vCPUを合わせる TiDB TiKV 4 vCPU, 16 GiB $0.627 (r6g.xlarge, 4vCPU/32GiB) $0.5704 $0.5704 8 vCPU, 16 GiB $1.253 (r6g.2xlarge, 8vCPU/64GiB) $0.9844 - 8 vCPU, 32 GiB $1.253 (r6g.2xlarge, 8vCPU/64GiB) - $1.1408 16 vCPU, 32 GiB $2.506 (r6g.4xlarge, 16vCPU/128GiB) $1.9688 - 16 vCPU, 64 GiB $2.506 (r6g.4xlarge, 16vCPU/128GiB) - $2.2816 比較は難しいが、ノード単位で見ると大体同程度 - Auroraと同等スペックのノードがTiDB Cloudでは提供されていない - 実際の料金には通信やI/Oコストなどが掛かるので読みにくい

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© WonderPlanet Inc. 51 TiDBとAuroraの比較：その他機能 Amazon Aurora TiDB SQL MySQL 5.x, 8.x 100%互換 MySQL 5.7互換 (一部互換なし, 独自機能あり) バックアップ ◯ ◯: 1日1度自動バックアップリカバリ ◯: Point in Time Recovery ◯: Point in Time Recovery メトリクス監視 ◯ ◯ アラート ◯ △: 自由に設定するには外部ツール必要クエリ分析 ◯ ◯

Slide 52

Slide 52 text

© WonderPlanet Inc. 52 MySQL互換性について MySQLの全ての機能をサポートしていない - ストアドプロシージャと関数 - トリガーやイベント　　： MySQLと挙動が異なる機能がある - AUTO_INCREMENT - EXPLAIN - DDLの制限　　：データベース機能を使わないシンプルなクエリであれば影響は小さい - あるゲームのデータベースをTiDBにリストアして結合試験し、MySQLと同じ結果を得た

Slide 53

Slide 53 text

© WonderPlanet Inc. 53 TiDBの特徴まとめシャーディング対応する規模で高頻度でスケーリングするサービスに向いている - シャーディング不要・レプリケーション遅延問題が発生しない - 非停止でDDL適用やスケーリング可能 - コストや処理性能はAuroraと同等程度ネットワークレイテンシの観点でマイクロ秒レベルの最適化が必要なサービスは不利 →ワンダープラネットのゲームプロダクトに合致

Slide 54

Slide 54 text

54 TiDBの活用について

Slide 55

Slide 55 text

© WonderPlanet Inc. 55 活用状況検証の結果、開発中タイトルへ導入することに - シャーディングしないで済む管理・運用コストの改善が魅力 - ビジネススケールに合わせて直ぐスケーリングできる - 特にリリース時や大規模イベントといった負荷を読みにくいタイミングに効果を期待 - 最悪MySQL (Amazon Aurora) に戻せるように互換性を保っておく - ローカル開発時はMySQL、開発環境はTiDB Cloud 細かい課題はありつつ、概ね問題なく動作している

Slide 56

Slide 56 text

© WonderPlanet Inc. 56 採用に関するワンポイント - 機能 MySQLとの細かい違いに注意が必要 - MySQLをStrict Modeで動かしておらず、移行時にDEFAULT・NULL値周りでトラブル AUTO_INCREMENTは非推奨 - ホットスポットを誘発しやすくなりパフォーマンス劣化の原因になってしまう - ワンダープラネットではアプリケーション側でUUIDを採番しているスケーリングの際にコネクションが切れる - アプリケーション側でハンドリングして自動リトライを入れた - TiDB Cloud側でプロキシを前段に立てる改善予定とのこと

Slide 57

Slide 57 text

© WonderPlanet Inc. 57 採用に関するワンポイント - 運用物理DDL適用に時間が掛かる - 論理DDLと物理DDLがありインデックス追加などが物理DDL - オンラインで実行できるものの、MySQLより時間が掛かる TiDB Cloud Serverlessが便利 - ちょっとした検証のために立てて繋ぐことができる - ローカルでもDocker上でTiDBを構築できるがちょっと重い TiDB自体のバージョンアップによる機能改善サイクルが早い - LTSを約6ヶ月毎にリリースするサイクル - 検証中にバージョンが上がってスケール性が向上した - 速度改善や独自機能の追加も盛ん

Slide 58

Slide 58 text

© WonderPlanet Inc. 58 採用に関するワンポイント - サポートドキュメントが豊富 - 前述のMySQL互換やAUTO_INCREMENTなど、つまづいたところは大体解説されている - バージョン更新に伴ってドキュメントも更新されていく - Youtubeで基本的な仕組みから詳細な機能まで解説されている - GitHubにコードが公開されているサポートが手厚い - 前述の課題はPingCAP社に相談して解決や回避策を取っている

Slide 59

Slide 59 text

59 まとめ

Slide 60

Slide 60 text

© WonderPlanet Inc. 60 まとめワンダープラネットではデータベースのシャーディングに課題感を持っていた - 設計・開発・運用どのタイミングでも問題が起こりやすい TiDBを検証して、開発中プロダクトへの導入を決定 - ビジネススケールに合わせてインフラサイズを調整しやすい - 複雑なデータベース分割から解放されインフラ管理工数の削減が期待できる複雑なシャーディングを考えずにゲームの楽しさ作りに集中できるように！

Slide 61

Slide 61 text

61 ご清聴ありがとうございました！最後に・・・

Slide 62

Slide 62 text

Slide 63

Slide 63 text

THANK YOU. もっとくわしく？ → つづける（Ask The Speakerへ）やめる