Tweet
Tweet

Slide 1

Slide 1 text

© DMM.com DB TECH SHOWCASE 2022 合同会社DMM.com プラットフォーム事業本部 @yuyu_hf 1 DMMの取り組み最前線 ~フルマネージドNewSQLであるTiDB Cloudの可能性~

Slide 2

Slide 2 text

© DMM.com

Slide 3

Slide 3 text

© DMM.com

Slide 4

Slide 4 text

© DMM.com プラットフォーム事業本部 プラットフォーム事業本部の役割と重要性 プラットフォーム事業本部は DMMの各サービスで共通して使われる基盤を開発している部署 ex) 会員の管理、ユーザーの認証、認可、各種決済周り、DMMポイントやtoreta+といった電子マネーの仕組みを提供 DMMの各種サービスは、プラットフォーム事業本部がAPIの形で提供している機能を利用して作られている つまり、、、 基盤に不具合が起きると、それがそのままDMMの不具合になってしまう、、 DMMの多くのサービスが停止してしまう非常に重要な基盤を扱っている 4

Slide 5

Slide 5 text

© DMM.com DBの検証をする動機 DMMプラットフォームのアプリケーションの多くはオンプレを利用 → 最近ではAWS/GCPなどのパブリッククラウドも使い始めた その背景からオンプレ・AWS・GCPなどあらゆる環境が混在している プラットフォーム事業本部では今後数年にかけてクラウド化の計画がある 認証認可のアプリケーションをクラウド移行するプロジェクトが発足 → まずはオンプレのDB(MySQL)からクラウド移行する 5

Slide 6

Slide 6 text

© DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・既存の認証認可アプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性 ・データにリレーションを持たせることができる（Joinができる） 6

Slide 7

Slide 7 text

© DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・既存の認証認可アプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性 ・データにリレーションを持たせることができる（Joinができる） 7

Slide 8

Slide 8 text

© DMM.com 認証認可のアプリケーション ダウンタイムは許されない。厳しい負荷とレイテンシの要件がある 8 API Gateway 認証/認可 動画 会員/決済/… DMMプラットフォーム 電子書籍 ① ② ③

Slide 9

Slide 9 text

© DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・既存の認証認可アプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性 ・データにリレーションを持たせることができる（Joinができる） 9

Slide 10

Slide 10 text

© DMM.com フルマネージドサービスの理由 プラットフォーム事業本部の課題感 オンプレのインフラ周りの変更はインフラ部に作業を依頼する必要がある ・インフラ部の作業待ちが発生している ・調整コストがかかる → 開発効率が悪い 10

Slide 11

Slide 11 text

© DMM.com フルマネージドサービスの理由 アプリケーション開発チームだとオンプレを管理できない → インフラ環境のクラウド化 アプリケーション開発チームがDBを管理する方針にした → フルマネージドサービスを選ぶしかない 11

Slide 12

Slide 12 text

© DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・既存の認証認可アプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性 ・データにリレーションを持たせることができる（Joinができる） 12

Slide 13

Slide 13 text

© DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・直近で移行予定のアプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性 ・データにリレーションを持たせることができる（Joinができる） → NewSQLを検討 13

Slide 14

Slide 14 text

© DMM.com 14 NewSQLとは RDB (ex. MySQL) NoSQL (ex. Cassandra) New SQL (ex. TiDB) CAPの考え方 CA AP CP+HA クエリ SQL API, SQL(CQL) SQL 　- トランザクション 〇 X 〇 　- JOIN 〇 X 〇 Readスケーラビリティ 〇 リードレプリカ ◎ 分散アーキテクチャ ◎ 分散アーキテクチャ Writeスケーラビリティ △ Writerは単一ボトルネック （要シャーディング） ◎ 分散アーキテクチャ ◎ 分散アーキテクチャ (大きい1テーブル対応可) RDBとNoSQLの特長をいいところ取りしたデータベース

Slide 15

Slide 15 text

