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

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

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

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

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

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

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

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

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

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

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

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

© 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

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

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

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

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

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

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

© 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Decks by PingCAP-Japan

Other Decks in Technology

Featured

Transcript