「最高のコンテンツ」を支える、Cygamesのデータベース技術の今までとこれから 〜次世代データベース「TiDB」の検証を開始したCygamesの取り組み〜

2022/11/18 db tech showcase 2022 Tokyo

Transcript

1. データ管理・運⽤ノウハウ
   〜次世代データベース「TiDB」の検証を開始したCygamesの取り組み〜
   株式会社Cygames サーバーサイド ⼤橋 庸 / CTO室 浦⾕ 和茂
   「最⾼のコンテンツ」を⽀える、
   Cygamesのデータベース技術の今までとこれから
   

   View Slide

2. 2/140
   Cygamesについて
   

   View Slide

3. 3/140
   Cygamesについて
   「最⾼のコンテンツを作る会社」
   

   View Slide

4. 4/140
   Cygamesについて
   ソーシャルゲームをはじめ
   コンシューマーゲーム・アニメ
   e-sportsなど
   

   View Slide

5. 5/140
   アジェンダ
   TiDBへの取り組み
   Chapter1
   Chapter2
   データベース技術の今とこれから
   

   View Slide

6. 6/140
   データベース技術の今とこれから
   Chapter1
   

   View Slide

7. 7/140
   ⼤橋 庸
   サーバーサイド / サブマネージャー
   2014年株式会社Cygamesへ⼊社
   「グランブルファンタジー」サーバーサイドサブリーダー
   ユーザー体験の向上を通じて「最⾼のコンテンツ」をユーザーの皆様に
   届けるべく、アプリケーション/データベースそれぞれのレイヤにおける
   負荷対策と、運⽤で⽣じる様々なトラブルや課題の解決に従事
   ⾃⼰紹介
   

   View Slide

8. 8/140
   1. サーバーサイドのミッション
   2. 現⾏アーキテクチャ概要
   3. 現⾏アーキテクチャの改善ポイント
   4. チャレンジを⽀えるマインド
   5. まとめ
   データベース技術の今とこれから
   

   View Slide

9. 9/140
   1. サーバーサイドのミッション
   2. 現⾏アーキテクチャ概要
   3. 現⾏アーキテクチャの改善ポイント
   4. チャレンジを⽀えるマインド
   5. まとめ
   データベース技術の今とこれから
   

   View Slide

10. 10/140
    サーバーサイドのミッション
    https://speakerdeck.com/cygames/kuranhuruhuantasiwozhi-eruinhurafalseji-shu
    安定とモダンな技術の導⼊の両⽴がチャレンジ
    そのマインドが「最⾼のコンテンツ」を⽀える源
    最⾼のユーザー体験を⽣み出すために
    安定・⾼速・スケーラブルなサーバーシステムの構築
    聖域を設けずに、モダンな技術の検証/導⼊をしていく
    インフラ視点の資料は「グランブルーファンタジーを⽀えるインフラ技術」をご覧ください
    

    View Slide

11. 11/140
    1. サーバーサイドのミッション
    2. 現⾏アーキテクチャ概要
    3. 現⾏アーキテクチャの改善ポイント
    4. チャレンジを⽀えるマインド
    5. まとめ
    データベース技術の今とこれから
    

    View Slide

12. 12/140
    現⾏アーキテクチャ概要
    MySQL RDBMS
    基本的なアーキテクチャ
    ⽔平分割 シャーディング
    垂直分割
    レプリケーション＋MHAクラスター構成
    構成のイメージ
    を利⽤
    MHA
    Cluster1
    MHA
    ClusterN
    ………
    Primary sharding
    Online DB/OLTP
    Secondary sharding
    Hot Stand by/OLAP
    Tertiary sharding
    Backup/For data lake
    For Cold Backup
    Powered by MySQL MHA
    Cluster2
    Replication
    Replication
    メンテナンス
    (サービス停⽌)
    スケールアウト
    データリバランス
    バランシングルール更新
    

    View Slide

13. 13/140
    ソースコードレベルで研究
    データモデル設計
    モニタリング/チューニング
    ロードテスト
    MySQLの性能を引き出すチャレンジについて
    社内勉強会 etc
    体系化（フレームワーク）
    ⽇々様々なチームで改善を継続することで
    「安定・⾼速」なサーバーシステムを実現している
    現⾏アーキテクチャ概要
    今後もMySQLを利⽤していく
    

    View Slide

14. 14/140
    1. サーバーサイドのミッション
    2. 現⾏アーキテクチャ概要
    3. 現⾏アーキテクチャの改善ポイント
    4. チャレンジを⽀えるマインド
    5. まとめ
    データベース技術の今とこれから
    

    View Slide

15. 15/140
    現⾏アーキテクチャの改善ポイント
    サーバー構築
    サーバーサイドのミッション
    「スケーラブル」に関して課題
    安 定 ⾼ 速 スケーラブル な
    

    View Slide

16. 16/140
    現⾏アーキテクチャの改善ポイント
    現⾏アーキテクチャでは解決困難なもの
    シームレスなスケーリング
    リソースごとのスケーリング
    弊社で直⾯した「スケーラブル」が満たせてない事例を紹介
    

    View Slide

17. 17/140
    現⾏アーキテクチャの改善ポイント
    メンテナンス時はサービス停⽌
    サービスの予想以上の急成⻑で
    ⻑時間に渡るメンテナンス
    サービス停⽌を減らし、よりよい最⾼のユーザー体験を⽣み出す
    ※ オンラインメンテナンスは、求められるレイテンシなど状況次第で可能ではある
    シームレスなスケーリングが極めて困難
    ユーザー体験の阻害に
    なぜ
    改善
    

    View Slide

18. 18/140
    現⾏アーキテクチャの改善ポイント
    求めてる要件
    オンラインでスケールが可能で、
    データの不整合が発⽣しない
    （⾃動でデータリバランスも）
    MySQL
    ユーザーがデータベースに書き込み時に
    不整合が発⽣するのでスケール時に
    サービスを停⽌する必要がある
    コンピューティング
    ノード
    ＋
    ストレージノード
    コンピューティング
    ノード
    ストレージノード
    シームレスなスケーリング
    

    View Slide

19. 19/140
    現⾏アーキテクチャの改善ポイント
    リソースごとに動的に変更すれば最適化が期待できる
    最適化できたコストを「楽しさ」の追求に還元したい
    なぜ
    改善
    リソースごとのスケールが出来ない
    計算資源やストレージなど
    リソースごとのスケール×
    リソース利⽤が⾮効率な状況
    運⽤期間に伴い
    データ量増加
    

    View Slide

20. 20/140
    現⾏アーキテクチャの改善ポイント
    求めてる要件
    計算資源とストレージのノードが
    分離している
    MySQL
    計算資源とストレージが結合している
    コンピューティング
    ノード
    ＋
    ストレージノード
    コンピューティング
    ノード
    ストレージノード
    リソースごとのスケール
    

    View Slide

21. 21/140
    MySQL互換
    オープンソース
    多様な運⽤環境（オンプレ・クラウド）
    クラウド環境ではフルマネージドも選択可能
    現⾏アーキテクチャの改善ポイント
    その他求めてる要件
    

    View Slide

22. 22/140
    現⾏アーキテクチャの改善ポイント
    選択した
    ソリューション
    

    View Slide

23. 23/140
    1. サーバーサイドのミッション
    2. 現⾏アーキテクチャ概要
    3. 現⾏アーキテクチャの改善ポイント
    4. チャレンジを⽀えるマインド
    5. まとめ
    データベース技術の今とこれから
    

    View Slide

24. 24/140
    チャレンジを⽀えるマインド
    我々は10年以上MySQLを利⽤し
    チャレンジとチューニングを繰り返してきた
    データベースの変更におよぶ技術検証
    ⽇々様々なチームで改善を継続し
    「安定・⾼速」なサーバーシステムを実現
    データベースの変更におよぶ技術検証は
    極めて⼤きなチャレンジ
    

    View Slide

25. 25/140
    チャレンジを⽀えるマインド
    ⼤きなチャレンジを⽀える４つのマインド
    聖域を作らない
    いかなるレイヤーにおいても
    より改善していく
    現象と原因
    現象を正確に把握する
    根本的な原因を追求する
    変化に追従
    ビジネス・ユーザー・技術など
    変化に対して柔軟に追従する
    適切な⼿段を選択
    選択⼿段を評価し最適解を導く
    

    View Slide

26. 26/140
    1. サーバーサイドのミッション
    2. 現⾏アーキテクチャ概要
    3. 現⾏アーキテクチャの改善ポイント
    4. チャレンジを⽀えるマインド
    5. まとめ
    データベース技術の今とこれから
    

    View Slide

27. 27/140
    Chapter1まとめ
    最⾼のユーザー体験を⽣み出すために
    安定・⾼速・スケーラブルなサーバーシステム構築
    聖域を設けずに、モダンな技術の検証/導⼊をしていく
    課題を解決する最適なソリューションはTiDB
    データベース技術の今とこれから
    シームレスなスケーリング
    リソースごとのスケーリング
    現⾏アーキテクチャで課題となる２つのスケーリング
    MySQLで「安定・⾼速」なサーバーシステムを実現
    チャレンジを⽀える４つのマインド
    

    View Slide

28. 28/140
    TiDBへの取り組み
    Chapter2
    

    View Slide