© DMM.com 移行候補のDB 15 移行候補のDBの要件 ・ダウンタイムがない ・直近で移行予定のアプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性 ・データにリレーションを持たせることができる（Joinができる） → Cloud Spannerが候補にあがった

Slide 16

Slide 16 text

© DMM.com TiDB Cloud ・フルマネージドのNewSQL ・マルチプラットフォーム（GCP/AWS） ・MySQL互換 16 2000 2010 2020 NewSQLの先駆け


Slide 17

Slide 17 text

© DMM.com DBの要件外の要望 MySQL互換 認証認可のアプリケーションではMySQLを使っている ・アプリケーションコードの修正工数が少ない ・SQLなどの学習コストが低い ・MySQLエコシステムを利用することができる → TiDB Cloudの検証をすることを決めた 17

Slide 18

Slide 18 text

© DMM.com 18 　　　　　　とは ストレージノード
 
 データストアレイヤー ( TiKV Cluster )
 
 コンピューティングノード 
 
 SQL解析レイヤー ( TiDB Cluster )
 
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB 負荷分散・領域管理 
 3ノードのみ必要 
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD MySQLでデータベースと対話
 Raftを採用したKVSでバックアップを兼ね備える
 TiDBの司令塔
 ( Placement Driver )
 ①スケールアウト型のNewSQLデータベース ②マルチプラットフォーム可能。フルマネージドサービスも(TiDB Cloud) ③OLTPとOLAPを一つのDBで（HTAP）*今回は未検証

Slide 19

Slide 19 text

© DMM.com Regionの考え方 19 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 TiDB TiDB コンピューティング
 ノード
 ストレージノード
 region Leader：IO対象 region Follower：バックアップ sample table ①Region単位で分割して管理 ②３面コピーをとっている ③Region-Leaderに対してIO

Slide 20

Slide 20 text

© DMM.com ダウンタイムなしで運用したい 20 スケール ノード追加した瞬間からデータ移行が開始 　　IOは継続して行われる TiDBのバージョンアップ 　　 Leaderを別ノードへ移動し 　　 ローリングアップグレード TiKV-0 TiKV-1 TiKV-2 TiKV-3 region 1 region 1 region 1 region 3 region 2 region 2 region 4 region 3 region 3 region 5 region 4 region 5 region 2 region 4 region 5 TiKV-4 region 2 region 4 region 1 工夫によりダウンタイムなし TiKV-0 TiKV-1 TiKV-2 TiKV-3 region 1 region 1 region 1 region 3 region 2 region 2 region 4 region 3 region 3 region 5 region 4 region 5 region 2 region 4 region 5 Leaderを移動しながら 順にアップグレード対応 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region 1 region 1 region 1 region 3 region 2 region 2 region 4 region 3 region 3 region 5 region 4 region 5 region 2 region 4 region 5 障害時挙動 TiKV障害時はリーダーが他の TiKVノードに移動 サービスは継続 *オンラインDDLも対応

Slide 21

Slide 21 text

© DMM.com 検証の観点 以下の3つの軸で検証/考察してみる 21 検証項目 詳細 性能面 既存のアプリケーションの負荷を捌 けるか検証 認証認可基盤で発行されるクエリを一部模倣したもの を使い、既存のアプリケーションの負荷を捌けるか 運用面 運用する上で必要な機能をサポート しているか調査 運用する上で必要な機能をサポートしているか 移行性 移行するときの問題点や工数の調査 移行元のアプリケーションコードにどれくらい手を入れ なければならないか 移行元のオンプレから通信することはできるか

Slide 22

Slide 22 text

© DMM.com 性能面 22

Slide 23

Slide 23 text

© DMM.com 負荷試験で確かめること 既存のアプリケーションの負荷に耐えられるか ・QPS: 20,000 ・99%ileレイテンシ: 100 ms以内 23

Slide 24

Slide 24 text

© DMM.com 負荷試験ツール アプリケーションのリプレースでGoに移行する → Goのライブラリの使い勝手も確かめたい Goで試験スクリプトが書ける負荷試験ツールを選定する → locust + locust extensions(boomer) 24

Slide 25

