DMMの取り組み最前線 ~フルマネージドNewSQLであるTiDB Cloudの可能性~

DB Tech Showcase 2022の2022.11.16 (水) 11:00 - 11:45 C-1セッションの発表で使用したスライドです。

Transcript

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

   View Slide

2. © DMM.com
   

   View Slide

3. © DMM.com
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. © 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の特長をいいところ取りしたデータベース
    

    View Slide

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

    View Slide

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

    

    View Slide

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

    View Slide

18. © 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）*今回は未検証
    

    View Slide

19. © 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
    

    View Slide

20. © 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も対応
    

    View Slide

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

    View Slide

22. © DMM.com
    性能面
    22
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

32. © 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
    それ以外はランダムな値
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

39. © 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
    

    View Slide

40. © 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
    

    View Slide

41. © 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
    

    View Slide

42. © 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
    

    View Slide

43. © 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

50. © 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 = ?;
    

    View Slide

51. © 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%
    

    View Slide

52. © 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%
    

    View Slide

53. © 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）*今回は未検証
    

    View Slide

54. © 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%
    

    View Slide

55. © 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%
    

    View Slide

56. © 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%
    

    View Slide

57. © 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%
    

    View Slide

58. © 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%
    性能試験サマリー（レイテンシ）
    

    View Slide

59. © 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%
    性能試験サマリー（レイテンシ）
    

    View Slide

60. © 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%
    性能試験サマリー（レイテンシ）
    

    View Slide

61. © 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%
    

    View Slide

62. © 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%
    

    View Slide

63. © 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%
    性能試験サマリー（スループット）
    

    View Slide

64. © DMM.com
    運用面
    64
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

72. © DMM.com
    移行面
    72
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

77. © DMM.com
    終わり
    77
    

    View Slide