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

2023年8月に開催されたイベント「CEDEC 2023」でのWonderPlanet社とPingCAPによるセッション「脱シャーディング！！ NewSQLのTiDBで実現 ~ 楽しいね！を世界中の日常へお届けするためにエンジニアリングで行ったこと」の資料です。

イベント開催日：2023年08月24日

楽しいね！と言ってもらえるゲームを作る、ゲーム業界に携わるみなさんにとっても最も重要なことだと思いますが、一方でユーザー様に長く楽しんで頂くために足元を整えることもかかせません。運用フェーズを見据え、想定を超えるアクセスがあった際どのようにして機会損失が発生しないようにするか、運用コストの削減にエンジニアリングの観点でどう寄与していくか、特にデータベースのシャーディングや先の読めないサイジングをどう解決していくかはひとつの大きなテーマかと思います。

シャーディングなしで高負荷にも耐えられるスケール性を持ちつつ、リソース活用の最適化が容易なものがあったらイイと思いませんか？慣れ親しんだMySQL互換でこれらの課題を解決してくれるNewSQLデータベースのTiDBを検証し、実際に採用したポイントやその効果について話します。

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

Transcript

1. 脱シャーディング！！ NewSQLのTiDBで実現 ~楽しいね！を世界中の⽇常へお届けするために エンジニアリングで⾏ったこと ⽇下 太智 PingCAP株式会社 シニアソリューションアーキテクト 中⼭ 智義 ワンダープラネット株式会社 エンジニアリング＆デザインマネジメント室 テックリード
2. アンケートのお願い QRコードを読み込んでアンケートにご回答ください。 回答者にはTiDB資格試験無料パスをもれなく全員にプレゼントいたします。オンライン参加者の⽅ は、資格試験パスの他に「PingCAPオリジナルTシャツ」または「Software Design 2023年8⽉号」 の中から1点ご選択ください。※回答期限は2023年8⽉24⽇(⽊) 午後14:00まで。 会場参加の⽅ オンライン参加の⽅ TiDB資格試験無料パス
3. Agenda 【前半】TiDBについて（PingCAP） • 会社/⾃⼰紹介 • TiDBの特徴やアーキテクチャー、ユースケース 【後半】TiDBの活⽤について（ワンダープラネット） • 会社/⾃⼰紹介 • 抱えていた課題 • これまでの対策 • TiDBの活⽤⽅法 • 採⽤に関するワンポイント ピンちゃん ※PingCAP⾮公式キャラクター
4. 会社紹介 Our Mission エンジニアへの価値提供によって ビジネスのスケール、スピード、アジリティに貢 献します NewSQL  MySQL互換の  分散型SQLデータベース グローバル 以上で採⽤ 3,000社
5. ⾃⼰紹介 ⽇下 太智（Taichi Kusaka） PingCAP株式会社 シニアソリューションアーキテクト ゲーム業界を中⼼に様々な業界のお客様に プリセールスや導⼊/移⾏⽀援を⾏っています
6. ゲーム業界の⽅々から よく聞くお話し
7. • 急なイベント対応続きで夜寝られない • サイジングは難しい（当てるのが） そのための対策は何よりも⾯倒っ！！！ • 極⼒、停めないためにどうするか‧‧‧ 某エンジニア
8. • 新規タイトル⼤ヒット！！！！ でもDB拡張が追いつかず機会損失が‧‧‧ • 事前サイジングから⼤きく下ぶれてしまった‧‧‧ DBのコストが思ってたより⾼くついてる 某プランナー
9. • ワールドが違うユーザー同⼠など、 すべてのユーザーでマッチング可能（パーティーを組む） にするのは、意外と難しいらしい ※ワンワールドの実現は難しい！！ 某プロデューサー
10. それ、DBを ⼤量アクセスの対策として やったものの‧‧‧ シャーディングしてますよね？ いままで アプリケーション User1
 User2
 User3
 ・・
 User10001
 User10002
 ・・
 User20000
 ・・・
 User90001
 User90002
 ・・
 User99999
 • 実装の複雑化、メンテナンス⼤変 • DBリソースの不均衡によるコスト⾼ ※インフラ費⽤に占める割合としても無視できない • ゲーム性も限定される要因に
11. こうしたい アプリケーション User1
 User2
 User3
 ・・
 User10001
 User10002
 ・・
 User20000
 User90001
 User90002
 ・・
 User99999
 ・・・
 どうやる？ → NewSQL
