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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2/140 Cygamesについて

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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 メンテナンス (サービス停⽌) スケールアウトデータリバランスバランシングルール更新

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

28/140 TiDBへの取り組み Chapter2

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

46/140 TiDBの検証について

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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の実⾏に使⽤したツール

Slide 53

Slide 53 text

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に戻る（以降、指定時間分繰り返す）

Slide 54

Slide 54 text

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の実⾏に使⽤したツール

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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...）

Slide 58

Slide 58 text

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...）

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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)

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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]

Slide 73

Slide 73 text

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を実⾏

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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]

Slide 78

Slide 78 text

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]

Slide 79

Slide 79 text

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]

Slide 80

Slide 80 text

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秒以内に集約して表⽰ヒストグラムの結果を⾒やすくするため

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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倍の値

Slide 94

Slide 94 text

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倍の値

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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 追加 … …

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

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の検証について

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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が増加することを確認

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

No content

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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環境構築リスト

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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コマンドはここで実⾏する）

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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 ＋

Slide 154

Slide 154 text

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アドレスを記載する

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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.]

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

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クラスター名を指定

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

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 … …

Slide 170

Slide 170 text

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. …

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

172/195 TiDB環境構築

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

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 …

Slide 175

Slide 175 text

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

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

177/195 負荷試験環境構築

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

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

Slide 180

Slide 180 text

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

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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] ・負荷かけ先の情報

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

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

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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のサイズ内で乱数⽣成

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

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