$30 off During Our Annual Pro Sale. View Details »

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

yuyu_hf
PRO
November 17, 2022

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

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

yuyu_hf
PRO

November 17, 2022
Tweet

More Decks by yuyu_hf

Other Decks in Technology

Transcript

  1. © DMM.com DB TECH SHOWCASE 2022 合同会社DMM.com プラットフォーム事業本部 @yuyu_hf 1

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

  3. © DMM.com

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

    基盤に不具合が起きると、それがそのままDMMの不具合になってしまう、、 DMMの多くのサービスが停止してしまう非常に重要な基盤を扱っている 4
  5. © DMM.com DBの検証をする動機 DMMプラットフォームのアプリケーションの多くはオンプレを利用 → 最近ではAWS/GCPなどのパブリッククラウドも使い始めた その背景からオンプレ・AWS・GCPなどあらゆる環境が混在している プラットフォーム事業本部では今後数年にかけてクラウド化の計画がある 認証認可のアプリケーションをクラウド移行するプロジェクトが発足 →

    まずはオンプレのDB(MySQL)からクラウド移行する 5
  6. © DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・既存の認証認可アプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性

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

    ・データにリレーションを持たせることができる(Joinができる) 7
  8. © DMM.com 認証認可のアプリケーション ダウンタイムは許されない。厳しい負荷とレイテンシの要件がある 8 API Gateway 認証/認可 動画 会員/決済/…

    DMMプラットフォーム 電子書籍 ① ② ③
  9. © DMM.com 移行候補のDB 移行候補のDBの要件 ・ダウンタイムがない ・既存の認証認可アプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする ・強整合性

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

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

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

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

    ・データにリレーションを持たせることができる(Joinができる) → NewSQLを検討 13
  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の特長をいいところ取りしたデータベース
  15. © DMM.com 移行候補のDB 15 移行候補のDBの要件 ・ダウンタイムがない ・直近で移行予定のアプリケーションの負荷に耐えられる ・フルマネージドサービス ・Write がスケールする

    ・強整合性 ・データにリレーションを持たせることができる(Joinができる) → Cloud Spannerが候補にあがった
  16. © DMM.com TiDB Cloud ・フルマネージドのNewSQL ・マルチプラットフォーム(GCP/AWS) ・MySQL互換 16 2000 2010

    2020 NewSQLの先駆け

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

    Cloudの検証をすることを決めた 17
  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)*今回は未検証
  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単位で分割して管理 ②3面コピーをとっている ③Region-Leaderに対してIO
  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も対応
  21. © DMM.com 検証の観点 以下の3つの軸で検証/考察してみる 21 検証項目 詳細 性能面 既存のアプリケーションの負荷を捌 けるか検証

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

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

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

    locust extensions(boomer) 24
  25. © DMM.com 負荷試験の条件 25 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間

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

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

    キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件(Deleteの試験のみ3億件) その他 99%ile レイテンシが100 ms以内の試験のみ有効
  28. © DMM.com 試験回数と試験時間の決め方 事前にパラメーターチューニングの負荷試験を大量に実施した → 試験するタイミングや試験時間によってDBのパフォーマンスがあまり変 わらない 28

  29. © DMM.com 負荷試験の条件 29 負荷の指定方法 locustの並列数を100刻みで実施 試験回数 1回 試験時間 1時間

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

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

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

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

    キャッシュ なし テーブルスキーマ 移行元のアプリケーションで最もよく使っているテーブルと同じ構造 使用するデータ ダミーデータ 試験開始時のDBのレコード数 6,000万件(Deleteの試験のみ3億件) その他 99%ile レイテンシが100 ms以内の試験のみ有効
  35. © DMM.com DBのクライアント DBのパフォーマンスを発揮できる設定 35 Goのライブラリ gorm 最大Openコネクション数 locustの並列数と同じ 最大Idleコネクション数

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

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

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

    最大Openコネクション数と同じ timeout値 100 ms
  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
  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
  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
  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
  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
  44. © DMM.com アーキテクチャ 44 Microservice Platform Kubenetes Engine PrimaryKey Cache

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

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

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

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

    Memorystore CSV data for import Cloud Storage TiDBCloud TiDB TiDB KV KV KV
  49. © DMM.com store-io-pool-sizeの有効化 TiKVで以下の2つの処理を逐次的 -> 並行処理する ・ディスクへのログの書き込み ・ディスクへのデータの書き込み TiKVで発行されるThread数が増える →

    TiKV Serverの負荷が増える 事前検証中の結果ですがWriteのQPSが4倍に増えました 49
  50. © DMM.com 試験で利用したSQLクエリ 1件のレコードのCRUDの性能のみ調査 ・primary keyを指定するときはprepared statementを利用 ・トランザクションの作成はDB側で暗黙的に行う 50 試験の項目

    SQLクエリ Read SELECT * FROM <テーブル名> WHERE <primary_key> = ?; Create INSERT INTO <テーブル名> (...) VALUES(...); Update UPDATE <テーブル名> SET <primary key以外のカラムの値を更新> WHERE <primary_key> = ?; Delete DELETE FROM <テーブル名> WHERE <primary_key> = ?;
  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%
  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%
  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)*今回は未検証
  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%
  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%
  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%
  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%
  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% 性能試験サマリー(レイテンシ)
  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% 性能試験サマリー(レイテンシ)
  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% 性能試験サマリー(レイテンシ)
  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%
  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%
  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% 性能試験サマリー(スループット)
  64. © DMM.com 運用面 64

  65. © DMM.com 運用で必要な機能の調査結果(一部抜粋) 実績のあるクラウドサービスと同等の運用性 Datadog連携もできるので、運用性は◦ 65 terraformでリソース管理 できる 無停止でカラムの追加 できる

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

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

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

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

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

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

    無停止でスケールイン /アウト できる オートスケールイン/アウト できない ※ロードマップにはある(現状は APIを活用) 無停止でメンテナンスをのりきる できる メトリクスの収集 できる。Datadog連携もサポートしている 監査ログの収集 できる ※ただし、データを確認する仕組みはない
  72. © DMM.com 移行面 72

  73. © DMM.com TiDB Cloudへの移行面のメリット 73 MySQL互換 MySQLエコシステムを利用できる。移行元のアプリケーションからTiDB Cloudへの疎通確認で、アプリケーションコードの変更がほとんどなかった (IPアドレスの変更しかしなかった) DataMigrationツール

    現時点で未検証だが、TiDB Data Migration(DM)というTiDB向けツールを 活用して現状のオンプレMySQLから簡単に移行できそう。実際の切替/切戻 についても、TiCDCというツールを使って安全に切替できそう
  74. © DMM.com まとめ MySQL互換のNewSQLであるTiDB Cloudも充分検討できる 74 検証項目 結果 性能面 既存のアプリケーションの負荷を捌けるか

    検証 実際の認証認可のアプリケーションでのユース ケースを踏まえると、 QPS/レイテンシの要件は十 分に満たしている 運用面 運用する上で必要な機能をサポートして いるか調査 定常的な運用で必要な機能は十分にある ダウンタイムなしでという観点でも、検証自体はこ れからだが、期待ができる 移行性 移行するときの問題点や工数の調査 アプリ/インフラ/データの各観点で移行は実現でき そう アプリケーションコードの観点においても、改修工 数少なくすむのは非常に助かる
  75. アンケートご協力へのお願い db tech showcase 2022 アンケート回答で Amazonギフト券1000円分または PingCAPロゴ入りのノベルティを 抽選で100名様にプレゼント! 回答期限は11/21(月)13:00PMまで。

    ※アンケートに回答する際、セッション参加のメールアドレスのご使用をお願い いたします。 ※当選は、Amazonギフト券のメール案内、またはノベルティの発送をもって代 えさせていただきます。 URL: https://customform.jp/form/input/124060 #dbts2022TiDB
  76. テキスタイルモバイル アクセサリーケース(L) サーモステンレスマグ 380ml Tシャツ シルバー ブラック ブラック PingCAPロゴ入りノベルティ例 #dbts2022TiDB

  77. © DMM.com 終わり 77