29. 29/140
    浦⾕ 和茂
    CTO室 / Senior Database Administrator
    2013年株式会社Cygamesへ⼊社
    CTO室所属のDBAとして
    Cygamesの新規プロジェクトから既存のプロジェクトまで
    全タイトルの基幹データベースの構築と改善を横断的に担当
    ⾃⼰紹介
    

    View Slide

30. 30/140
    1. TiDBを選択した理由
    2. TiDBの検証
    3. TiDBにおけるその他取り組み
    Chapter2 アジェンダ
    おまけ
    ・TiDBの環境構築について ・検証環境構築の⾃動化について
    ・ダミーQUERYの増幅について
    セッション発表対象外
    

    View Slide

31. 31/140
    TiDBアーキテクチャー（チュートリアル）
    その前に‼
    

    View Slide

32. 32/140
    https://docs.pingcap.com/tidb/stable/tidb-architecture
    TiDBのアーキテクチャー（チュートリアル）
    TiDBのアーキテクチャーのイメージ
    

    View Slide

33. 33/140
    TiDBのアーキテクチャー（チュートリアル）
    PD cluster
    PD serverの
    クラスター構成
    クラスター全般の管理を
    ⾏う頭脳
    領域管理のレイヤー
    

    View Slide

34. 34/140
    SQLを解析するレイヤー
    TiDBのアーキテクチャー（チュートリアル）
    TiDB cluster
    TiDB serverの
    クラスター構成
    Parser・Optimizer・
    Executor等の機能がある
    

    View Slide

35. 35/140
    TiDBのアーキテクチャー（チュートリアル）
    Storage cluster
    TiKV serverと
    TiFlash serverの
    クラスター構成
    Key-Valueと列指向の構造で
    データを永続化する
    データストアのレイヤー
    

    View Slide

36. 36/140
    必要に応じてpluggableに
    TiFlashやTiSpark等を追加
    TiDBのアーキテクチャー（チュートリアル）
    TiDBの基本構成
    PD・TiDB・TiKV
    

    View Slide

37. 37/140
    TiDBを選択した理由について
    

    View Slide

38. 38/140
    CygamesではMySQLを使⽤している
    サーバーリソースをより上⼿く使⽤したい
    ユーザーがより安⼼して遊べる環境を構築する
    チャレンジ‼
    TiDBを選択した理由について
    

    View Slide

39. 39/140
    CygamesではMySQLを使⽤している
    TiDBはMySQLのインターフェースをそのまま使⽤できる
    MySQL（MySQL5.7）との互換性が⾼くMySQLを扱っている
    アプリケーション開発者としては扱いやすい
    アプリケーション開発者がバックエンドの仕組みを
    意識することなく今まで通り使⽤できる
    TiDBを選択した理由について
    

    View Slide

40. 40/140
    CPUリソース あるいはストレージの容量だけ
    ⾜りないサーバー等の偏りがある
    サーバーによって
    リソースの使われ⽅が異なるため
    バランスよくリソースが使⽤出来ないか
    サーバーリソースをより上⼿く使⽤したい
    課 題
    TiDBを選択した理由について
    

    View Slide

41. 41/140
    TiDBを選択した理由について
    TiDB（マイクロな構成）
    コンピューティングノードと
    ストレージノードが疎結合なため
    独⽴したスケールが可能
    MySQL（モノリスな構成）
    サーバーリソースが密結合なため
    リソースをセットで
    スケールさせる必要がある
    この中に⽂字
    を打ち込む
    必要なリソースに
    ターゲットを絞って
    スケールできない
    それぞれ
    単独で
    スケールできる
    コンピューティング
    ノード
    ストレージノード
    

    View Slide

42. 42/140
    TiDBは必要なリソースにターゲットを絞って
    スケールできるためバランスよくリソースを使⽤できる
    特にTiDB serverはステートレスであり
    必要に応じてより柔軟にスケールできるため
    コスト削減にも期待できる
    サーバーリソースをより上⼿く使⽤したい
    TiDBを選択した理由について
    解 決
    

    View Slide

43. 43/140
    TiDBはクラスター構成のため
    ノーメンテナンスでスケールできる
    メンテナンスをなくし
    24時間365⽇遊べる環境を構築できる
    ユーザーがより安⼼して遊べる環境を構築する
    TiDBを選択した理由について
    

    View Slide

44. 44/140
    ユーザーがより安⼼して遊べる環境を構築する
    TiDBを選択した理由について
    TiKV cluster
    各クラスターは
    独⽴しているため
    必要に応じて柔軟に
    スケール出来る
    スケールアウト
    スケールイン
    TiKV cluster
    

    View Slide

45. 45/140
    現在サービスで採⽤している技術は安定し
    信頼性の⾼い技術を取り扱っているが、
    既存技術だけで無くモダンな技術の検証を⾏い
    エンジニアの技術⼒向上と将来のゲーム
    コンテンツへの導⼊を⽬指していきたい
    Cygamesにはチャレンジできる環境がある
    チャレンジ︕︕
    TiDBを選択した理由について
    

    View Slide

46. 46/140
    TiDBの検証について
    

    View Slide

47. 47/140
    TiDBの検証について（サマリ）
    プロジェクトのQUERYを
    どの様に実⾏して
    どの様な検証を⾏ったのか︖
    運⽤プロジェクトのQUERYをサンプルに
    検証は…
    

    View Slide

48. 48/140
    シンプルなQUERYを実⾏
    QUERYの発⾏数は数百万QPSにのぼる
    CygamesのソーシャルゲームにおけるQUERY
    発⾏するQUERYの種類は圧倒的にSELECTのQUERYが多くなります
    使⽤しない︓テーブル結合やサブQUERYなど
    特にイベントやアクティブな時間帯は
    アクセス数 QUERYの発⾏数
    QUERYについて
    

    View Slide

49. 49/140
    QUERYの実⾏に使⽤したツールについて
    検証環境について
    検証データの準備について
    実施した検証について
    TiDBの検証について
    

    View Slide

50. 50/140
    QUERYの実⾏に使⽤したツールについて
    検証環境について
    検証データの準備について
    実施した検証について
    TiDBの検証について
    

    View Slide

51. 51/140
    vegeta-mysqlはGoで実装されたツールで
    ファイルに格納されたQUERYを実⾏して
    指定したサーバーに負荷をかけて
    レポートを出⼒するベンチマークツールです
    vegeta-mysqlを使⽤
    ツール
    TiDBの検証について︓QUERYの実⾏に使⽤したツール
    

    View Slide

52. 52/140
    パラメータ 説明
    pconnect コネクションプーリングの有無
    rate
    QPSをコントロールする場合に使⽤する
    例）1＝1秒間に1リクエスト、10＝1秒間に10リクエスト
    maxOpenConns
    同時接続数（クエリの並列度）
    例）30＝30コネクション接続してクエリを
    同時に実⾏する
    「※pconnect=trueの場合のみ有効」
    maxIdleConns
    maxOpenConnsと同じ値
    「※pconnect=trueの場合のみ有効」
    duration
    実⾏時間
    例）10s=10秒間実⾏した後に処理を終了する
    reporter reporter [text, json, plot, hist[buckets]]
    1秒あたりのリクエスト数
    及び、同時接続数等を
    調整しながら検証する
    TiDBの検証について︓QUERYの実⾏に使⽤したツール
    

    View Slide

53. 53/140
    プロジェクトのQUERYをサンプルにしているためQUERY数を増幅しています
    より多くのQUERYを実⾏するためのアイデアについては「（おまけ）ダミーQUERYの増幅について」
    vegeta-mysqlが１秒間に1000リクエスト、
    同時接続数が200の条件で30秒間指定したQUERYを実⾏する
    TiDB
    vegeta-mysql
    ・rate=1000
    ・maxOpenConns=200
    ・maxIdleConns =200
    ・duration=30
    QUERY
    TiDBの検証について︓QUERYの実⾏に使⽤したツール
    末尾のQUERY実⾏後に
    先頭のQUERYに戻る
    （以降、指定時間分繰り返す）
    

    View Slide

54. 54/140
    Bucket # % Histogram
    [0s, 3s] 558428 88.02% ##################################################################
    [3s, 5s] 41401 6.52% ####
    [5s, +Inf] 34671 5.46% ####
    Histogram
    Plot
    HistogramやPlot等の
    形式でレイテンシを出⼒
    vegeta-mysqlのレポート
    TiDBの検証について︓QUERYの実⾏に使⽤したツール
    

    View Slide

55. 55/140
    QUERYの実⾏に使⽤したツールについて
    検証環境について
    検証データの準備について
    実施した検証について
    TiDBの検証について
    

    View Slide

56. 56/140
    検証環境は
    コンポーネントから
    TiFlash・TiCDCを
    除いた構成
    https://docs.pingcap.com/tidb/stable/hardware-and-software-requirements
    本番環境の推奨事項
    （最⼩要件構成）
    TiDBの検証について︓検証環境
    

    View Slide

57. 57/140
    Component Instance Name Instance Type
    TiDB構成
    PD load-tidb-pd-cluster-0X m5d.2xlarge
    TiDB load-tidb-mysql-cluster-0X m6i.4xlarge
    TiKV load-tidb-tikv-storage-cluster-0X m5d.4xlarge
    モニタリング Monitor load-tidb-monitor m6i.4xlarge
    TiDBの検証環境 インスタンスはAmazon EC2を使⽤
    本番環境の推奨事項と同等のスペック
    TiDB cluster name︓load-tidb-cluster
    TiDB cluster version︓v6.1.0
    Prometheus version︓2.27.1
    Grafana version︓v7.5.11
    TiDBの検証について︓検証環境
    0X＝シャード番号（01、02、03...）
    

    View Slide