12. RDBMSとNewSQLの違い（1/2） - ストレージエンジン RDBMS NewSQL B+Tree ‧読取りに特化した平衡⽊ ‧上書き型 LSM-Tree ‧書込みに特化した構造 ‧追記型  ex. ⼀時的にメモリに書込み、   ソート/マージしつつディスク保存 ソート＆マージ ソート＆マージ
13. RDBMSとNewSQLの違い（2/2） - 拡張性を求めた構成 RDBMS NewSQL ‧マスターが更新ログを送って同期 ※もしくはStorage共有など ‧読取り:リードレプリカで負荷分散 ‧書込み:マスター ※ボトルネック ‧Shared-nothing:データを分割管理 ※各ノード(リーダー)で書込み/読取 ‧ノード追加により、  読み書き共にスケール App マスター リードレプリカ Read Only Read/Write App マルチマスター Read/Write リーダー フォロワー
14. TiDBのアーキテクチャー ⽔平⽅向に スケール ※垂直も可 ※ワンアクションで TiDB = コンピューティング ‧Parser / Optimizer etcを担う ※都合の良いストレージコンポーネントからデータを読む TiKV = ストレージ（Row型） ‧ACIDトランザクションを提供する分散KVS ※NewSQL的なStorage TiFlash = ストレージ（Column型） ‧列形式のデータストア ‧オプショナルで追加 ※HTAP PD = 司令塔 ‧データの物理的な配置情報管理 ‧グローバルで⼀意なタイムスタンプ発⾏
15. TiDBのアーキテクチャー ⽔平⽅向に スケール ※垂直も可 ※ワンアクションで
16. データ管理の仕組み Autoシャーディング ∴設計‧実装の考慮不要 • Raftグループを形成(Multi-Raft) ◦ Leader ：読み書き対象 （１つ） ◦ Follower ：バックアップ （２つ） ◦ Learner ：カラムナ側 （１＋ ） • Region単位で管理 ◦ PKなどのRangeで分割 ◦ デフォルト96MBを軸に⾃動分割
17. データ管理の仕組み Autoシャーディング ∴アプリケーション側での実装不要
18. こんなときは？ 障害起きた。。。 バージョンアップしたい（しなきゃ） スケールさせたい Leaderの役割が移動 ダウンタイムなし
19. TiDBのラインナップ • Serverless ◦ クラウド型フルマネージド ◦ マルチテナント • Dedicated ◦ クラウド型フルマネージド ◦ お客様毎の専⽤VPC内にTiDB構築 • Self-Hosted ◦ OSSバージョンのTiDB ◦ 様々な環境/構成で構築可能 マルチAZ 構成
20. プロデューサー プランナー エンジニア つまり、ゲームの設計‧開発〜運⽤の過程で エンジニアリング的にもビジネス的にもメリットが？！ 今まで　※シャーディング TiDBなら ワールド限界 ※ゲーム性の幅 サービスを停めたくない 予想外れ機会損失/コスト⾼ 実装の複雑化 メンテナンス⼤変 シャーディング不要な実装 ※慣れ親しんだMySQL互換 ワンポチで⾃在なスケール 障害/バージョンアップ時も サービス継続
21. 「脱シャーディング」とは  少し違う⾓度から
22. こんなことにもお困りでは？ プランナーさん （多数派：SQL書けない）  ビジネス判断のためデータを早く欲しい • 今⽉の売上げを⽇別にまとめて • 継続率を1⽇・3⽇・7⽇・30⽇で⽇毎にまとめて • 3万円以上課⾦して⼀週間以上ログインしていな いユーザーのレベルを教えて • 第三ステージのクリア時のLvと戦⼒を教えて エンジニアさん （多数派：SQL書ける） やるべきことはたくさん （正直めんどくさい）
23. これまでのやり⽅ではこんな懸念が？ • DB負荷 取得すべきデータが本番にしかない →よろしくないクエリを投げてしまう恐れ ∴ゲームユーザーに影響？！ • データ DWHなどにETL通じて連携 ∴構築/運⽤コストかかる ∴データ鮮度も落ちる • SQL ⾃然⾔語をSQLにエンジニアが変換 ∴⼿間
24. TiDBだと • DB負荷 Resource Control機能 ∴影響気にしない • データ • SQL • 活⽤するリソースをユーザー単位で制限 →分析クエリ発⾏者には制限をかけることで、ゲームユー ザへの影響を減らす
25. TiDBだと • DB負荷 Resource Control機能 ∴影響気にしない • データ TiFlashに追加により ∴TiDBで完結 ∴データ鮮度良好 • SQL Chat2Query機能で⾃然⾔語をSQLに変換 ∴プランナー⇔エンジニアのパス不要 ※APIもあり
26. デモンストレーションサイト Chat2QueryのAPIを活⽤した 対話型ダッシュボード TiDBにGithubのデータ（現在60億超えのレコー ド数）を取り込み、Webページからクエリを発 ⾏、分析を可能としているサイトです。 Githubのリアルタイムイベントを取り込むOLTP を実⾏しながら、各種ダッシュボードなどの OLAPタスクを同時に実⾏するインターネット情 報サイトのデモになっています。 OSS Insight https://ossinsight.io/