Slide 25 text

© DMM.com 負荷試験の条件 25 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 26

Slide 26 text

© DMM.com 負荷試験の条件 26 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 27

Slide 27 text

© DMM.com 負荷試験の条件 27 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 28

Slide 28 text

© DMM.com 試験回数と試験時間の決め方 事前にパラメーターチューニングの負荷試験を大量に実施した → 試験するタイミングや試験時間によってDBのパフォーマンスがあまり変 わらない 28

Slide 29

Slide 29 text

© DMM.com 負荷試験の条件 29 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 30

Slide 30 text

© DMM.com 負荷試験の条件 30 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 31

Slide 31 text

© DMM.com 負荷試験の条件 31 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 32

Slide 32 text

© DMM.com ダミーデータ テーブルのスキーマ CREATE TABLE sample ( sample1 VARCHAR NOT NULL, sample2 VARCHAR NOT NULL, sample3 BINARY, sample4 INT NOT NULL, sample5 INT NOT NULL, sample6 INT NOT NULL, sample7 INT NOT NULL, created_at TIMESTAMP NOT NULL, created_by VARCHAR NOT NULL, updated_at TIMESTAMP NOT NULL, updated_by VARCHAR NOT NULL ) PRIMARY KEY (sample1); 32 ダミーデータの生成方法 sample1とsample2はUUID それ以外はランダムな値

Slide 33

Slide 33 text

© DMM.com 負荷試験の条件 33 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 34

Slide 34 text

© DMM.com 負荷試験の条件 34 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間 キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件（Deleteの試験のみ3億件） その他 99%ile レイテンシが100 ms以内の試験のみ有効

Slide 35

Slide 35 text

© DMM.com DBのクライアント DBのパフォーマンスを発揮できる設定 35 Goのライブラリ gorm 最大Openコネクション数 locustの並列数と同じ 最大Idleコネクション数 最大Openコネクション数と同じ timeout値 100 ms

Slide 36

Slide 36 text

© DMM.com DBのクライアント DBのパフォーマンスを発揮できる設定 36 Goのライブラリ gorm 最大Openコネクション数 locustの並列数と同じ 最大Idleコネクション数 最大Openコネクション数と同じ timeout値 100 ms

Slide 37

Slide 37 text

© DMM.com DBのクライアント DBのパフォーマンスを発揮できる設定 37 Goのライブラリ gorm 最大Openコネクション数 locustの並列数と同じ 最大Idleコネクション数 最大Openコネクション数と同じ timeout値 100 ms

Slide 38

Slide 38 text

© DMM.com DBのクライアント DBのパフォーマンスを発揮できる設定 38 Goのライブラリ gorm 最大Openコネクション数 locustの並列数と同じ 最大Idleコネクション数 最大Openコネクション数と同じ timeout値 100 ms

Slide 39

Slide 39 text

© DMM.com TiDB Cloudのインフラ構成 39 クラウド GCP クラスター シングルクラスター Region asia-northeast1 Zone asia-northeast1-a asia-northeast1-b asia-northeast1-c VPC Peering なし ノードサイズ TiDB Server 2 instances 8 vCPU, 32 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB

Slide 40

Slide 40 text

© DMM.com TiDB Cloudのインフラ構成 40 クラウド GCP クラスター シングルクラスター Region asia-northeast1 Zone asia-northeast1-a asia-northeast1-b asia-northeast1-c VPC Peering なし ノードサイズ TiDB Server 2 instances 8 vCPU, 32 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB

Slide 41

Slide 41 text

© DMM.com TiDB Cloudのインフラ構成 41 クラウド GCP クラスター シングルクラスター Region asia-northeast1 Zone asia-northeast1-a asia-northeast1-b asia-northeast1-c VPC Peering なし ノードサイズ TiDB Server 2 instances 8 vCPU, 32 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB

Slide 42

Slide 42 text

© DMM.com TiDB Cloudのインフラ構成 42 クラウド GCP クラスター シングルクラスター Region asia-northeast1 Zone asia-northeast1-a asia-northeast1-b asia-northeast1-c VPC Peering なし ノードサイズ TiDB Server 2 instances 8 vCPU, 32 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB

