$30 off During Our Annual Pro Sale. View Details »

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

Cygames
December 23, 2022

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

2022/11/18 db tech showcase 2022 Tokyo

Cygames

December 23, 2022
Tweet

More Decks by Cygames

Other Decks in Technology

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

    View Slide

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

    View Slide

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

    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が1秒間に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固定で1秒間のリクエスト数を変動させます(増分値=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
    今回は4つの検証を⾏い
    期待通りの結果となりました‼
    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