27. プロデューサー プランナー エンジニア つまり、ゲーム運営に関わるビジネス的な判断のための分析において やっぱりエンジニアリング的にもビジネス的にもメリットが？！ 今まで TiDBなら 依頼した情報を早く確認し て、⽅向性を早く決めたい 依頼にすぐに答えたいけど、 運⽤で⼿⼀杯‧‧‧ HTAPやAIなどTiDBの機能 をフル活⽤で解決！！！
28. CONTINUE
29. 脱シャーディング！！ NewSQLのTiDBで実現 ~楽しいね！を世界中の⽇常へお届けするために エンジニアリングで⾏ったこと~ 中⼭ 智義 ワンダープラネット株式会社 エンジニアリング＆デザインマネジメント室 テックリード
30. © WonderPlanet Inc. 30 アジェンダ TiDBの活用について • 会社/自己紹介 • 抱えていた課題 • これまでの対策 • TiDBの期待と検証 • TiDBの活用方法 • 採用に関するワンポイント
31. © WonderPlanet Inc. 31 自己紹介 中山 智義（Tomoyoshi Nakayama） ワンダープラネット株式会社 エンジニアリング＆デザインマネジメント室テックリード - 全社的なサーバー/インフラの課題解決 - プロジェクト支援
32. © WonderPlanet Inc. 私たちの使命は、世界中の一人でも多くの人々の日常に、 家族や友達と「楽しいね！」と笑いあえるひとときを届けることです。 国・言語・文化・年齢・性別などあらゆる壁を越えて誰もが楽しめる プロダクト・サービスを創り、コミュニケーションを通じた 「笑顔」を世界の隅々まで広げていきます。 ミッション 32
33. © WonderPlanet Inc. 33 主要タイトル概要と注力分野 アリスフィクション クラッシュフィーバー ジャンプチ ヒーローズ 新規タイトル開発 【タイトル概要】 ・2015/7リリース ・運営8年目 ・日本版、海外版を運営中 【タイトル概要】 ・2018/3リリース ・運営5年目 ・日本版、繁体字版を運営中 【タイトル概要】 ・2022/7リリース ・全世界同時配信・同時運営 全世界同時運営 全世界1400万DL 全世界2000万DL ギネス記録認定 自社開発タイトル（オリジナル） 自社開発タイトル（IP） 新規事業領域参入 コンシューマー系ゲーム開発会社との 共同事業新規タイトルを準備中
34. 34 抱えている課題
35. © WonderPlanet Inc. 35 データベースへの課題感 ゲームサービスの運営をしているとデータベースに課題が出てくる パフォーマンスの劣化に繋がる 急な負荷にデータベースが対応できない データが貯まり続ける
36. © WonderPlanet Inc. 36 これまで取ってきた対策 - 1 Amazon Auroraを活用してWrite/Readでクエリの接続先を分ける - Readレプリケーションにはスケール性がある - ストレージの自動拡張が可能 Writeはスケールしないので他の対策が必要 - ゲームサービスは書き込みクエリ量が多い
37. © WonderPlanet Inc. 37 これまで取ってきた対策 - 2 更にNoSQLを活用する - 低レイテンシ・高スケーラビリティ メインDBとして運用するのが厳しく、サブシステムやキャッシュに活用 - 一貫性の担保、保守性、学習コストに課題あり
38. © WonderPlanet Inc. 38 これまで取ってきた対策 - 3 更にデータベースの垂直分割・水平分割（シャーディング）を行う - 後から実施するのは大変なので、開発中から対応したい 垂直分割 シャーディング
39. © WonderPlanet Inc. 39 そもそもデータベース分割は複雑で難度が高い どのように分割するかの設計が難しい - 分割の仕方が良くないとデータの取り回しが悪くなり処理が複雑になる - 全シャードを探索する必要があるとパフォーマンスが落ちる データベースが分割されていることを念頭に置いた開発・実装が難しい - どのデータベースにどのデータが入っているかを把握する必要がある - Write - Readのレプリケーション遅延を考慮する必要がある 分割されたデータベースを運用することが難しい - 想定通りのユーザー数にならず分割が無駄・負債になったり分割数を増やす必要が出る - データの偏りが発生しシャードの振り分け方法を最適化する必要が出る - 分析・集計処理やデータ修正が複雑・困難 - シャード分割起因の不具合や障害が発生する etc...
40. © WonderPlanet Inc. 40 そもそもデータベース分割は複雑で難度が高い どのように分割するかの設計が難しい - 分割の仕方が良くないとデータの取り回しが悪くなり処理が複雑になる - 全シャードを探索する必要があるとパフォーマンスが落ちる データベースが分割されていることを念頭に置いた開発・実装が難しい - どのデータベースにどのデータが入っているかを把握する必要がある - Write - Readのレプリケーション遅延を考慮する必要がある 分割されたデータベースを運用することが難しい - 想定通りのユーザー数にならず分割が無駄・負債になったり分割数を増やす必要が出る - データの偏りが発生しシャードの振り分け方法を最適化する必要が出る - 分析・集計処理やデータ修正が複雑・困難 - シャード分割起因の不具合や障害が発生する ゲームの楽しさ作りに集中できない！ etc...
41. 41 TiDBの期待と検証
42. © WonderPlanet Inc. 42 負荷分散・シャーディング周りの課題が解消できそう！ 内部的に分割されているだけで 
 外からは1つのデータベースとして扱える 
 TiDB Writeもスケールアウトが可能
 - 簡単に負荷分散できる
 
 自動シャーディング
 - データ配置を意識しなくて良い 
 
 MySQL互換
 - これまでの資産が無駄にならない 
 
 Cloudネイティブ
 - サーバ管理から解放される
 
 データベース分割周りの問題が解決！ 