Slide 43

Slide 43 text

© DMM.com TiDB Cloudのインフラ構成 43 クラウド GCP クラスター シングルクラスター Region asia-northeast1 Zone asia-northeast1-a asia-northeast1-b asia-northeast1-c VPC Peering なし ノードサイズ TiDB Server 2 instances 8 vCPU, 32 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB

Slide 44

Slide 44 text

© DMM.com アーキテクチャ 44 Microservice Platform Kubenetes Engine PrimaryKey Cache Memorystore CSV data for import Cloud Storage TiDBCloud TiDB TiDB KV KV KV

Slide 45

Slide 45 text

© DMM.com アーキテクチャ 45 Microservice Platform Kubenetes Engine PrimaryKey Cache Memorystore CSV data for import Cloud Storage TiDBCloud TiDB TiDB KV KV KV

Slide 46

Slide 46 text

© DMM.com アーキテクチャ 46 Microservice Platform Kubenetes Engine PrimaryKey Cache Memorystore CSV data for import Cloud Storage TiDBCloud TiDB TiDB KV KV KV

Slide 47

Slide 47 text

© DMM.com アーキテクチャ 47 Microservice Platform Kubenetes Engine PrimaryKey Cache Memorystore CSV data for import Cloud Storage TiDBCloud TiDB TiDB KV KV KV

Slide 48

Slide 48 text

© DMM.com アーキテクチャ 48 Microservice Platform Kubenetes Engine PrimaryKey Cache Memorystore CSV data for import Cloud Storage TiDBCloud TiDB TiDB KV KV KV

Slide 49

Slide 49 text

© DMM.com store-io-pool-sizeの有効化 TiKVで以下の2つの処理を逐次的 -> 並行処理する ・ディスクへのログの書き込み ・ディスクへのデータの書き込み TiKVで発行されるThread数が増える → TiKV Serverの負荷が増える 事前検証中の結果ですがWriteのQPSが4倍に増えました 49

Slide 50

Slide 50 text

© DMM.com 試験で利用したSQLクエリ 1件のレコードのCRUDの性能のみ調査 ・primary keyを指定するときはprepared statementを利用 ・トランザクションの作成はDB側で暗黙的に行う 50 試験の項目 SQLクエリ Read SELECT * FROM <テーブル名> WHERE = ?; Create INSERT INTO <テーブル名> (...) VALUES(...); Update UPDATE <テーブル名> SET WHERE = ?; Delete DELETE FROM <テーブル名> WHERE = ?;

Slide 51

Slide 51 text

© DMM.com Read 51 Locustの並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU 100 47,900 49,700 2.06 ms 76% 31.62% 200 66,700 68,600 3.71 ms 93% 38.75% 300 69,200 73,800 13.1 ms 93% 36.5% 400 68,900 71,600 14.6 ms 94.12% 35.5% 500 68,000 69,000 21.4 ms 94.12% 31.25%

Slide 52

Slide 52 text

© DMM.com Read 52 Locustの並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU 100 47,900 49,700 2.06 ms 76% 31.62% 200 66,700 68,600 3.71 ms 93% 38.75% 300 69,200 73,800 13.1 ms 93% 36.5% 400 68,900 71,600 14.6 ms 94.12% 35.5% 500 68,000 69,000 21.4 ms 94.12% 31.25%

Slide 53

Slide 53 text

© DMM.com 53 　　　　　とは ストレージノード
 
 データストアレイヤー ( TiKV Cluster )
 
 コンピューティングノード 
 
 SQL解析レイヤー ( TiDB Cluster )
 
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB 負荷分散・領域管理 
 3ノードのみ必要 
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD MySQLでデータベースと対話
 Raftを採用したKVSでバックアップを兼ね備える
 TiDBの司令塔
 ( Placement Driver )
 ①スケールアウト型のNewSQLデータベース ②マルチプラットフォーム可能。フルマネージドサービスも(TiDB Cloud) ③OLTPとOLAPを一つのDBで（HTAP）*今回は未検証

