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

2022/11/18 db tech showcase 2022 Tokyo

Transcript

1. データ管理・運⽤ノウハウ 〜次世代データベース「TiDB」の検証を開始したCygamesの取り組み〜 株式会社Cygames サーバーサイド ⼤橋 庸 / CTO室 浦⾕ 和茂 「最⾼のコンテンツ」を⽀える、 Cygamesのデータベース技術の今までとこれから
2. 2/140 Cygamesについて
3. 3/140 Cygamesについて 「最⾼のコンテンツを作る会社」
4. 4/140 Cygamesについて ソーシャルゲームをはじめ コンシューマーゲーム・アニメ e-sportsなど
5. 5/140 アジェンダ TiDBへの取り組み Chapter1 Chapter2 データベース技術の今とこれから
6. 6/140 データベース技術の今とこれから Chapter1
7. 7/140 ⼤橋 庸 サーバーサイド / サブマネージャー 2014年株式会社Cygamesへ⼊社 「グランブルファンタジー」サーバーサイドサブリーダー ユーザー体験の向上を通じて「最⾼のコンテンツ」をユーザーの皆様に 届けるべく、アプリケーション/データベースそれぞれのレイヤにおける 負荷対策と、運⽤で⽣じる様々なトラブルや課題の解決に従事 ⾃⼰紹介
8. 8/140 1. サーバーサイドのミッション 2. 現⾏アーキテクチャ概要 3. 現⾏アーキテクチャの改善ポイント 4. チャレンジを⽀えるマインド 5. まとめ データベース技術の今とこれから
9. 9/140 1. サーバーサイドのミッション 2. 現⾏アーキテクチャ概要 3. 現⾏アーキテクチャの改善ポイント 4. チャレンジを⽀えるマインド 5. まとめ データベース技術の今とこれから
10. 10/140 サーバーサイドのミッション https://speakerdeck.com/cygames/kuranhuruhuantasiwozhi-eruinhurafalseji-shu 安定とモダンな技術の導⼊の両⽴がチャレンジ そのマインドが「最⾼のコンテンツ」を⽀える源 最⾼のユーザー体験を⽣み出すために 安定・⾼速・スケーラブルなサーバーシステムの構築 聖域を設けずに、モダンな技術の検証/導⼊をしていく インフラ視点の資料は「グランブルーファンタジーを⽀えるインフラ技術」をご覧ください
11. 11/140 1. サーバーサイドのミッション 2. 現⾏アーキテクチャ概要 3. 現⾏アーキテクチャの改善ポイント 4. チャレンジを⽀えるマインド 5. まとめ データベース技術の今とこれから
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 メンテナンス (サービス停⽌) スケールアウト データリバランス バランシングルール更新
13. 13/140 ソースコードレベルで研究 データモデル設計 モニタリング/チューニング ロードテスト MySQLの性能を引き出すチャレンジについて 社内勉強会 etc 体系化（フレームワーク） ⽇々様々なチームで改善を継続することで 「安定・⾼速」なサーバーシステムを実現している 現⾏アーキテクチャ概要 今後もMySQLを利⽤していく
14. 14/140 1. サーバーサイドのミッション 2. 現⾏アーキテクチャ概要 3. 現⾏アーキテクチャの改善ポイント 4. チャレンジを⽀えるマインド 5. まとめ データベース技術の今とこれから
15. 15/140 現⾏アーキテクチャの改善ポイント サーバー構築 サーバーサイドのミッション 「スケーラブル」に関して課題 安 定 ⾼ 速 スケーラブル な
16. 16/140 現⾏アーキテクチャの改善ポイント 現⾏アーキテクチャでは解決困難なもの シームレスなスケーリング リソースごとのスケーリング 弊社で直⾯した「スケーラブル」が満たせてない事例を紹介
17. 17/140 現⾏アーキテクチャの改善ポイント メンテナンス時はサービス停⽌ サービスの予想以上の急成⻑で ⻑時間に渡るメンテナンス サービス停⽌を減らし、よりよい最⾼のユーザー体験を⽣み出す ※ オンラインメンテナンスは、求められるレイテンシなど状況次第で可能ではある シームレスなスケーリングが極めて困難 ユーザー体験の阻害に なぜ 改善
18. 18/140 現⾏アーキテクチャの改善ポイント 求めてる要件 オンラインでスケールが可能で、 データの不整合が発⽣しない （⾃動でデータリバランスも） MySQL ユーザーがデータベースに書き込み時に 不整合が発⽣するのでスケール時に サービスを停⽌する必要がある コンピューティング ノード ＋ ストレージノード コンピューティング ノード ストレージノード シームレスなスケーリング
19. 19/140 現⾏アーキテクチャの改善ポイント リソースごとに動的に変更すれば最適化が期待できる 最適化できたコストを「楽しさ」の追求に還元したい なぜ 改善 リソースごとのスケールが出来ない 計算資源やストレージなど リソースごとのスケール× リソース利⽤が⾮効率な状況 運⽤期間に伴い データ量増加
20. 20/140 現⾏アーキテクチャの改善ポイント 求めてる要件 計算資源とストレージのノードが 分離している MySQL 計算資源とストレージが結合している コンピューティング ノード ＋ ストレージノード コンピューティング ノード ストレージノード リソースごとのスケール
21. 21/140 MySQL互換 オープンソース 多様な運⽤環境（オンプレ・クラウド） クラウド環境ではフルマネージドも選択可能 現⾏アーキテクチャの改善ポイント その他求めてる要件
22. 22/140 現⾏アーキテクチャの改善ポイント 選択した ソリューション
23. 23/140 1. サーバーサイドのミッション 2. 現⾏アーキテクチャ概要 3. 現⾏アーキテクチャの改善ポイント 4. チャレンジを⽀えるマインド 5. まとめ データベース技術の今とこれから
24. 24/140 チャレンジを⽀えるマインド 我々は10年以上MySQLを利⽤し チャレンジとチューニングを繰り返してきた データベースの変更におよぶ技術検証 ⽇々様々なチームで改善を継続し 「安定・⾼速」なサーバーシステムを実現 データベースの変更におよぶ技術検証は 極めて⼤きなチャレンジ
25. 25/140 チャレンジを⽀えるマインド ⼤きなチャレンジを⽀える４つのマインド 聖域を作らない いかなるレイヤーにおいても より改善していく 現象と原因 現象を正確に把握する 根本的な原因を追求する 変化に追従 ビジネス・ユーザー・技術など 変化に対して柔軟に追従する 適切な⼿段を選択 選択⼿段を評価し最適解を導く
26. 26/140 1. サーバーサイドのミッション 2. 現⾏アーキテクチャ概要 3. 現⾏アーキテクチャの改善ポイント 4. チャレンジを⽀えるマインド 5. まとめ データベース技術の今とこれから
27. 27/140 Chapter1まとめ 最⾼のユーザー体験を⽣み出すために 安定・⾼速・スケーラブルなサーバーシステム構築 聖域を設けずに、モダンな技術の検証/導⼊をしていく 課題を解決する最適なソリューションはTiDB データベース技術の今とこれから シームレスなスケーリング リソースごとのスケーリング 現⾏アーキテクチャで課題となる２つのスケーリング MySQLで「安定・⾼速」なサーバーシステムを実現 チャレンジを⽀える４つのマインド
28. 28/140 TiDBへの取り組み Chapter2
29. 29/140 浦⾕ 和茂 CTO室 / Senior Database Administrator 2013年株式会社Cygamesへ⼊社 CTO室所属のDBAとして Cygamesの新規プロジェクトから既存のプロジェクトまで 全タイトルの基幹データベースの構築と改善を横断的に担当 ⾃⼰紹介
30. 30/140 1. TiDBを選択した理由 2. TiDBの検証 3. TiDBにおけるその他取り組み Chapter2 アジェンダ おまけ ・TiDBの環境構築について ・検証環境構築の⾃動化について ・ダミーQUERYの増幅について セッション発表対象外
31. 31/140 TiDBアーキテクチャー（チュートリアル） その前に‼
32. 32/140 https://docs.pingcap.com/tidb/stable/tidb-architecture TiDBのアーキテクチャー（チュートリアル） TiDBのアーキテクチャーのイメージ
33. 33/140 TiDBのアーキテクチャー（チュートリアル） PD cluster PD serverの クラスター構成 クラスター全般の管理を ⾏う頭脳 領域管理のレイヤー
34. 34/140 SQLを解析するレイヤー TiDBのアーキテクチャー（チュートリアル） TiDB cluster TiDB serverの クラスター構成 Parser・Optimizer・ Executor等の機能がある
35. 35/140 TiDBのアーキテクチャー（チュートリアル） Storage cluster TiKV serverと TiFlash serverの クラスター構成 Key-Valueと列指向の構造で データを永続化する データストアのレイヤー
36. 36/140 必要に応じてpluggableに TiFlashやTiSpark等を追加 TiDBのアーキテクチャー（チュートリアル） TiDBの基本構成 PD・TiDB・TiKV
37. 37/140 TiDBを選択した理由について
38. 38/140 CygamesではMySQLを使⽤している サーバーリソースをより上⼿く使⽤したい ユーザーがより安⼼して遊べる環境を構築する チャレンジ‼ TiDBを選択した理由について
39. 39/140 CygamesではMySQLを使⽤している TiDBはMySQLのインターフェースをそのまま使⽤できる MySQL（MySQL5.7）との互換性が⾼くMySQLを扱っている アプリケーション開発者としては扱いやすい アプリケーション開発者がバックエンドの仕組みを 意識することなく今まで通り使⽤できる TiDBを選択した理由について
40. 40/140 CPUリソース あるいはストレージの容量だけ ⾜りないサーバー等の偏りがある サーバーによって リソースの使われ⽅が異なるため バランスよくリソースが使⽤出来ないか サーバーリソースをより上⼿く使⽤したい 課 題 TiDBを選択した理由について
41. 41/140 TiDBを選択した理由について TiDB（マイクロな構成） コンピューティングノードと ストレージノードが疎結合なため 独⽴したスケールが可能 MySQL（モノリスな構成） サーバーリソースが密結合なため リソースをセットで スケールさせる必要がある この中に⽂字 を打ち込む 必要なリソースに ターゲットを絞って スケールできない それぞれ 単独で スケールできる コンピューティング ノード ストレージノード
42. 42/140 TiDBは必要なリソースにターゲットを絞って スケールできるためバランスよくリソースを使⽤できる 特にTiDB serverはステートレスであり 必要に応じてより柔軟にスケールできるため コスト削減にも期待できる サーバーリソースをより上⼿く使⽤したい TiDBを選択した理由について 解 決
43. 43/140 TiDBはクラスター構成のため ノーメンテナンスでスケールできる メンテナンスをなくし 24時間365⽇遊べる環境を構築できる ユーザーがより安⼼して遊べる環境を構築する TiDBを選択した理由について
44. 44/140 ユーザーがより安⼼して遊べる環境を構築する TiDBを選択した理由について TiKV cluster 各クラスターは 独⽴しているため 必要に応じて柔軟に スケール出来る スケールアウト スケールイン TiKV cluster
45. 45/140 現在サービスで採⽤している技術は安定し 信頼性の⾼い技術を取り扱っているが、 既存技術だけで無くモダンな技術の検証を⾏い エンジニアの技術⼒向上と将来のゲーム コンテンツへの導⼊を⽬指していきたい Cygamesにはチャレンジできる環境がある チャレンジ︕︕ TiDBを選択した理由について
46. 46/140 TiDBの検証について
47. 47/140 TiDBの検証について（サマリ） プロジェクトのQUERYを どの様に実⾏して どの様な検証を⾏ったのか︖ 運⽤プロジェクトのQUERYをサンプルに 検証は…
48. 48/140 シンプルなQUERYを実⾏ QUERYの発⾏数は数百万QPSにのぼる CygamesのソーシャルゲームにおけるQUERY 発⾏するQUERYの種類は圧倒的にSELECTのQUERYが多くなります 使⽤しない︓テーブル結合やサブQUERYなど 特にイベントやアクティブな時間帯は アクセス数 QUERYの発⾏数 QUERYについて
49. 49/140 QUERYの実⾏に使⽤したツールについて 検証環境について 検証データの準備について 実施した検証について TiDBの検証について
50. 50/140 QUERYの実⾏に使⽤したツールについて 検証環境について 検証データの準備について 実施した検証について TiDBの検証について
51. 51/140 vegeta-mysqlはGoで実装されたツールで ファイルに格納されたQUERYを実⾏して 指定したサーバーに負荷をかけて レポートを出⼒するベンチマークツールです vegeta-mysqlを使⽤ ツール TiDBの検証について︓QUERYの実⾏に使⽤したツール
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の実⾏に使⽤したツール
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に戻る （以降、指定時間分繰り返す）
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の実⾏に使⽤したツール
55. 55/140 QUERYの実⾏に使⽤したツールについて 検証環境について 検証データの準備について 実施した検証について TiDBの検証について
56. 56/140 検証環境は コンポーネントから TiFlash・TiCDCを 除いた構成 https://docs.pingcap.com/tidb/stable/hardware-and-software-requirements 本番環境の推奨事項 （最⼩要件構成） TiDBの検証について︓検証環境
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...）
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...）
59. 59/140 QUERYの実⾏に使⽤したツールについて 検証環境について 検証データの準備について 実施した検証について TiDBの検証について
60. 60/140 TiDBの検証について︓検証データの準備 検証データは、各テーブル毎に約100万件準備 使⽤したテーブルの数は約500 プロジェクトが実際に使⽤しているデータではなく プロジェクトの サンプルQUERY プロジェクトのデータモデルから⽣成した ダミーデータ を使⽤ ダミーデータの⽣成⽅法については「（おまけ）ダミーQUERYの増幅について」
61. 61/140 タイプ ユニークQUERY SELECT 291種類 INSERT 232種類 UPDATE 175種類 今回の検証で使⽤したサンプルQUERYの種類 TiDBの検証について︓検証データの準備
62. 62/140 TiDB DashboardのKey Visualizerを使⽤してデータの登録状況を確認（ヒートマップ） https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer TiDBの検証について︓検証データの準備
63. 63/140 ⽣成したダミーデータを登録後にデータを増幅 https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer ダミーデータから データを増幅 （SELECT INSERT） ❶ ❷ ⽣成した ダミーデータを 登録 TiDBの検証について︓検証データの準備
64. 64/140 同じ100万件でもデータモデルによってRegionの数が異なります https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer ⽐較的⼩さな Regionの数 ⽐較的⼤きな Regionの数 TiDBの検証について︓検証データの準備
65. 65/140 Regionは TiDBデータスケジューリングの最⼩単位であり テーブル作成時に1つのRegionが作成される Regionのサイズが96MiB以上になると分割し 20MiB以下になるとマージする 範囲ベースのシャーディング戦略を取る TiDBの検証について︓検証データの準備
66. 66/140 TiDBの検証について︓検証データの準備 96MiB以上だと分割し20MiB以下だと隣接するRegionをマージする TiKV Node Store Increase 96MiB Split Decrease 20MiB Meage Region Region TiKV Node Store Region
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)
68. 68/140 QUERYの実⾏に使⽤したツールについて 検証環境について 検証データの準備について 実施した検証について TiDBの検証について
69. 69/140 1. TiDB1台あたりの最適なQPSを⾒つけるための検証 2. インスタンス最⼩要件の台数で構築して検証 3. TiDBスケールアウト時に問題ないことを検証 4. スケールアウト後の環境でQPSが上がることを検証 TiDBの検証について︓実施した検証
70. 70/140 [1] TiDB1台あたりの 最適なQPSを⾒つけるための検証
71. 71/140 TiDBの検証について︓実施した検証 [1] TiDB server1台あたりの最適なQPSを確認 この検証での確認（⽬的）
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]
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を実⾏
74. 74/140 負荷かけ先のTiDBインスタンス（シングル構成） TiDBの検証について︓実施した検証 [1]
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
76. 76/140 シナリオを連続実⾏することで 最適なQPSを探すことができました 以降、 シナリオと検証の結果を 記載します シナリオは最適なQPSの前後のシナリオのみ記載 TiDBの検証について︓実施した検証 [1]
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]
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]
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]
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秒以内に集約して表⽰ ヒストグラムの結果を ⾒やすくするため
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
82. 82/140 シナリオ実⾏後のQPSのメトリクス シナリオ1-1〜1-12まで連続して実⾏した結果 Grafana︓TiDB-Summary︓QPS TiDBの検証について︓実施した検証 [1]
83. 83/140 1秒間のリクエスト数 20250に対して QPS20300 結果から現時点では 最適なQPSは20000 シナリオ1-6のQPSを拡⼤ TiDBの検証について︓実施した検証 [1]
84. 84/140 シナリオ実⾏後のCPU Usageメトリクス シナリオ1-1〜1-12まで連続して実⾏した結果 Grafana︓TiDB-Runtime︓CPU Usage TiDBの検証について︓実施した検証 [1]
85. 85/140 シナリオ1-6のCPU Usageを拡⼤ TiDBの検証について︓実施した検証 [1] もう少しだけ ゆとりを持たせたい
86. 86/140 QPSの結果から 最適なQPSは20000かと思われたが フルに近いリソースを使⽤している 最適なQPSを確定 TiDBの検証について︓実施した検証 [1] もう少しだけ ゆとりを持たせたい 安全を考慮して20000の80％である 16000を最適なQPSとした
87. 87/140 Grafana︓TiDB︓Server︓Connection Count シナリオ実⾏後のConnection Countメトリクス シナリオ1-1〜1-12まで連続して実⾏した結果 TiDBの検証について︓実施した検証 [1]
88. 88/140 [2]インスタンス最⼩要件の台数で 構築して検証
89. 89/140 TiDBの検証について︓実施した検証 [2] この検証での確認（⽬的） スケールアウト実⾏後に 負荷が減ることを確認 最⼩要件構成で 最適なQPS通りになることを確認
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
91. 91/140 負荷かけ先のTiDBインスタンス（最⼩要件構成） TiDBの検証について︓実施した検証 [2] PD2台追加 TiDB1台追加 TiKV2台追加
92. 92/140 最⼩要件の構成で台数が増えたため スケールアウト実⾏後に負荷が減ることを [1]の検証で実施したシナリオを元に再度検証 TiDB server（load-tidb-mysql-cluster）の台数が 2倍になったためCPU使⽤率が減ることを確認 TiDBの検証について︓実施した検証 [2]
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倍の値
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倍の値
95. 95/140 最適なQPSを元に 最⼩要件構成⽤のシナリオを 追加して検証する 最適なQPSである16000の2倍である 32000QPSが出ることを確認する TiDBの検証について︓実施した検証 [2]
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
97. 97/140 シナリオ実⾏後のQPSのメトリクス シナリオ2-1〜2-3まで連続して実⾏した結果です Grafana︓TiDB︓Query Summary︓QPS TiDBの検証について︓実施した検証 [2]
98. 98/140 シナリオ2-3のQPSを拡⼤ 期待通りのQPS32000となっています TiDBの検証について︓実施した検証 [2]
99. 99/140 シナリオ実⾏後のCPU Usageメトリクス シナリオ2-1〜2-3まで連続して実⾏した結果です Grafana︓TiDB︓Server︓CPU Usage TiDBの検証について︓実施した検証 [2]
100. 100/140 シナリオ2-1、2-2のCPU Usage スケールアウト実⾏後に負荷が減ることを確認 TiDBの検証について︓実施した検証 [2] 負荷が半減
101. 101/140 シナリオ2-3のCPU Usageを拡⼤ CPU Usageはゆとりのある使い⽅に シナリオ内の QUERYの偏りを調整すれば リソース使⽤のバランスが もっとよくなりそう TiDBの検証について︓実施した検証 [2]
102. 102/140 シナリオ実⾏後のConnection Countメトリクス シナリオ2-1〜2-3まで連続して実⾏した Grafana︓TiDB︓Server︓Connection Count TiDBの検証について︓実施した検証 [2]
103. 103/140 シナリオ2-3のConnection Countを拡⼤ 同時接続数が1800であることを確認しました Grafana︓TiDB︓Server︓Connection Count TiDBの検証について︓実施した検証 [2]
104. 104/140 [3] TiDBスケールアウト時に 問題ないことを検証
105. 105/140 TiDBの検証について︓実施した検証 [3] この検証での確認（⽬的） シナリオ実⾏中にスケールアウトを⾏い 運⽤中のTiDBに影響がないことを確認
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 追 加 … …
107. 107/140 負荷をかけた状態でスケールアウトを⾏い 運⽤中のTiDBに影響がないことを確認 スケールアウト実⾏中にCPUのスパイク及び QPSやレイテンシに影響がないことを確認 TiDBの検証について︓実施した検証 [3]
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
109. 109/140 シナリオ2-3実⾏＋スケールアウト後のCPU Usageメトリクス シナリオの実⾏時間は10分でその間にスケールアウトを実施 TiDBの検証について︓実施した検証 [3]
110. 110/140 17:46 シナリオ2-3を実⾏する TiDBの検証について︓実施した検証 [3]
111. 111/140 17:48 tiup cluster check実⾏（TiDB7台＋TiKV6台） TiDBの検証について︓実施した検証 [3]
112. 112/140 17:50 tiup cluster scale-out実⾏（TiDB7台＋TiKV6台） TiDBの検証について︓実施した検証 [3]
113. 113/140 TiDBの検証について︓実施した検証 [3] CPUのスパイクがない （影響なし）
114. 114/140 シナリオ2-3実⾏＋スケールアウト後のQPSメトリクス 1秒間のリクエスト数32000の要求に対してQPS32000 Grafana︓TiDB︓Query Summary︓QPS TiDBの検証について︓実施した検証 [3] QPSは⼀定で 安定している
115. 115/140 シナリオ2-3実⾏＋スケールアウト後のConnection Countメトリクス 同時接続数1800の要求に対してConnection1800 Grafana︓TiDB︓Server︓Connection Count TiDBの検証について︓実施した検証 [3] Connectionは ⼀定で安定している
116. 116/140 負荷かけ先のTiDBインスタンス（スケールアウト後の構成） TiDBの検証について︓実施した検証 [3] TiDB9台・TiKV9台構成
117. 117/140 負荷かけ先のTiDBインスタンス（スケールアウト後の構成） TiDBの検証について︓実施した検証 [3] TiDB7台追加
118. 118/140 負荷かけ先のTiDBインスタンス（スケールアウト後の構成） TiDBの検証について︓実施した検証 [3] TiKV6台追加
119. 119/140 [4] スケールアウト後の環境で QPSが上がることを検証
120. 120/140 TiDBの検証について︓実施した検証 [4] この検証での確認（⽬的） TiDBの台数が増えた分 QPSが増加することを確認 負荷かけの実⾏時間を3分から30分に 変更して安定して動作することを確認
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
122. 122/140 最⼩要件構成⽤のシナリオを使⽤して検証 最適なQPSである16000の9倍である 144000QPSが出ること及び 30分実⾏した場合でも途中で パフォーマンスが劣化することなく 安定して動作することを確認 TiDBの検証について︓実施した検証 [4]
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
124. 124/140 シナリオ実⾏後のQPSのメトリクス 1秒間のリクエスト数144000の要求に対してQPS144000 Grafana︓TiDB︓Query Summary︓QPS TiDBの検証について︓実施した検証 [4] QPSは⼀定で 安定している
125. 125/140 シナリオ実⾏後のCPU Usageメトリクス Grafana︓TiDB︓Server︓CPU Usage TiDBの検証について︓実施した検証 [4] CPUは スパイクすることなく 安定している
126. 126/140 シナリオ実⾏後のConnection Countメトリクス 同時接続数8100の要求に対してConnection8100 Grafana︓TiDB︓Server︓Connection Count TiDBの検証について︓実施した検証 [4] Connectionは ⼀定で安定している
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の検証について
128. 128/140 TiDBの検証について CygamesのQPSは数百万で 特にイベントやアクティブな時間帯は アクセス数が多く 更にQUERYの発⾏数が増加するため ノーメンテナンスで必要なリソースに ターゲットを絞ってスケール可能なTiDBは ソーシャルゲームの運⽤に向いている
129. 129/140 TiDBの検証について ユーザー数 時間 イベントやアクティブな 時間帯はスケールアウト ⾮アクティブな 時間帯はスケールイン
130. 130/140 ソーシャルゲームはユーザーのアクセス数に応じた リソースのコントロールが必要になるため TiDB serverのスケールがメイン そのため今回の検証では TiDB serverを基準としてQPSの算出を⾏い TiDB server1台あたりの最適なQPSをもとに スケールする検証を⾏った TiDBの検証について
131. 131/140 TiDB9台追加 TiDB serverのスケールがメイン TiDB serverを9台から18台に増加して検証 TiDBの検証について
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が増加することを確認
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をスケール 台数はストレージのサイズに合わせて増加する 短期的 中・⻑期的
134. 134/140 今回は４つの検証を⾏い 期待通りの結果となりました‼ TiDBの検証について
135. 135/140 本⽇はCygamesで取り組んでる 検証の⼀部を紹介しました 今後もTiDBにおける最適な 「設計」と「運⽤」を⽬指して 引き続き検証をしていきます TiDBの検証について
136. 136/140 TiDBにおけるその他取り組み
137. 137/140 TiDBにおける Cygamesでのその他取り組みについて 少しだけ紹介します TiDBの検証は勿論なのですが 他のエンジニアの技術⼒向上のためにも TiDBの勉強会を開催しました TiDBにおけるその他取り組み
138. 138/140 Cygamesの社内勉強会「カジュアル共有会」 オンラインセッションで発表 TiDBにおけるその他取り組み タイトル 開催⽇ カジュアル共有会 〜TiDB学習前基礎知識編〜 2⽉に開催 カジュアル共有会 〜TiDBアーキテクチャー編〜 7⽉に開催（2⽇間） カジュアル共有会 〜TiDB検証編〜 要スケジュール調整
139. 139/140 今後もカジュアル共有会や その他勉強会を通じて Cygamesエンジニアの技術⼒向上に向けて 次世代データベースであるTiDBに関する 知⾒の共有が出来ればと考えています TiDBにおけるその他取り組み
140. 140/140 Chapter2 まとめ 最適なQPSを1つの指標として vegeta-mysqlを使⽤したTiDBの検証を⾏い インスタンス数に⽐例したQPSの増加を確認しました TiDBの検証 必要なリソースにターゲットを絞ってスケール可能な TiDBは⼤規模かつ変動の激しいサービスである ソーシャルゲームの運⽤に向いているかと思います TiDBとソーシャルゲームとの親和性
142. 142/195 Chapter2 おまけ 1. TiDBの環境構築について 2. 検証環境構築の⾃動化について 3. ダミーQUERYの増幅について セッション発表対象外
143. 143/195 TiDBの環境構築について お ま け
144. 144/195 TiDBの環境構築はパッケージマネージャー TiUP（TiUPコマンド）を使⽤して構築します TiUPコマンドを使⽤することで環境構築を ⾮常に簡単に⾏うことができます TiDBの環境構築について TiUP Overview︓https://docs.pingcap.com/tidb/stable/tiup-overview
145. 145/195 環境構築で利⽤可能なコンポーネントとして 「playgroundやcluster」等がありますが TiUP Clusterコマンドを使⽤した 構築⽅法について説明します TiDBの環境構築について TiUP Cluster︓https://docs.pingcap.com/tidb/stable/tiup-component-cluster
146. 146/195 TiDBの環境構築について TiDBバージョンの取得 tiup list tidb ・・・ 後述する「TiUP実⾏環境」への事前準備が完了した場合に tidb-managerから実⾏する tiup list︓https://docs.pingcap.com/tidb/stable/tiup-command-list
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環境構築リスト
148. 148/195 TiDBの環境構築 準備編
149. 149/195 TiDBの環境構築 [準備編] 1. TiDBインスタンスを準備 2. TiDBデプロイ前の事前準備 3. TiDBデプロイ⽤のトポロジを準備
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
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コマンドはここで実⾏する）
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
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 ＋
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アドレスを記載する
155. 155/195 TiDBの環境構築 チェック編
156. 156/195 TiDBの環境構築 [チェック編] 1.TiDBクラスターをチェック
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
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
159. 159/195 TiDBの環境構築 デプロイ編
160. 160/195 TiDBの環境構築 [デプロイ編] 1. TiDBクラスターをデプロイ 2. TiDBクラスターを開始 3. TiDBクラスターのステータスを確認
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.]
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
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クラスター名を指定
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
165. 165/195 検証環境構築の⾃動化について お ま け
166. 166/195 検証環境構築の⾃動化について 概要 ツール名 略称 EC2インスタンス構築 AWS-Automation-Support aas TiDB環境構築 TiDB-Deployment-Manager tdm 負荷試験環境構築 Majin-Vegeta-Mysql mvm 下記のツールを使⽤して⾃動化 検証環境 簡単ではありますが説明します
167. 167/195 EC2インスタンス構築
168. 168/195 検証環境構築の⾃動化︓EC2インスタンス構築 ec2_orchestration _instance EC2インスタンス 管理完了 instance.cnfに記載されたインスタンス名を元に スクリプトを実⾏してEC2インスタンスを管理 ①インスタンスを記載 ②スクリプトを実⾏ instance.cnf
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 … …
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. …
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
172. 172/195 TiDB環境構築
173. 173/195 検証環境構築の⾃動化︓TiDB環境構築 TiDB Cluster 管理完了 tidb_instance.cnfに記載されたインスタンス名を元に スクリプトを実⾏してTiDB Clusterを管理 ①TiDBインスタンスを記載 ②スクリプトを実⾏ tidb_ instance.cnf tidb_setup
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 …
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
176. 176/195 スクリプト実⾏後にTiDBが使⽤可能になります 検証環境構築の⾃動化︓TiDB環境構築
177. 177/195 負荷試験環境構築
178. 178/195 検証環境構築の⾃動化︓負荷試験環境構築 mvm_edit_cnf ホスト名だけでなくIPアドレスを含めた 負荷かけ元(mvm)のcnfを⽣成 ①mvmインスタンスを記載 ②スクリプトを実⾏ mvm_load_source.cnf⽣成 mvm_load_ source.cnf mvm_ instance.cnf
179. 179/195 検証環境構築の⾃動化︓負荷試験環境構築 mvm_edit_cnf 指定したシナリオグループのQUERYを 負荷かけ元(mvm)へアップロードするためのcnfを⽣成 ①シナリオグループを設定 mvm_query.cnf⽣成 mvm_query.cnf mvm_load_ source.cnf ②スクリプトを実⾏ シナリオグループ
180. 180/195 検証環境構築の⾃動化︓負荷試験環境構築 mvm_edit_cnf RateやConnsの値を変動させるためのcnfを⽣成 ①RateやConnsの変動パラメータを設定 mvm_load_level.cnf⽣成 mvm_load_ level.cnf ②スクリプトを実⾏ 負荷レベル
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
182. 182/195 検証環境構築の⾃動化︓負荷試験環境構築 mvm_query.cnfに記載された情報を元に 負荷かけ元(mvm)へQUERYをアップロード ①⽣成したQUERYの情報 QUERYアップロード パラメータ upload QUERY アップロード完了 ②スクリプトを実⾏ mvm_query.cnf mvm_ orchestration
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] ・負荷かけ先の情報
184. 184/195 検証環境構築の⾃動化︓負荷試験環境構築 mvm_attack_scenario.cnfの情報を元に vegeta-mysqlを実⾏してTiDB環境へ負荷をかける ①負荷試験情報を設定 負荷試験の実⾏ ③vegeta-mysqlからQUERY実⾏ パラメータ attack ②スクリプトを実⾏ mvm_attack_ scenario.cnf mvm_ orchestration mvm環境 TiDB環境
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
186. 186/195 ダミーQUERYの増幅について お ま け
187. 187/195 ダミーQUERYの増幅について 概要 ツール名 略称 ダミーQUERY⽣成 Random-Query-Generator rqg 下記のツールを使⽤して増幅 ダミーQUERY 簡単ではありますが説明します
188. 188/195 rqg_ orchestration プロジェクトから出⼒されたLTSVログを元にQUERYを抽出 ベースQUERYとしてQUERYのみ出⼒ ①プロジェクトのLTSVログを準備 ベースQUERY出⼒ ダミーQUERYの増幅について プロジェクトのLTSVログはデバッグ環境で実⾏されたログ端末から 網羅的に実⾏して出⼒（QUERY以外の情報を含む） BASE QUERY 出⼒ ②スクリプトを実⾏ LTSV パラメータ upload
189. 189/195 ベースQUERYを元にQUERYの情報を登録 ②スクリプトを実⾏ QUERY情報登録 ダミーQUERYの増幅について UNIQUE QUERY QUERY情報登録 QUERY FORMAT BASE QUERY rqg_entry_ query_format ①ベースQUERYを準備
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
191. 191/195 ベースQUERYを元にダミーQUERYを⽣成 ①ベースQUERYを準備 ダミーQUERY⽣成 ダミーQUERYの増幅について DUMMY QUERY ⽣成 ②スクリプトを実⾏ ベースQUERY rqg_ orchestration パラメータ generate
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のサイズ内で 乱数⽣成
193. 193/195 ダミーQUERYの増幅について マイページ QUERY プロジェクト マイページ ダミーQUERY プレゼント QUERY ガチャ QUERY 負荷試験 増幅 プレゼント ダミーQUERY 増幅 ガチャ ダミーQUERY 増幅 マイページの 負荷レベルで設定 プレゼントの 負荷レベルで設定 ガチャの 負荷レベルで設定 QUERY実⾏ QUERY実⾏ QUERY実⾏ TiDB マイページ を1回実⾏ プレゼント を1回実⾏ ガチャ を1回実⾏ 出⼒ 出⼒ 出⼒ 各機能を1回実⾏して機能毎にQUERYを管理して増幅 疑似的に負荷試験を⾏う等の応⽤も可能
194. 194/195 vegeta-mysqlでの負荷試験は 準備したQUERYを実⾏するため 負荷試験に必要なQUERYを準備すること⾃体が プロジェクトとの調整も含めて ⼤変になるかと思います ダミーQUERYの増幅について
195. 195/195 しかしながら QUERYを増幅出来ればプロジェクト側の⼯数を なるべく取ることなくQUERYを準備することが 可能になるのではないか︖と考えています ダミーQUERYの増幅について