43. © WonderPlanet Inc. 43 TiDB Cloudの検証 TiDB Cloudはゲームサービスの運用に耐えられるのか？の観点でAuroraと比較検証 • 処理性能 ◦ 通信レイテンシはどうか ◦ クエリ処理速度はどうか ◦ 負荷耐性はどうか • 拡張性 ◦ 運用中に非停止でDDL適用することができるか ◦ 運用中に非停止でスケールすることができるか ◦ コネクション管理はどうか ◦ スケールが許容できるコスト感か • 機能 ◦ MySQL互換性は十分か ◦ 復旧機能（バックアップやリストア性能）は十分か ◦ ログや統計情報など、運用のための情報を取得できるか
44. © WonderPlanet Inc. 44 TiDBとAuroraの比較：処理性能 Amazon Aurora TiDB 通信レイテンシ ◯ ◯: Auroraと同程度 レプリケーション 遅延あり 遅延なし 単体のクエリ処理速度 ◯ △: 10~20%ほどビハインド 負荷耐性 △: EngineCPU90%でエラーが出始める ◯: 速度遅延していくのみ
45. © WonderPlanet Inc. 45 通信レイテンシについて TiDB CloudはAWS(or GCP)上に構築でき、Auroraと同程度の速度で処理可能 - AWSは東京リージョン（ap-northeast-1）あり - VPC PeeringやPrivate Endpointを構成可能
46. © WonderPlanet Inc. 46 クエリ処理速度について TiDB CloudはLB, TiKVが別Availability Zoneに あるため通信コストが掛かる - 軽いクエリはネットワークのレイテンシで不利 I/Oコスト優位な本番ワークロードで改善の見込み - リリース前負荷試験で測定予定
47. © WonderPlanet Inc. 47 負荷耐性について 
 
 
 
 TiDB Cloudに負荷を掛けて検証 - 平均100ms位掛かるデータとクエリ CPU使用率90%辺りでQPSが上昇しなくなる - 以降はレスポンス時間が伸びていった - ~2000msまで観測 - エラー率は0% スロットリングせずクエリ処理時間が伸びる ような挙動