Slide 54

Slide 54 text

© DMM.com Read 54 Locustの並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU 100 47,900 49,700 2.06 ms 76% 31.62% 200 66,700 68,600 3.71 ms 93% 38.75% 300 69,200 73,800 13.1 ms 93% 36.5% 400 68,900 71,600 14.6 ms 94.12% 35.5% 500 68,000 69,000 21.4 ms 94.12% 31.25%

Slide 55

Slide 55 text

© DMM.com Create 55 Locustの並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU 100 14,600 15,200 15.4 ms 46.25% 41.625% 200 22,300 25,100 25.6 ms 61% 50.5% 400 30,600 35,100 41.4 ms 73.62% 57% 500 32,900 38,000 48.1 ms 77.25% 58.25% 600 33,500 38,900 58.7 ms 80% 58.87% 700 35,400 41,000 62.5 ms 80.75% 59.87% 800 37,300 43,000 63 ms 83.25% 60.25%

Slide 56

Slide 56 text

© DMM.com Update 56 Locustの並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU 100 12,900 13,800 15.5 ms 55.87% 47.25% 200 19,200 20,700 28 ms 73.25% 59.5% 300 23,600 25,700 31.5 ms 79.25% 64.12% 400 24,000 25,000 52.8 ms 86.25% 63.25% 500 25,600 27,300 59.2 ms 88.62% 64.75% 600 27,700 30,500 61.6 ms 86.87% 66.5% 700 27,800 30,000 62.6 ms 90.37% 66.375%

Slide 57

Slide 57 text

© DMM.com Delete 57 Locustの並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU 100 13,100 13,800 14.7 ms 49.75% 48.87% 200 19,700 21,200 22.9 ms 62,62% 59.75% 400 24,600 27,000 33 ms 75.5% 68.25% 500 27,000 30,300 49.9 ms 73.62 % 69.12% 600 26,800 29,800 56.9 ms 78% 70.5% 700 28,900 32,600 59.7 ms 77.5% 70.75% 800 29,100 32,100 63.5 ms 81.12% 71%

Slide 58

Slide 58 text

© DMM.com 既存のアプリケーションと同じ負荷をかけたときに、99%ileのレイテンシが 100 ms以内で収まる 58 試験項目 並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU Read 200 66,700 68,600 3.71 ms 93% 38.75% Create 200 22,300 25,100 25.6 ms 61% 50.5% Update 200 19,200 20,700 28 ms 73.25% 59.5% Delete 200 19,700 21,200 22.9 ms 62,62% 59.75% 性能試験サマリー（レイテンシ）

Slide 59

Slide 59 text

© DMM.com 既存のアプリケーションと同じ負荷をかけたときに、99%ileのレイテンシが 100 ms以内で収まる 59 試験項目 並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU Read 200 66,700 68,600 3.71 ms 93% 38.75% Create 200 22,300 25,100 25.6 ms 61% 50.5% Update 200 19,200 20,700 28 ms 73.25% 59.5% Delete 200 19,700 21,200 22.9 ms 62,62% 59.75% 性能試験サマリー（レイテンシ）

Slide 60

Slide 60 text

© DMM.com 99%ileのレイテンシが100 ms以内で収まっている 60 試験項目 並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU Read 200 66,700 68,600 3.71 ms 93% 38.75% Create 200 22,300 25,100 25.6 ms 61% 50.5% Update 200 19,200 20,700 28 ms 73.25% 59.5% Delete 200 19,700 21,200 22.9 ms 62,62% 59.75% 性能試験サマリー（レイテンシ）

Slide 61

Slide 61 text

© DMM.com 既存のアプリケーションの負荷20,000QPS以上は捌けそう 61 性能試験サマリー（スループット） 試験項目 並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU Read 400 68,900 71,600 14.6 ms 94.12% 35.5% Create 800 37,300 43,000 63 ms 83.25% 60.25% Update 700 27,800 30,000 62.6 ms 90.37% 66.375% Delete 800 29,100 32,100 63.5 ms 81.12% 71%

