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 :読み書き対象 (1つ) ○ Follower :バックアップ (2つ) ○ Learner :カラムナ側 (1+ ) ● 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

© WonderPlanet Inc. 30 アジェンダ TiDBの活用について ● 会社/自己紹介 ● 抱えていた課題 ● これまでの対策 ● TiDBの期待と検証 ● TiDBの活用方法 ● 採用に関するワンポイント

Slide 31

Slide 31 text

© WonderPlanet Inc. 31 自己紹介 中山 智義(Tomoyoshi Nakayama) ワンダープラネット株式会社 エンジニアリング&デザインマネジメント室テックリード - 全社的なサーバー/インフラの課題解決 - プロジェクト支援

Slide 32

Slide 32 text

© WonderPlanet Inc. 私たちの使命は、世界中の一人でも多くの人々の日常に、 家族や友達と「楽しいね!」と笑いあえるひとときを届けることです。 国・言語・文化・年齢・性別などあらゆる壁を越えて誰もが楽しめる プロダクト・サービスを創り、コミュニケーションを通じた 「笑顔」を世界の隅々まで広げていきます。 ミッション 32

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

© WonderPlanet Inc. 35 データベースへの課題感 ゲームサービスの運営をしているとデータベースに課題が出てくる パフォーマンスの劣化に繋がる 急な負荷にデータベースが対応できない データが貯まり続ける

Slide 36

Slide 36 text

© WonderPlanet Inc. 36 これまで取ってきた対策 - 1 Amazon Auroraを活用してWrite/Readでクエリの接続先を分ける - Readレプリケーションにはスケール性がある - ストレージの自動拡張が可能 Writeはスケールしないので他の対策が必要 - ゲームサービスは書き込みクエリ量が多い

Slide 37

Slide 37 text

© WonderPlanet Inc. 37 これまで取ってきた対策 - 2 更にNoSQLを活用する - 低レイテンシ・高スケーラビリティ メインDBとして運用するのが厳しく、サブシステムやキャッシュに活用 - 一貫性の担保、保守性、学習コストに課題あり

Slide 38

Slide 38 text

© WonderPlanet Inc. 38 これまで取ってきた対策 - 3 更にデータベースの垂直分割・水平分割(シャーディング)を行う - 後から実施するのは大変なので、開発中から対応したい 垂直分割 シャーディング

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

© WonderPlanet Inc. 44 TiDBとAuroraの比較:処理性能 Amazon Aurora TiDB 通信レイテンシ ◯ ◯: Auroraと同程度 レプリケーション 遅延あり 遅延なし 単体のクエリ処理速度 ◯ △: 10~20%ほどビハインド 負荷耐性 △: EngineCPU90%でエラーが出始める ◯: 速度遅延していくのみ

Slide 45

Slide 45 text

© WonderPlanet Inc. 45 通信レイテンシについて TiDB CloudはAWS(or GCP)上に構築でき、Auroraと同程度の速度で処理可能 - AWSは東京リージョン(ap-northeast-1)あり - VPC PeeringやPrivate Endpointを構成可能

Slide 46

Slide 46 text

© WonderPlanet Inc. 46 クエリ処理速度について TiDB CloudはLB, TiKVが別Availability Zoneに あるため通信コストが掛かる - 軽いクエリはネットワークのレイテンシで不利 I/Oコスト優位な本番ワークロードで改善の見込み - リリース前負荷試験で測定予定

Slide 47

Slide 47 text

© WonderPlanet Inc. 47 負荷耐性について 
 
 
 
 TiDB Cloudに負荷を掛けて検証 - 平均100ms位掛かるデータとクエリ CPU使用率90%辺りでQPSが上昇しなくなる - 以降はレスポンス時間が伸びていった - ~2000msまで観測 - エラー率は0% スロットリングせずクエリ処理時間が伸びる ような挙動

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

© WonderPlanet Inc. 50 コスト面について - 2 2023/07/06にServerless Tierが一般提供開始 - マルチテナント型の従量課金 - 現時点(2023/08/24)ではAWSクラウドのみ 無料クォータがあり開発や検証に利用しやすい - 小規模な開発なら無料枠に収まる

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

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

Slide 63

Slide 63 text

THANK YOU. もっとくわしく? → つづける(Ask The Speakerへ)   やめる