48. © WonderPlanet Inc. 48 TiDBとAuroraの比較：拡張性 Amazon Aurora TiDB 非停止DDL適用 ◎: Fast DDLあり ◯ スケールアウト △: Readerのみ、Writeは不可 ◯ スケールイン ◯ ◯: コネクション再接続が必要 スケールアップ / ダウン △: 停止が必要 ◯: コネクション再接続が必要 コネクション数 △: メモリサイズ依存 ◯: 上限なし 1ノードあたりの費用 △: 高め △: 高め 最小コスト 1ノード分の費用 Serverless：従量、Freeあり Dedicated：TiDB x1, TiKV x3 ストレージ拡張 ◎: 自動 ◯: 容量指定
49. © 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コストなどが掛かるので読みにくい
50. © WonderPlanet Inc. 50 コスト面について - 2 2023/07/06にServerless Tierが一般提供開始 - マルチテナント型の従量課金 - 現時点(2023/08/24)ではAWSクラウドのみ 無料クォータがあり開発や検証に利用しやすい - 小規模な開発なら無料枠に収まる
51. © 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 メトリクス監視 ◯ ◯ アラート ◯ △: 自由に設定するには外部ツール必要 クエリ分析 ◯ ◯
52. © WonderPlanet Inc. 52 MySQL互換性について MySQLの全ての機能をサポートしていない - ストアドプロシージャと関数 - トリガーやイベント 　　： MySQLと挙動が異なる機能がある - AUTO_INCREMENT - EXPLAIN - DDLの制限 　　： データベース機能を使わないシンプルなクエリであれば影響は小さい - あるゲームのデータベースをTiDBにリストアして結合試験し、MySQLと同じ結果を得た
53. © WonderPlanet Inc. 53 TiDBの特徴まとめ シャーディング対応する規模で高頻度でスケーリングするサービスに向いている - シャーディング不要・レプリケーション遅延問題が発生しない - 非停止でDDL適用やスケーリング可能 - コストや処理性能はAuroraと同等程度 ネットワークレイテンシの観点でマイクロ秒レベルの最適化が必要なサービスは不利 →ワンダープラネットのゲームプロダクトに合致
54. 54 TiDBの活用について
55. © WonderPlanet Inc. 55 活用状況 検証の結果、開発中タイトルへ導入することに - シャーディングしないで済む管理・運用コストの改善が魅力 - ビジネススケールに合わせて直ぐスケーリングできる - 特にリリース時や大規模イベントといった負荷を読みにくいタイミングに効果を期待 - 最悪MySQL (Amazon Aurora) に戻せるように互換性を保っておく - ローカル開発時はMySQL、開発環境はTiDB Cloud 細かい課題はありつつ、概ね問題なく動作している
56. © WonderPlanet Inc. 56 採用に関するワンポイント - 機能 MySQLとの細かい違いに注意が必要 - MySQLをStrict Modeで動かしておらず、移行時にDEFAULT・NULL値周りでトラブル AUTO_INCREMENTは非推奨 - ホットスポットを誘発しやすくなりパフォーマンス劣化の原因になってしまう - ワンダープラネットではアプリケーション側でUUIDを採番している スケーリングの際にコネクションが切れる - アプリケーション側でハンドリングして自動リトライを入れた - TiDB Cloud側でプロキシを前段に立てる改善予定とのこと
57. © WonderPlanet Inc. 57 採用に関するワンポイント - 運用 物理DDL適用に時間が掛かる - 論理DDLと物理DDLがありインデックス追加などが物理DDL - オンラインで実行できるものの、MySQLより時間が掛かる TiDB Cloud Serverlessが便利 - ちょっとした検証のために立てて繋ぐことができる - ローカルでもDocker上でTiDBを構築できるがちょっと重い TiDB自体のバージョンアップによる機能改善サイクルが早い - LTSを約6ヶ月毎にリリースするサイクル - 検証中にバージョンが上がってスケール性が向上した - 速度改善や独自機能の追加も盛ん
58. © WonderPlanet Inc. 58 採用に関するワンポイント - サポート ドキュメントが豊富 - 前述のMySQL互換やAUTO_INCREMENTなど、つまづいたところは大体解説 されている - バージョン更新に伴ってドキュメントも更新されていく - Youtubeで基本的な仕組みから詳細な機能まで解説されている - GitHubにコードが公開されている サポートが手厚い - 前述の課題はPingCAP社に相談して解決や回避策を取っている
59. 59 まとめ
60. © WonderPlanet Inc. 60 まとめ ワンダープラネットではデータベースのシャーディングに課題感を持っていた - 設計・開発・運用どのタイミングでも問題が起こりやすい TiDBを検証して、開発中プロダクトへの導入を決定 - ビジネススケールに合わせてインフラサイズを調整しやすい - 複雑なデータベース分割から解放されインフラ管理工数の削減が期待できる 複雑なシャーディングを考えずにゲームの楽しさ作りに集中できるように！
61. 61 ご清聴ありがとうございました！ 最後に・・・
62. アンケートのお願い QRコードを読み込んでアンケートにご回答ください。 回答者にはTiDB資格試験無料パスをもれなく全員にプレゼントいたします。オンライン参加者の⽅ は、資格試験パスの他に「PingCAPオリジナルTシャツ」または「Software Design 2023年8⽉号」 の中から1点ご選択ください。※回答期限は2023年8⽉24⽇(⽊) 午後14:00まで。 会場参加の⽅ オンライン参加の⽅ TiDB資格試験無料パス
63. THANK YOU. もっとくわしく？ → つづける（Ask The Speakerへ）   やめる