Slide 62

Slide 62 text

© DMM.com 既存のアプリケーションの負荷20,000QPS以上は捌けそう 62 性能試験サマリー（スループット） 試験項目 並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU Read 400 68,900 71,600 14.6 ms 94.12% 35.5% Create 800 37,300 43,000 63 ms 83.25% 60.25% Update 700 27,800 30,000 62.6 ms 90.37% 66.375% Delete 800 29,100 32,100 63.5 ms 81.12% 71%

Slide 63

Slide 63 text

© DMM.com TiDB Serverのリソースがボトルネックになっていて、TiKV Serverのリソー スに余裕がある 63 試験項目 並列数 QPS(avg) QPS(max) 99%ile TiDB CPU TiKV CPU Read 400 68,900 71,600 14.6 ms 94.12% 35.5% Create 800 37,300 43,000 63 ms 83.25% 60.25% Update 700 27,800 30,000 62.6 ms 90.37% 66.375% Delete 800 29,100 32,100 63.5 ms 81.12% 71% 性能試験サマリー（スループット）

Slide 64

Slide 64 text

© DMM.com 運用面 64

Slide 65

Slide 65 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 65 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 66

Slide 66 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 66 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 67

Slide 67 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 67 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 68

Slide 68 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 68 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 69

Slide 69 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 69 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 70

Slide 70 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 70 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 71

Slide 71 text

© DMM.com 運用で必要な機能の調査結果（一部抜粋） 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は○ 71 terraformでリソース管理 できる 無停止でカラムの追加 できる 無停止でスケールイン /アウト できる オートスケールイン/アウト できない　※ロードマップにはある（現状は APIを活用） 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる　※ただし、データを確認する仕組みはない

Slide 72

Slide 72 text

© DMM.com 移行面 72

Slide 73

Slide 73 text

© DMM.com TiDB Cloudへの移行面のメリット 73 MySQL互換 MySQLエコシステムを利用できる。移行元のアプリケーションからTiDB Cloudへの疎通確認で、アプリケーションコードの変更がほとんどなかった （IPアドレスの変更しかしなかった） DataMigrationツール 現時点で未検証だが、TiDB Data Migration(DM)というTiDB向けツールを 活用して現状のオンプレMySQLから簡単に移行できそう。実際の切替/切戻 についても、TiCDCというツールを使って安全に切替できそう

Slide 74

Slide 74 text

© DMM.com まとめ MySQL互換のNewSQLであるTiDB Cloudも充分検討できる 74 検証項目 結果 性能面 既存のアプリケーションの負荷を捌けるか 検証 実際の認証認可のアプリケーションでのユース ケースを踏まえると、 QPS/レイテンシの要件は十 分に満たしている 運用面 運用する上で必要な機能をサポートして いるか調査 定常的な運用で必要な機能は十分にある ダウンタイムなしでという観点でも、検証自体はこ れからだが、期待ができる 移行性 移行するときの問題点や工数の調査 アプリ/インフラ/データの各観点で移行は実現でき そう アプリケーションコードの観点においても、改修工 数少なくすむのは非常に助かる

Slide 75

Slide 75 text

アンケートご協力へのお願い db tech showcase 2022 アンケート回答で Amazonギフト券1000円分または PingCAPロゴ入りのノベルティを 抽選で100名様にプレゼント！ 回答期限は11/21(月)13:00PMまで。 ※アンケートに回答する際、セッション参加のメールアドレスのご使用をお願い いたします。 ※当選は、Amazonギフト券のメール案内、またはノベルティの発送をもって代 えさせていただきます。 URL: https://customform.jp/form/input/124060 #dbts2022TiDB

Slide 76

Slide 76 text

テキスタイルモバイル アクセサリーケース(L) サーモステンレスマグ 380ml Tシャツ シルバー ブラック ブラック PingCAPロゴ入りノベルティ例 #dbts2022TiDB

Slide 77

Slide 77 text

© DMM.com 終わり 77