58. 58/140
    Component Instance Name Instance Type
    負荷掛け元 majin-vegeta-mysql-0X t3.medium
    QUERYの実⾏に使⽤したツールで説明したvegeta-mysqlの環境
    vegeta-mysqlをスケールさせて魔神の如く負荷を与える仕組みのため
    ツール名をMajin-Vegeta-Mysql（mvm）と名付け
    インスタンスはAmazon EC2を使⽤
    負荷掛け元の環境
    TiDBの検証について︓検証環境
    0X＝シャード番号（01、02、03...）
    

    View Slide

59. 59/140
    QUERYの実⾏に使⽤したツールについて
    検証環境について
    検証データの準備について
    実施した検証について
    TiDBの検証について
    

    View Slide

60. 60/140
    TiDBの検証について︓検証データの準備
    検証データは、各テーブル毎に約100万件準備
    使⽤したテーブルの数は約500
    プロジェクトが実際に使⽤しているデータではなく
    プロジェクトの
    サンプルQUERY
    プロジェクトのデータモデルから⽣成した
    ダミーデータ
    を使⽤
    ダミーデータの⽣成⽅法については「（おまけ）ダミーQUERYの増幅について」
    

    View Slide

61. 61/140
    タイプ ユニークQUERY
    SELECT 291種類
    INSERT 232種類
    UPDATE 175種類
    今回の検証で使⽤したサンプルQUERYの種類
    TiDBの検証について︓検証データの準備
    

    View Slide

62. 62/140
    TiDB DashboardのKey Visualizerを使⽤してデータの登録状況を確認（ヒートマップ）
    https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer
    TiDBの検証について︓検証データの準備
    

    View Slide

63. 63/140
    ⽣成したダミーデータを登録後にデータを増幅
    https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer
    ダミーデータから
    データを増幅
    （SELECT INSERT）
    ❶
    ❷
    ⽣成した
    ダミーデータを
    登録
    TiDBの検証について︓検証データの準備
    

    View Slide

64. 64/140
    同じ100万件でもデータモデルによってRegionの数が異なります
    https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer
    ⽐較的⼩さな
    Regionの数
    ⽐較的⼤きな
    Regionの数
    TiDBの検証について︓検証データの準備
    

    View Slide

65. 65/140
    Regionは
    TiDBデータスケジューリングの最⼩単位であり
    テーブル作成時に1つのRegionが作成される
    Regionのサイズが96MiB以上になると分割し
    20MiB以下になるとマージする
    範囲ベースのシャーディング戦略を取る
    TiDBの検証について︓検証データの準備
    

    View Slide

66. 66/140
    TiDBの検証について︓検証データの準備
    96MiB以上だと分割し20MiB以下だと隣接するRegionをマージする
    TiKV
    Node
    Store
    Increase
    96MiB Split
    Decrease
    20MiB Meage
    Region
    Region
    TiKV
    Node
    Store
    Region
    

    View Slide

