Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

PingCAP-Japan
November 22, 2022

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

DMMプラットフォームではNewSQLデータベースの導入を検討しています。そこで、MySQL互換のNewSQLデータベースとしてTiDB Cloudを検証しました。 本スライドでは、パフォーマンスだけでなく運用面や移行性などの観点も含めた内容を紹介します。

出典:db tech showcase 2022

アーカイブ動画:
https://youtu.be/qiz2SSKXrck

PingCAP-Japan

November 22, 2022
Tweet

More Decks by PingCAP-Japan

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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



    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  12. © 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 full-size slide

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

    View full-size slide

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


    View full-size slide

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

    View full-size slide

  16. © 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 full-size slide

  17. © 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単位で分割して管理
    ②3面コピーをとっている
    ③Region-Leaderに対してIO

    View full-size slide

  18. © 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 full-size slide

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

    View full-size slide

  20. © DMM.com
    性能面
    22

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. © 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. © 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 full-size slide

  38. © 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 full-size slide

  39. © 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 full-size slide

  40. © 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 full-size slide

  41. © 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  48. © 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 full-size slide

  49. © 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 full-size slide

  50. © 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 full-size slide

  51. © 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 full-size slide

  52. © 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 full-size slide

  53. © 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 full-size slide

  54. © 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 full-size slide

  55. © 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 full-size slide

  56. © 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 full-size slide

  57. © 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 full-size slide

  58. © 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 full-size slide

  59. © 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 full-size slide

  60. © 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 full-size slide

  61. © 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 full-size slide

  62. © DMM.com
    運用面
    64

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  70. © DMM.com
    移行面
    72

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  73. © DMM.com
    終わり
    75

    View full-size slide