67. 67/140
    Key Visualizerを確認することで直感的にテーブルの⼤きさがわかる
    TiDBの検証について︓検証データの準備
    +-----------+------------------------------------------------+------------------------------------------------+
    | REGION_ID | START_KEY | END_KEY |
    +-----------+------------------------------------------------+------------------------------------------------+
    | 1302 | t_713_i_1_04564b3e628350a9830400000000a044f83a | t_713_r_47025 |
    | 1204 | t_713_r_47025 | t_713_r_111668 |
    | 1218 | t_713_r_111668 | t_713_r_191338 |
    | 1220 | t_713_r_191338 | t_713_r_231476 |
    | 1254 | t_713_r_231476 | t_713_r_291338 |
    | 1256 | t_713_r_291338 | t_713_r_331476 |
    | 1266 | t_713_r_331476 | t_713_r_391338 |
    | 1268 | t_713_r_391338 | t_713_r_431476 |
    | 1288 | t_713_r_431476 | t_713_r_491338 |
    | 1290 | t_713_r_491338 | t_713_r_531476 |
    | 1294 | t_713_r_531476 | t_713_r_591338 |
    | 1296 | t_713_r_591338 | t_713_r_631476 |
    | 1322 | t_713_r_631476 | t_713_r_691338 |
    | 1324 | t_713_r_691338 | t_713_r_731476 |
    | 1336 | t_713_r_731476 | t_713_r_791338 |
    | 1338 | t_713_r_791338 | t_713_r_831476 |
    | 1348 | t_713_r_831476 | t_713_r_891338 |
    | 1350 | t_713_r_891338 | t_713_r_931476 |
    | 1360 | t_713_r_931476 | t_713_r_991338 |
    | 1362 | t_713_r_991338 | t_713_r_1031476 |
    | 712 | t_713_r_1031476 | t_715_ |
    | 1340 | t_713_ | t_713_i_1_04564b3e628350a9830400000000a044f83a |
    +-----------+------------------------------------------------+------------------------------------------------+
    22 rows in set (0.04 sec
    +-----------+----------------+----------------+
    | REGION_ID | START_KEY | END_KEY |
    +-----------+----------------+----------------+
    | 1282 | t_775_ | t_775_r_200161 |
    | 774 | t_775_r_200161 | t_777_ |
    +-----------+----------------+----------------+
    2 rows in set (0.01 sec)
    

    View Slide

68. 68/140
    QUERYの実⾏に使⽤したツールについて
    検証環境について
    検証データの準備について
    実施した検証について
    TiDBの検証について
    

    View Slide

69. 69/140
    1. TiDB1台あたりの最適なQPSを⾒つけるための検証
    2. インスタンス最⼩要件の台数で構築して検証
    3. TiDBスケールアウト時に問題ないことを検証
    4. スケールアウト後の環境でQPSが上がることを検証
    TiDBの検証について︓実施した検証
    

    View Slide

70. 70/140
    [1] TiDB1台あたりの
    最適なQPSを⾒つけるための検証
    

    View Slide

71. 71/140
    TiDBの検証について︓実施した検証 [1]
    TiDB server1台あたりの最適なQPSを確認
    この検証での確認（⽬的）
    

    View Slide

72. 72/140
    シングル構成（各1台）で構築
    TiDB1台あたりのQPSを⾒つける検証のため
    シングル構成にしています
    （load-tidb-monitorはイメージでは省略）
    TiDB構成
    load-tidb-pd-cluster-01
    load-tidb-mysql-cluster-01
    load-tidb-tikv-storage-cluster-01
    負荷かけ元は3台準備
    負荷かけ元
    majin-vegeta-mysql-01
    majin-vegeta-mysql-02
    majin-vegeta-mysql-03
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

73. 73/140
    TiDBの検証について︓実施した検証 [1]
    load-tidb-
    mysql-cluster-
    01
    load-tidb-pd-
    cluster-01
    load-tidb-tikv-
    storage-
    cluster-01
    QUERY
    1
    QUERY
    2
    QUERY
    3
    majin-vegeta-
    mysql-02
    majin-vegeta-
    mysql-03
    majin-vegeta-
    mysql-01
    負荷かけ先
    負荷かけ元
    負荷かけ元から
    load-tidb-mysql-cluster-01に対してQUERYを実⾏
    

    View Slide

74. 74/140
    負荷かけ先のTiDBインスタンス（シングル構成）
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

75. 75/140
    1秒間のリクエスト数と同時接続数を
    可変させながら最適なQPSを探し出す
    Levelを変動させながらシナリオを3分実⾏
    「1秒間のリクエスト数=約20000、同時接続数は約900」が最適な負荷
    TiDBの検証について︓実施した検証 [1]
    シナリオを連続実⾏できる仕組みを作成
    [負荷かけ元1台あたりの負荷を設定]
    ・Rate=Rateの変更につき50増分
    ・MaxCon=1レベルあたり10増分
    Level Rate MaxCon
    ------------ ---- ---------
    load_level08218, 6500, 280, 280
    load_level08219, 6500, 290, 290
    load_level08220, 6500, 300, 300
    ・・・
    load_level08291, 6550, 100, 100
    load_level08292, 6550, 110, 110
    load_level08293, 6550, 120, 120
    

    View Slide

76. 76/140
    シナリオを連続実⾏することで
    最適なQPSを探すことができました
    以降、
    シナリオと検証の結果を
    記載します
    シナリオは最適なQPSの前後のシナリオのみ記載
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

77. 77/140
    ・TiDB1台あたりの最適なQPSを⾒つけるためのシナリオです
    ・同時接続数は900固定で１秒間のリクエスト数を変動させます（増分値=150）
    ・負荷掛け元の台数は3台なのでリクエスト数と同時接続数は3倍の値です
    ・シナリオ1-1 ︓1秒間のリクエスト数=6500、同時接続数=300（19500、900）
    ・シナリオ1-2 ︓1秒間のリクエスト数=6550、同時接続数=300（19650、900）
    ・シナリオ1-3 ︓1秒間のリクエスト数=6600、同時接続数=300（19800、900）
    ・シナリオ1-4 ︓1秒間のリクエスト数=6650、同時接続数=300（19950、900）
    ・シナリオ1-5 ︓1秒間のリクエスト数=6700、同時接続数=300（20100、900）
    ・シナリオ1-6 ︓1秒間のリクエスト数=6750、同時接続数=300（20250、900）
    ・シナリオ1-7 ︓1秒間のリクエスト数=6800、同時接続数=300（20400、900）
    ・シナリオ1-8 ︓1秒間のリクエスト数=6850、同時接続数=300（20550、900）
    ・シナリオ1-9 ︓1秒間のリクエスト数=6900、同時接続数=300（20700、900）
    ・シナリオ1-10︓1秒間のリクエスト数=6950、同時接続数=300（20850、900）
    ・シナリオ1-11︓1秒間のリクエスト数=7000、同時接続数=300（21000、900）
    ・シナリオ1-12︓1秒間のリクエスト数=7050、同時接続数=300（21150、900）
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

78. 78/140
    ・QPS約20000のシナリオ1-6が最適なQPSの境界なので⼀部のシナリオを省略します
    ・シナリオ1-1 ︓1秒間のリクエスト数=6500、同時接続数=300（19500、900）
    ・シナリオ1-2 ︓1秒間のリクエスト数=6550、同時接続数=300（19650、900）
    ・シナリオ1-3 ︓1秒間のリクエスト数=6600、同時接続数=300（19800、900）
    ・シナリオ1-4 ︓1秒間のリクエスト数=6650、同時接続数=300（19950、900）
    ・シナリオ1-5 ︓1秒間のリクエスト数=6700、同時接続数=300（20100、900）
    ・シナリオ1-6 ︓1秒間のリクエスト数=6750、同時接続数=300（20250、900）
    ・シナリオ1-7 ︓1秒間のリクエスト数=6800、同時接続数=300（20400、900）
    ・シナリオ1-8 ︓1秒間のリクエスト数=6850、同時接続数=300（20550、900）
    ・シナリオ1-9 ︓1秒間のリクエスト数=6900、同時接続数=300（20700、900）
    ・シナリオ1-10︓1秒間のリクエスト数=6950、同時接続数=300（20850、900）
    ・シナリオ1-11︓1秒間のリクエスト数=7000、同時接続数=300（21000、900）
    ・シナリオ1-12︓1秒間のリクエスト数=7050、同時接続数=300（21150、900）
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

79. 79/140
    レイテンシは
    1msから100msに
    集中しているが
    3秒以内のレイテンシが
    分散してしまう…
    Bucket # % Histogram
    [0s, 1ms] 2703 0.07%
    [1ms, 2ms] 233493 6.41% ####
    [2ms, 3ms] 308158 8.45% ######
    [3ms, 5ms] 162300 4.45% ###
    [5ms, 10ms] 196722 5.40% ####
    [10ms, 20ms] 365855 10.04% #######
    [20ms, 30ms] 434485 11.92% ########
    [30ms, 50ms] 952457 26.13% ###################
    [50ms, 100ms] 876815 24.06% ##################
    [100ms, 200ms] 84012 2.30% #
    [200ms, 300ms] 14597 0.40%
    [300ms, 500ms] 8372 0.23%
    [500ms, 1s] 3757 0.10%
    [1s, 2s] 1034 0.03%
    [2s, 3s] 240 0.00%
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    シナリオ1-6 詳細の結果
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

80. 80/140
    3645000リクエストを3秒以内で100%処理を完了した結果
    レイテンシの判定として100%であればOK
    Bucket # % Histogram
    [0s, 3s] 3645000 100.00% #### ・・・ ####################
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    Bucket # % Histogram
    [0s, 1ms] 2703 0.07%
    [1ms, 2ms] 233493 6.41% ####
    [2ms, 3ms] 308158 8.45% ######
    [3ms, 5ms] 162300 4.45% ###
    [5ms, 10ms] 196722 5.40% ####
    [10ms, 20ms] 365855 10.04% #######
    [20ms, 30ms] 434485 11.92% ########
    [30ms, 50ms] 952457 26.13% ###################
    [50ms, 100ms] 876815 24.06% ##################
    [100ms, 200ms] 84012 2.30% #
    [200ms, 300ms] 14597 0.40%
    [300ms, 500ms] 8372 0.23%
    [500ms, 1s] 3757 0.10%
    [1s, 2s] 1034 0.03%
    [2s, 3s] 240 0.00%
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    レイテンシが3秒以内の場合は
    [0s, 3s]に集約される
    TiDBの検証について︓実施した検証 [1]
    結果を3秒以内に集約して表⽰
    ヒストグラムの結果を
    ⾒やすくするため
    

    View Slide

81. 81/140
    Bucket # % Histogram
    [0s, 3s] 3564000 100.00% #### ・・・ #############################
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    [シナリオ1-3︓19800、900] 19800×180=3564000
    Bucket # % Histogram
    [0s, 3s] 3645000 100.00% #### ・・・ #############################
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    [シナリオ1-6︓20250、900] 20250×180=3645000
    Bucket # % Histogram
    [0s, 3s] 3679982 99.49% #### ・・・ #############################
    [3s, 5s] 10875 0.29%
    [5s, +Inf] 8143 0.22%
    [シナリオ1-8︓20550、900] 20550×180=3699000
    19800
    20250
    20550
    レイテンシが
    ⾼くなり始めている
    TiDBの検証について︓実施した検証 [1]
    期待するQPS
    

    View Slide

82. 82/140
    シナリオ実⾏後のQPSのメトリクス
    シナリオ1-1〜1-12まで連続して実⾏した結果
    Grafana︓TiDB-Summary︓QPS
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

83. 83/140
    1秒間のリクエスト数
    20250に対して
    QPS20300
    結果から現時点では
    最適なQPSは20000
    シナリオ1-6のQPSを拡⼤
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

84. 84/140
    シナリオ実⾏後のCPU Usageメトリクス
    シナリオ1-1〜1-12まで連続して実⾏した結果
    Grafana︓TiDB-Runtime︓CPU Usage
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

85. 85/140
    シナリオ1-6のCPU Usageを拡⼤
    TiDBの検証について︓実施した検証 [1]
    もう少しだけ
    ゆとりを持たせたい
    

    View Slide

86. 86/140
    QPSの結果から
    最適なQPSは20000かと思われたが
    フルに近いリソースを使⽤している
    最適なQPSを確定
    TiDBの検証について︓実施した検証 [1]
    もう少しだけ
    ゆとりを持たせたい
    安全を考慮して20000の80％である
    16000を最適なQPSとした
    

    View Slide

87. 87/140
    Grafana︓TiDB︓Server︓Connection Count
    シナリオ実⾏後のConnection Countメトリクス
    シナリオ1-1〜1-12まで連続して実⾏した結果
    TiDBの検証について︓実施した検証 [1]
    

    View Slide

88. 88/140
    [2]インスタンス最⼩要件の台数で
    構築して検証
    

    View Slide

89. 89/140
    TiDBの検証について︓実施した検証 [2]
    この検証での確認（⽬的）
    スケールアウト実⾏後に
    負荷が減ることを確認
    最⼩要件構成で
    最適なQPS通りになることを確認
    

    View Slide

90. 90/140
    最⼩要件の構成にするためインスタンスを追加
    TiDB構成の台数が増えたため負荷かけ元の台数を増やしています
    TiDBの検証について︓実施した検証 [2]
    TiDB構成
    load-tidb-pd-cluster-01
    load-tidb-pd-cluster-02
    load-tidb-pd-cluster-03
    load-tidb-mysql-cluster-01
    load-tidb-mysql-cluster-02
    load-tidb-tikv-storage-cluster-01
    load-tidb-tikv-storage-cluster-02
    load-tidb-tikv-storage-cluster-03
    TiDBの環境を最⼩要件の構成で構築する
    負荷かけ元
    majin-vegeta-mysql-01
    majin-vegeta-mysql-02
    majin-vegeta-mysql-03
    majin-vegeta-mysql-04
    

    View Slide

91. 91/140
    負荷かけ先のTiDBインスタンス（最⼩要件構成）
    TiDBの検証について︓実施した検証 [2]
    PD2台追加
    TiDB1台追加
    TiKV2台追加
    

    View Slide

92. 92/140
    最⼩要件の構成で台数が増えたため
    スケールアウト実⾏後に負荷が減ることを
    [1]の検証で実施したシナリオを元に再度検証
    TiDB server（load-tidb-mysql-cluster）の台数が
    2倍になったためCPU使⽤率が減ることを確認
    TiDBの検証について︓実施した検証 [2]
    

    View Slide

93. 93/140
    Bucket # % Histogram
    [0s, 3s] 3672000 100.00% #### ・・・ #############################
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    期待するQPS
    20400
    TiDBの検証について︓実施した検証 [2]
    1秒間のリクエスト数=6750、同時接続数=300 20250、900
    QPSが最適なシナリオ
    20400、1800
    1-6
    1台あたりの「load-tidb-mysql-cluster」への負荷 10200、900
    20400、1800
    1秒間のリクエスト数=5100、同時接続数=450
    2-1
    [シナリオ2-2︓21200、1800] 21200×180=3816000
    スケールアウト実⾏後に負荷が減ることを再確認するシナリオ
    負荷掛け元の台数は4台なのでリクエスト数と同時接続数は4倍の値
    

    View Slide

94. 94/140
    Bucket # % Histogram
    [0s, 3s] 3672000 100.00% #### ・・・ #############################
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    期待するQPS
    21200
    TiDBの検証について︓実施した検証 [2]
    1秒間のリクエスト数=7050、同時接続数=300 21150、900
    レイテンシが徐々に落ちるシナリオ
    20400、1800
    1-12
    1台あたりの「load-tidb-mysql-cluster」への負荷 10600、900
    21200、1800
    1秒間のリクエスト数=5300、同時接続数=450
    2-2
    [シナリオ2-2︓21200、1800] 21200×180=3816000
    スケールアウト実⾏後に負荷が減ることを再確認するシナリオ
    負荷掛け元の台数は4台なのでリクエスト数と同時接続数は4倍の値
    

    View Slide

95. 95/140
    最適なQPSを元に
    最⼩要件構成⽤のシナリオを
    追加して検証する
    最適なQPSである16000の2倍である
    32000QPSが出ることを確認する
    TiDBの検証について︓実施した検証 [2]
    

    View Slide

96. 96/140
    Bucket # % Histogram
    [0s, 3s] 5760000 100.00% #### ・・・ #############################
    [3s, 5s] 0 0.00%
    [5s, +Inf] 0 0.00%
    [シナリオ2-3︓32000、1800] 32000×180=5760000
    期待するQPS
    32000
    TiDBの検証について︓実施した検証 [2]
    最⼩要件構成⽤シナリオ シナリオ:2-3
    最適なQPSを元に実⾏する最⼩要件構成⽤のシナリオ
    負荷掛け元の台数は4台なのでリクエスト数と同時接続数は4倍
    1秒間のリクエスト数=8000、同時接続数=450
    1台あたりの「load-tidb-mysql-cluster」への負荷
    32000、1800
    16000、 900
    

    View Slide

97. 97/140
    シナリオ実⾏後のQPSのメトリクス
    シナリオ2-1〜2-3まで連続して実⾏した結果です
    Grafana︓TiDB︓Query Summary︓QPS
    TiDBの検証について︓実施した検証 [2]
    

    View Slide

98. 98/140
    シナリオ2-3のQPSを拡⼤
    期待通りのQPS32000となっています
    TiDBの検証について︓実施した検証 [2]
    

    View Slide

99. 99/140
    シナリオ実⾏後のCPU Usageメトリクス
    シナリオ2-1〜2-3まで連続して実⾏した結果です
    Grafana︓TiDB︓Server︓CPU Usage
    TiDBの検証について︓実施した検証 [2]
    

    View Slide

100. 100/140
     シナリオ2-1、2-2のCPU Usage
     スケールアウト実⾏後に負荷が減ることを確認
     TiDBの検証について︓実施した検証 [2]
     負荷が半減
     

     View Slide

101. 101/140
     シナリオ2-3のCPU Usageを拡⼤
     CPU Usageはゆとりのある使い⽅に
     シナリオ内の
     QUERYの偏りを調整すれば
     リソース使⽤のバランスが
     もっとよくなりそう
     TiDBの検証について︓実施した検証 [2]
     

     View Slide

102. 102/140
     シナリオ実⾏後のConnection Countメトリクス
     シナリオ2-1〜2-3まで連続して実⾏した
     Grafana︓TiDB︓Server︓Connection Count
     TiDBの検証について︓実施した検証 [2]
     

     View Slide

103. 103/140
     シナリオ2-3のConnection Countを拡⼤
     同時接続数が1800であることを確認しました
     Grafana︓TiDB︓Server︓Connection Count
     TiDBの検証について︓実施した検証 [2]
     

     View Slide

104. 104/140
     [3] TiDBスケールアウト時に
     問題ないことを検証
     

     View Slide

105. 105/140
     TiDBの検証について︓実施した検証 [3]
     この検証での確認（⽬的）
     シナリオ実⾏中にスケールアウトを⾏い
     運⽤中のTiDBに影響がないことを確認
     

     View Slide

106. 106/140
     TiDB構成に対してスケールアウト構成「TiDB7台＋TiKV6台」を追加
     TiDBの検証について︓実施した検証 [3]
     TiDB構成
     load-tidb-pd-cluster-01
     load-tidb-pd-cluster-02
     load-tidb-pd-cluster-03
     load-tidb-mysql-cluster-01
     load-tidb-mysql-cluster-02
     load-tidb-tikv-storage-cluster-01
     load-tidb-tikv-storage-cluster-02
     load-tidb-tikv-storage-cluster-03
     TiDB、TiKVを9台構成で構築する
     スケールアウト構成
     load-tidb-mysql-cluster-03
     load-tidb-mysql-cluster-09
     load-tidb-tikv-storage-cluster-04
     load-tidb-tikv-storage-cluster-09
     追 加
     … …
     

     View Slide

107. 107/140
     負荷をかけた状態でスケールアウトを⾏い
     運⽤中のTiDBに影響がないことを確認
     スケールアウト実⾏中にCPUのスパイク及び
     QPSやレイテンシに影響がないことを確認
     TiDBの検証について︓実施した検証 [3]
     

     View Slide

108. 108/140
     ・最適なQPSを元に実⾏する最⼩要件構成⽤のシナリオ
     ・負荷掛け元の台数は4台なのでリクエスト数と同時接続数は4倍
     期待するQPS
     32000
     TiDBの検証について︓実施した検証 [3]
     最⼩要件構成⽤シナリオ
     Bucket # % Histogram
     [0s, 3s] 19200000 100.00% #### ・・・ #############################
     [3s, 5s] 0 0.00%
     [5s, +Inf] 0 0.00%
     [シナリオ2-3︓32000、1800] 32000×600=19200000
     レイテンシは100%
     （影響なし）
     1秒間のリクエスト数=8000、同時接続数=450
     1台あたりの「load-tidb-mysql-cluster」への負荷
     32000、1800
     16000、 900
     シナリオ:2-3
     

     View Slide

109. 109/140
     シナリオ2-3実⾏＋スケールアウト後のCPU Usageメトリクス
     シナリオの実⾏時間は10分でその間にスケールアウトを実施
     TiDBの検証について︓実施した検証 [3]
     

     View Slide

110. 110/140
     17:46 シナリオ2-3を実⾏する
     TiDBの検証について︓実施した検証 [3]
     

     View Slide

111. 111/140
     17:48 tiup cluster check実⾏（TiDB7台＋TiKV6台）
     TiDBの検証について︓実施した検証 [3]
     

     View Slide

112. 112/140
     17:50 tiup cluster scale-out実⾏（TiDB7台＋TiKV6台）
     TiDBの検証について︓実施した検証 [3]
     

     View Slide

113. 113/140
     TiDBの検証について︓実施した検証 [3]
     CPUのスパイクがない
     （影響なし）
     

     View Slide

114. 114/140
     シナリオ2-3実⾏＋スケールアウト後のQPSメトリクス
     1秒間のリクエスト数32000の要求に対してQPS32000
     Grafana︓TiDB︓Query Summary︓QPS
     TiDBの検証について︓実施した検証 [3]
     QPSは⼀定で
     安定している
     

     View Slide

115. 115/140
     シナリオ2-3実⾏＋スケールアウト後のConnection Countメトリクス
     同時接続数1800の要求に対してConnection1800
     Grafana︓TiDB︓Server︓Connection Count
     TiDBの検証について︓実施した検証 [3]
     Connectionは
     ⼀定で安定している
     

     View Slide

116. 116/140
     負荷かけ先のTiDBインスタンス（スケールアウト後の構成）
     TiDBの検証について︓実施した検証 [3]
     TiDB9台・TiKV9台構成
     

     View Slide

117. 117/140
     負荷かけ先のTiDBインスタンス（スケールアウト後の構成）
     TiDBの検証について︓実施した検証 [3]
     TiDB7台追加
     

     View Slide

118. 118/140
     負荷かけ先のTiDBインスタンス（スケールアウト後の構成）
     TiDBの検証について︓実施した検証 [3]
     TiKV6台追加
     

     View Slide

119. 119/140
     [4] スケールアウト後の環境で
     QPSが上がることを検証
     

     View Slide

120. 120/140
     TiDBの検証について︓実施した検証 [4]
     この検証での確認（⽬的）
     TiDBの台数が増えた分
     QPSが増加することを確認
     負荷かけの実⾏時間を3分から30分に
     変更して安定して動作することを確認
     

     View Slide

121. 121/140
     負荷かけ元を14台追加する
     TiDBの構成が「TiDB9台＋TiKV9台」になったため負荷かけ元を追加
     負荷かけ元
     TiDBの検証について︓実施した検証 [4]
     …
     majin-vegeta-mysql-01
     majin-vegeta-mysql-02
     majin-vegeta-mysql-03
     majin-vegeta-mysql-04
     majin-vegeta-mysql-05
     majin-vegeta-mysql-06
     majin-vegeta-mysql-07
     majin-vegeta-mysql-08
     majin-vegeta-mysql-09
     majin-vegeta-mysql-18
     

     View Slide

122. 122/140
     最⼩要件構成⽤のシナリオを使⽤して検証
     最適なQPSである16000の9倍である
     144000QPSが出ること及び
     30分実⾏した場合でも途中で
     パフォーマンスが劣化することなく
     安定して動作することを確認
     TiDBの検証について︓実施した検証 [4]
     

     View Slide

123. 123/140
     ・最⼩構成⽤のシナリオ（2-3）をそのまま使⽤
     ・負荷掛け元の台数は18台なのでリクエスト数と同時接続数は18倍
     ・最後の仕上げとして負荷かけの時間は30分で実⾏
     期待するQPS
     144000
     TiDBの検証について︓実施した検証 [4]
     1秒間のリクエスト数=8000、同時接続数=450
     1台あたりの「load-tidb-mysql-cluster」への負荷
     144000、8100
     16000、 900
     最⼩要件構成⽤シナリオ シナリオ:2-3
     ヒストグラムの結果は実⾏時間を30分に変更したため
     vegeta-mysqlが出⼒する「result.bin」の肥⼤化がボトルネックに
     途中でパフォーマンスが低下したためレポートをOFFにして実⾏
     [シナリオ2-3︓144000、8100] 144000×1800=259200000
     

     View Slide

124. 124/140
     シナリオ実⾏後のQPSのメトリクス
     1秒間のリクエスト数144000の要求に対してQPS144000
     Grafana︓TiDB︓Query Summary︓QPS
     TiDBの検証について︓実施した検証 [4]
     QPSは⼀定で
     安定している
     

     View Slide

125. 125/140
     シナリオ実⾏後のCPU Usageメトリクス
     Grafana︓TiDB︓Server︓CPU Usage
     TiDBの検証について︓実施した検証 [4]
     CPUは
     スパイクすることなく
     安定している
     

     View Slide

126. 126/140
     シナリオ実⾏後のConnection Countメトリクス
     同時接続数8100の要求に対してConnection8100
     Grafana︓TiDB︓Server︓Connection Count
     TiDBの検証について︓実施した検証 [4]
     Connectionは
     ⼀定で安定している
     

     View Slide

127. 127/140
     QPS
     Component
     PD TiDB TiKV
     144000 3 9 9
     288000 3 18 18
     576000 3 36 36
     1152000 3 72 72
     2304000 3 144 144
     TiDB server1台あたりの最適なQPSから算出した台数
     検証は必要だが、理論的な値は上記になる
     TiDBの検証について
     

     View Slide

128. 128/140
     TiDBの検証について
     CygamesのQPSは数百万で
     特にイベントやアクティブな時間帯は
     アクセス数が多く
     更にQUERYの発⾏数が増加するため
     ノーメンテナンスで必要なリソースに
     ターゲットを絞ってスケール可能なTiDBは
     ソーシャルゲームの運⽤に向いている
     

     View Slide

129. 129/140
     TiDBの検証について
     ユーザー数
     時間
     イベントやアクティブな
     時間帯はスケールアウト
     ⾮アクティブな
     時間帯はスケールイン
     

     View Slide

130. 130/140
     ソーシャルゲームはユーザーのアクセス数に応じた
     リソースのコントロールが必要になるため
     TiDB serverのスケールがメイン
     そのため今回の検証では
     TiDB serverを基準としてQPSの算出を⾏い
     TiDB server1台あたりの最適なQPSをもとに
     スケールする検証を⾏った
     TiDBの検証について
     

     View Slide

131. 131/140
     TiDB9台追加
     TiDB serverのスケールがメイン
     TiDB serverを9台から18台に増加して検証
     TiDBの検証について
     

     View Slide

132. 132/140
     144000
     QPS
     216000
     QPS
     288000
     QPS
     最適なQPS 16000×18=288000QPS
     TiKV serverを増やす事でQPSを増加させることも可能
     TiDBの検証について
     Grafana︓TiDB︓Query Summary︓QPS Grafana︓TiDB︓Server︓CPU Usage
     TiDB serverのみを増やす事でQPSが増加することを確認
     

     View Slide

133. 133/140
     TiDB serverをスケール
     台数は想定するQPSを元に増減する
     QPS
     Component
     PD TiDB TiKV
     144000
     3台固定
     9台を最⼤として増減
     ストレージのサイズ
     に合わせて増加
     288000 18台を最⼤として増減
     576000 36台を最⼤として増減
     1152000 72台を最⼤として増減
     2304000 144台を最⼤として増減
     TiDBの検証について
     TiKV serverをスケール
     台数はストレージのサイズに合わせて増加する
     短期的 中・⻑期的
     

     View Slide

134. 134/140
     今回は４つの検証を⾏い
     期待通りの結果となりました‼
     TiDBの検証について
     

     View Slide

135. 135/140
     本⽇はCygamesで取り組んでる
     検証の⼀部を紹介しました
     今後もTiDBにおける最適な
     「設計」と「運⽤」を⽬指して
     引き続き検証をしていきます
     TiDBの検証について
     

     View Slide

136. 136/140
     TiDBにおけるその他取り組み
     

     View Slide

137. 137/140
     TiDBにおける
     Cygamesでのその他取り組みについて
     少しだけ紹介します
     TiDBの検証は勿論なのですが
     他のエンジニアの技術⼒向上のためにも
     TiDBの勉強会を開催しました
     TiDBにおけるその他取り組み
     

     View Slide

138. 138/140
     Cygamesの社内勉強会「カジュアル共有会」
     オンラインセッションで発表
     TiDBにおけるその他取り組み
     タイトル 開催⽇
     カジュアル共有会 〜TiDB学習前基礎知識編〜 2⽉に開催
     カジュアル共有会 〜TiDBアーキテクチャー編〜 7⽉に開催（2⽇間）
     カジュアル共有会 〜TiDB検証編〜 要スケジュール調整
     

     View Slide

139. 139/140
     今後もカジュアル共有会や
     その他勉強会を通じて
     Cygamesエンジニアの技術⼒向上に向けて
     次世代データベースであるTiDBに関する
     知⾒の共有が出来ればと考えています
     TiDBにおけるその他取り組み
     

     View Slide

140. 140/140
     Chapter2 まとめ
     最適なQPSを1つの指標として
     vegeta-mysqlを使⽤したTiDBの検証を⾏い
     インスタンス数に⽐例したQPSの増加を確認しました
     TiDBの検証
     必要なリソースにターゲットを絞ってスケール可能な
     TiDBは⼤規模かつ変動の激しいサービスである
     ソーシャルゲームの運⽤に向いているかと思います
     TiDBとソーシャルゲームとの親和性
     

     View Slide

141. View Slide

142. 142/195
     Chapter2 おまけ
     1. TiDBの環境構築について
     2. 検証環境構築の⾃動化について
     3. ダミーQUERYの増幅について
     セッション発表対象外
     

     View Slide

143. 143/195
     TiDBの環境構築について
     お ま け
     

     View Slide

144. 144/195
     TiDBの環境構築はパッケージマネージャー
     TiUP（TiUPコマンド）を使⽤して構築します
     TiUPコマンドを使⽤することで環境構築を
     ⾮常に簡単に⾏うことができます
     TiDBの環境構築について
     TiUP Overview︓https://docs.pingcap.com/tidb/stable/tiup-overview
     

     View Slide

145. 145/195
     環境構築で利⽤可能なコンポーネントとして
     「playgroundやcluster」等がありますが
     TiUP Clusterコマンドを使⽤した
     構築⽅法について説明します
     TiDBの環境構築について
     TiUP Cluster︓https://docs.pingcap.com/tidb/stable/tiup-component-cluster
     

     View Slide

146. 146/195
     TiDBの環境構築について
     TiDBバージョンの取得
     tiup list tidb
     ・・・
     後述する「TiUP実⾏環境」への事前準備が完了した場合に
     tidb-managerから実⾏する
     tiup list︓https://docs.pingcap.com/tidb/stable/tiup-command-list
     

     View Slide

147. 147/195
     TiDBの環境構築について
     Component Instance Name Comment
     TiDB管理 TiUP tidb-manager
     TiDB管理環境
     （TiUPコマンド実⾏環境）
     TiDB構成
     PD tidb-pd-cluster-0X TiDB cluster環境
     TiDB tidb-mysql-cluster-0X PD cluster環境
     TiKV tidb-tikv-storage-cluster-0X Storage cluster環境
     モニタリング Monitor tidb-monitor モニタリング環境
     0X＝シャード番号（01、02、03...）
     TiDB cluster name︓tidb-cluster
     TiDB cluster version︓v6.1.0
     TiDB環境構築リスト
     

     View Slide

148. 148/195
     TiDBの環境構築 準備編
     

     View Slide

149. 149/195
     TiDBの環境構築 [準備編]
     1. TiDBインスタンスを準備
     2. TiDBデプロイ前の事前準備
     3. TiDBデプロイ⽤のトポロジを準備
     

     View Slide

150. 150/195
     TiDBの環境構築︓インスタンスを準備
     本番環境の推奨事項（最⼩要件構成）通りの台数で構築する
     TiUP
     tidb-manager
     Monitor
     tidb-monitor
     TiDB構成
     単純に試す場合はスペックダウンや台数を減らす
     等の対応を取ればよいかと思います
     tidb-pd-cluster-01
     tidb-pd-cluster-02
     tidb-pd-cluster-03
     tidb-mysql-cluster-01
     tidb-mysql-cluster-02
     tidb-tikv-storage-cluster-01
     tidb-tikv-storage-cluster-02
     tidb-tikv-storage-cluster-03
     

     View Slide

151. 151/195
     TiDBの環境構築︓デプロイ前の事前準備
     TiDBを正常に
     動作させるため
     の環境を構築
     tidb-mysql-cluster-0X
     tidb-pd-cluster-0X
     tidb-tikv-storage-cluster-0X
     tidb-monitor
     TiDB基本構成＋Monitor
     TiDBを管理する
     環境を構築
     tidb-manager
     TiUP実⾏環境（全てのTiUPコマンドはここで実⾏する）
     

     View Slide

152. 152/195
     TiDBの環境構築︓デプロイ前の事前準備
     1. TiUPをインストール
     curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
     2. TiUP環境変数を設定
     source .bash_profile
     3. TiUPクラスターコンポーネントをインストール
     tiup cluster
     4. TiUPクラスターコンポーネントのアップデート
     tiup update --self && tiup update cluster
     5. mysql clientをインストール（必要に応じて）
     TiUP
     実⾏環境
     Deploy a TiDB Cluster Using TiUP︓https://docs.pingcap.com/tidb/stable/production-deployment-using-tiup
     

     View Slide

153. 153/195
     TiDBの環境構築︓デプロイ前の事前準備
     • NTP設定
     • NUMAコントロール設定
     • データディレクトリのI/Oスケジューラ設定
     • cpufreqモジュールの電源ポリシー設定
     • OSプロファイル設定
     • リソース制限設定
     • THP（Transparent Huge Pages）無効
     [カーネルパラメータ設定]
     • ファイルディスクリプタ制限設定
     • TCP/IPソケット接続要求制限設定
     • Syncookie無効
     • オーバーコミット有効
     （上限＝実メモリサイズ）
     • システムスワップ無効
     TiDB Environment and System Configuration Check︓https://docs.pingcap.com/tidb/stable/check-before-deployment
     TiDB基本構成＋Monitor
     ＋
     

     View Slide

154. 154/195
     TiDBの環境構築︓デプロイ⽤のトポロジを準備
     global:
     user: "tidb"
     deploy_dir: "/tidb-deploy"
     data_dir: "/tidb-data"
     server_configs: {}
     pd_servers:
     - host: tidb-pd-cluster-01
     - host: tidb-pd-cluster-02
     - host: tidb-pd-cluster-03
     tidb_servers:
     - host: tidb-mysql-cluster-01
     - host: tidb-mysql-cluster-02
     tikv_servers:
     - host: tidb-tikv-storage-cluster-01
     - host: tidb-tikv-storage-cluster-02
     - host: tidb-tikv-storage-cluster-03
     monitoring_servers:
     - host: tidb-monitor
     grafana_servers:
     - host: tidb-monitor
     alertmanager_servers:
     - host: tidb-monitor
     topology（yaml）
     にデプロイ対象の
     TiDBの構成を記載
     Topology Configuration File for TiDB Deployment Using TiUP︓https://docs.pingcap.com/tidb/stable/tiup-cluster-topology-reference
     tidb-cluster-topology.yaml「TiDB基本構成＋Monitor」記載例
     tidb-managerへ
     アップロード
     ※hostの名前解決をしない場合は
     IPアドレスを記載する
     

     View Slide

155. 155/195
     TiDBの環境構築 チェック編
     

     View Slide

156. 156/195
     TiDBの環境構築 [チェック編]
     1.TiDBクラスターをチェック
     

     View Slide

157. 157/195
     TiDBの環境構築︓クラスターをチェック
     「TiDB基本構成＋Monitor」の事前準備で
     適⽤したパラメータが
     正しく設定されていることをチェックします
     topology fileに記載された全てのホストが対象
     tiup cluster check tidb-cluster-topology.yaml [-i The path of the SSH identity file.]
     tiup cluster check︓https://docs.pingcap.com/tidb/stable/tiup-component-cluster-check#syntax
     

     View Slide

158. 158/195
     TiDBの環境構築︓クラスターをチェック
     Failが出た場合は
     再度TiDBデプロイ
     前の事前準備を⾏う
     必要があります
     PassであればOK
     （cpu-governorが
     WarnなのはEC2で
     構築しているため）
     tiup cluster check︓https://docs.pingcap.com/tidb/stable/tiup-component-cluster-check#output
     

     View Slide

159. 159/195
     TiDBの環境構築 デプロイ編
     

     View Slide

160. 160/195
     TiDBの環境構築 [デプロイ編]
     1. TiDBクラスターをデプロイ
     2. TiDBクラスターを開始
     3. TiDBクラスターのステータスを確認
     

     View Slide

161. 161/195
     TiDBの環境構築︓クラスターをデプロイ
     TiDBクラスターをチェックした結果が
     全てPassであればデプロイ実⾏可能です
     topology fileに記載された全てのホストが対象
     TiDBクラスター名とTiDBのバージョンを指定
     Deploy and Maintain an Online TiDB Cluster Using TiUP︓https://docs.pingcap.com/tidb/stable/tiup-cluster#deploy-the-cluster
     tiup cluster -y deploy tidb-cluster v6.1.0 tidb-cluster-topology.yaml [-i The path of the SSH identity file.]
     

     View Slide

162. 162/195
     TiDBの環境構築︓クラスターを開始
     デプロイしたTiDBクラスターを開始
     TiDBクラスター名を指定
     Deploy and Maintain an Online TiDB Cluster Using TiUP︓https://docs.pingcap.com/tidb/stable/tiup-cluster#start-the-cluster
     tiup cluster start tidb-cluster
     

     View Slide

163. 163/195
     TiDBの環境構築︓クラスターのステータスを確認
     デプロイしたTiDBクラスターを確認
     Deploy and Maintain an Online TiDB Cluster Using TiUP︓https://docs.pingcap.com/tidb/stable/tiup-cluster#check-the-cluster-status
     tiup cluster display tidb-cluster
     TiDBクラスター名を指定
     

     View Slide

164. 164/195
     TiDBの環境構築
     tidb-managerからデプロイした
     TiDBクラスターの情報を取得
     Deploy and Maintain an Online TiDB Cluster Using TiUP︓https://docs.pingcap.com/tidb/stable/tiup-cluster#view-the-cluster-list
     tiup list tidb
     

     View Slide

165. 165/195
     検証環境構築の⾃動化について
     お ま け
     

     View Slide

166. 166/195
     検証環境構築の⾃動化について
     概要 ツール名 略称
     EC2インスタンス構築 AWS-Automation-Support aas
     TiDB環境構築 TiDB-Deployment-Manager tdm
     負荷試験環境構築 Majin-Vegeta-Mysql mvm
     下記のツールを使⽤して⾃動化
     検証環境
     簡単ではありますが説明します
     

     View Slide

167. 167/195
     EC2インスタンス構築
     

     View Slide

168. 168/195
     検証環境構築の⾃動化︓EC2インスタンス構築
     ec2_orchestration
     _instance
     EC2インスタンス
     管理完了
     instance.cnfに記載されたインスタンス名を元に
     スクリプトを実⾏してEC2インスタンスを管理
     ①インスタンスを記載
     ②スクリプトを実⾏
     instance.cnf
     

     View Slide

169. 169/195
     検証環境構築の⾃動化︓EC2インスタンス構築
     TiDB
     [tidb_instance.cnf]
     load-tidb-manager
     load-tidb-pd-cluster-01
     load-tidb-mysql-cluster-01
     load-tidb-tikv-storage-cluster-01
     load-tidb-monitor
     load-tidb-pd-cluster-03
     load-tidb-mysql-cluster-09
     load-tidb-tikv-storage-cluster-09
     instance.cnfは機能別に分けて管理
     majin-vegeta-mysql
     [mvm_instance.cnf]
     majin-vegeta-mysql-01
     majin-vegeta-mysql-02
     majin-vegeta-mysql-03
     majin-vegeta-mysql-04
     majin-vegeta-mysql-05
     majin-vegeta-mysql-06
     majin-vegeta-mysql-07
     majin-vegeta-mysql-18
     …
     …
     

     View Slide

170. 170/195
     検証環境構築の⾃動化︓EC2インスタンス構築
     各スクリプト「作成・停⽌」などを組み込んでいる
     ec2_orchestration_instance
     各機能は
     AWS CLI v2
     を使⽤して構築
     ・public-ip setting
     ・change time zone
     ・set hostname
     ・git install
     ・etc.
     create_instance
     start_instance
     stop_instance
     terminate_instance
     etc.
     …
     

     View Slide

171. 171/195
     検証環境構築の⾃動化︓EC2インスタンス構築
     「TiDBインスタンス作成」の例
     mvm_
     instance.cnf
     EC2インスタンス管理完了
     load-tidb-manager
     load-tidb-pd-cluster-01
     load-tidb-mysql-cluster-01
     load-tidb-tikv-storage-cluster-01
     load-tidb-monitor
     load-tidb-pd-cluster-03
     load-tidb-mysql-cluster-09
     load-tidb-tikv-storage-cluster-09
     …
     パラメータ
     ・tidb
     ・create
     ec2_orchestration
     _instance
     処理は全て
     並列処理で実⾏
     tidb_
     instance.cnf
     

     View Slide

172. 172/195
     TiDB環境構築
     

     View Slide

173. 173/195
     検証環境構築の⾃動化︓TiDB環境構築
     TiDB Cluster
     管理完了
     tidb_instance.cnfに記載されたインスタンス名を元に
     スクリプトを実⾏してTiDB Clusterを管理
     ①TiDBインスタンスを記載
     ②スクリプトを実⾏
     tidb_
     instance.cnf
     tidb_setup
     

     View Slide

174. 174/195
     tidb_instance.cnfは
     EC2インスタンス構築時のcnfをそのまま使⽤
     検証環境構築の⾃動化︓TiDB環境構築
     TiDB
     [tidb_instance.cnf]
     load-tidb-manager
     load-tidb-pd-cluster-01
     load-tidb-mysql-cluster-01
     load-tidb-tikv-storage-cluster-01
     load-tidb-monitor
     load-tidb-pd-cluster-03
     load-tidb-mysql-cluster-09
     load-tidb-tikv-storage-cluster-09
     …
     

     View Slide

175. 175/195
     TiDB構築に必要な初期設定やdeploy⽤yamlの⽣成
     及びTiDB Clusterを管理
     tidb_setup
     検証環境構築の⾃動化︓TiDB環境構築
     tidb_hosts_setup
     ・tidb-manager
     ・tidb-cluster
     ・check
     ・deploy, scaleout, scalein
     ・start, stop
     ・etc.
     tidb_init_setup
     TiUPコマンドを使⽤
     tidb_tiup_tools
     tidb_orchestration_setup
     tidb_yaml_generator
     

     View Slide

176. 176/195
     スクリプト実⾏後にTiDBが使⽤可能になります
     検証環境構築の⾃動化︓TiDB環境構築
     

     View Slide

177. 177/195
     負荷試験環境構築
     

     View Slide

178. 178/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm_edit_cnf
     ホスト名だけでなくIPアドレスを含めた
     負荷かけ元(mvm)のcnfを⽣成
     ①mvmインスタンスを記載
     ②スクリプトを実⾏
     mvm_load_source.cnf⽣成
     mvm_load_
     source.cnf
     mvm_
     instance.cnf
     

     View Slide

179. 179/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm_edit_cnf
     指定したシナリオグループのQUERYを
     負荷かけ元(mvm)へアップロードするためのcnfを⽣成
     ①シナリオグループを設定
     mvm_query.cnf⽣成
     mvm_query.cnf
     mvm_load_
     source.cnf ②スクリプトを実⾏
     シナリオグループ
     

     View Slide

180. 180/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm_edit_cnf
     RateやConnsの値を変動させるためのcnfを⽣成
     ①RateやConnsの変動パラメータを設定
     mvm_load_level.cnf⽣成
     mvm_load_
     level.cnf
     ②スクリプトを実⾏
     負荷レベル
     

     View Slide

181. 181/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm_load_source.cnfの情報を元に
     負荷かけ元(mvm)の環境を構築
     ①⽣成した負荷かけ元情報
     Majin-Vegeta-Mysql（mvm）環境構築
     mvm環境構築完了
     ・vegeta-mysql
     ・mysql_client
     ・Nginx（レポートホスト）
     ・etc
     パラメータ
     setup ②スクリプトを実⾏
     mvm_
     orchestration
     mvm_load_
     source.cnf
     

     View Slide

182. 182/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm_query.cnfに記載された情報を元に
     負荷かけ元(mvm)へQUERYをアップロード
     ①⽣成したQUERYの情報
     QUERYアップロード
     パラメータ
     upload
     QUERY
     アップロード完了
     ②スクリプトを実⾏
     mvm_query.cnf
     mvm_
     orchestration
     

     View Slide

183. 183/195
     負荷試験を実⾏するためのcnf
     負荷かけ元・負荷かけ先・負荷レベルを⼿動で設定して調整
     [mvm_attack_scenario.cnf]
     検証環境構築の⾃動化︓負荷試験環境構築
     [mvm_query.cnf]
     ・QUERYファイルの情報
     [mvm_load_source.cnf]
     ・負荷かけ元の情報
     ・負荷かけ元情報及びQUERY情報のINDEX
     ・vegeta-mysqlで使⽤する負荷のINDEX
     ・負荷かけ先情報のINDEX
     ・QUERYのタイプ
     ・ALL
     ・SELECT, INSERT, UPDATE
     [mvm_load_level.cnf]
     ・RateやConns等の負荷のレベル
     [mvm_load_destination.cnf]
     ・負荷かけ先の情報
     

     View Slide

184. 184/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm_attack_scenario.cnfの情報を元に
     vegeta-mysqlを実⾏してTiDB環境へ負荷をかける
     ①負荷試験情報を設定
     負荷試験の実⾏
     ③vegeta-mysqlからQUERY実⾏
     パラメータ
     attack ②スクリプトを実⾏
     mvm_attack_
     scenario.cnf
     mvm_
     orchestration
     mvm環境 TiDB環境
     

     View Slide

185. 185/195
     検証環境構築の⾃動化︓負荷試験環境構築
     mvm環境 TiDB環境
     load-tidb-mysql-cluster-01
     load-tidb-mysql-cluster-03
     load-tidb-mysql-cluster-02
     load-tidb-mysql-cluster-09
     実施した検証 [4]で実⾏した環境での負荷かけイメージ
     …
     …
     mvm_
     orchestration
     majin-vegeta-mysql-01
     majin-vegeta-mysql-02
     majin-vegeta-mysql-03
     majin-vegeta-mysql-04
     majin-vegeta-mysql-18
     majin-vegeta-mysql-17
     majin-vegeta-mysql-05
     majin-vegeta-mysql-06
     

     View Slide

186. 186/195
     ダミーQUERYの増幅について
     お ま け
     

     View Slide

187. 187/195
     ダミーQUERYの増幅について
     概要 ツール名 略称
     ダミーQUERY⽣成 Random-Query-Generator rqg
     下記のツールを使⽤して増幅
     ダミーQUERY
     簡単ではありますが説明します
     

     View Slide

188. 188/195
     rqg_
     orchestration
     プロジェクトから出⼒されたLTSVログを元にQUERYを抽出
     ベースQUERYとしてQUERYのみ出⼒
     ①プロジェクトのLTSVログを準備
     ベースQUERY出⼒
     ダミーQUERYの増幅について
     プロジェクトのLTSVログはデバッグ環境で実⾏されたログ端末から
     網羅的に実⾏して出⼒（QUERY以外の情報を含む）
     BASE QUERY
     出⼒
     ②スクリプトを実⾏
     LTSV
     パラメータ
     upload
     

     View Slide

189. 189/195
     ベースQUERYを元にQUERYの情報を登録
     ②スクリプトを実⾏
     QUERY情報登録
     ダミーQUERYの増幅について
     UNIQUE QUERY
     QUERY情報登録
     QUERY FORMAT
     BASE QUERY
     rqg_entry_
     query_format
     ①ベースQUERYを準備
     

     View Slide

190. 190/195
     ダミーQUERYの増幅について
     MySQL
     UNIQUE QUERY
     QUERY FORMAT
     BASE QUERY
     QUERYのフォーマットは
     データモデルから
     データ型を取得して変換
     Uint64⽣成
     SELECT user_name FROM tbl_user WHERE user_id = N
     SELECT user_name FROM tbl_user WHERE user_id = _bigint_
     parse
     データ型
     tbl_user
     user_id BIGINT
     user_name VARCHAR
     QUERYをパースして
     ユニークQUERYとUint64を⽣成
     SELECT user_name FROM tbl_user WHERE user_id = 1
     

     View Slide

191. 191/195
     ベースQUERYを元にダミーQUERYを⽣成
     ①ベースQUERYを準備
     ダミーQUERY⽣成
     ダミーQUERYの増幅について
     DUMMY QUERY
     ⽣成
     ②スクリプトを実⾏
     ベースQUERY
     rqg_
     orchestration
     パラメータ
     generate
     

     View Slide

192. 192/195
     ダミーQUERYの増幅について
     BASE QUERY
     MySQL
     UNIQUE QUERY
     QUERY FORMAT
     SELECT user_name FROM tbl_user WHERE user_id = N
     SELECT user_name FROM tbl_user WHERE user_id = _bigint_
     検索
     取得
     parse
     1118
     DUMMY QUERY
     DUMMY INSERT
     出⼒
     出⼒
     INSERTやUPDATEも同様の⼿順で⽣成しています
     SELECT user_name FROM tbl_user WHERE user_id = 1
     Uint64⽣成
     INSERT INTO tbl_user (user_id, user_name) VALUES (1118, ʼxxxʼ)
     SELECT user_name FROM tbl_user WHERE user_id = 1118
     BIGINTのサイズ内で
     乱数⽣成
     

     View Slide

193. 193/195
     ダミーQUERYの増幅について
     マイページ
     QUERY
     プロジェクト
     マイページ
     ダミーQUERY
     プレゼント
     QUERY
     ガチャ
     QUERY
     負荷試験
     増幅
     プレゼント
     ダミーQUERY
     増幅
     ガチャ
     ダミーQUERY
     増幅
     マイページの
     負荷レベルで設定
     プレゼントの
     負荷レベルで設定
     ガチャの
     負荷レベルで設定
     QUERY実⾏
     QUERY実⾏
     QUERY実⾏
     TiDB
     マイページ
     を1回実⾏
     プレゼント
     を1回実⾏
     ガチャ
     を1回実⾏
     出⼒
     出⼒
     出⼒
     各機能を1回実⾏して機能毎にQUERYを管理して増幅
     疑似的に負荷試験を⾏う等の応⽤も可能
     

     View Slide

194. 194/195
     vegeta-mysqlでの負荷試験は
     準備したQUERYを実⾏するため
     負荷試験に必要なQUERYを準備すること⾃体が
     プロジェクトとの調整も含めて
     ⼤変になるかと思います
     ダミーQUERYの増幅について
     

     View Slide

195. 195/195
     しかしながら
     QUERYを増幅出来ればプロジェクト側の⼯数を
     なるべく取ることなくQUERYを準備することが
     可能になるのではないか︖と考えています
     ダミーQUERYの増幅について
     

     View Slide