Tweet
Tweet

Slide 1

Slide 1 text

© DMM.com クラウドネイティブ NewSQL 実現する ミッションクリティカル アプリケーション 運用 CloudNative Days Winter 2024 合同会社DMM.com プラットフォーム開発本部 い （@yuyu_hf） 1

Slide 2

Slide 2 text

© DMM.com 自己紹介 い （@yuyu_hf） ➢ 合同会社DMM.com（2019/04 - 現在） ○ プラットフォーム開発本部 認可チーム ➢ 認可APIをフルリプレースし います ○ PHP → Go ○ MySQL → TiDB Cloud ○ オンプレ → GKE/EKS 2 2

Slide 3

Slide 3 text

© DMM.com 本セッション い 2024年05月 認可API 利用し いるDBをオンプレ MySQLからクラウドネイティブ NewSQL あるTiDB Cloud 移行しました。 TiDB Cloudを運用し し らく経 使 みた所感 い 話します。 3

Slide 4

Slide 4 text

© DMM.com 本セッション 対象者 NewSQL ワードを最近聞くけ 、 よく知ら いし、採用するか迷う ... 思 いる人 ぜひ聞い ほしい。 NewSQLを採用する き 参考 し ください。 4

Slide 5

Slide 5 text

© DMM.com 今日話すこ 1. NewSQL 概要 2. DMM Platform TiDB Cloud 採用 3. 運用事例 紹介 4. TiDB Cloud ミッションクリティカル サービス 使える か？ 5

Slide 6

Slide 6 text

© DMM.com NewSQL 概要 6

Slide 7

Slide 7 text

© DMM.com 本セクション ゴール ・NewSQL 何？ ・NewSQL 良い ころ ？ ・NewSQLを使う き 注意 ？ 簡潔 回答したい。 7

Slide 8

Slide 8 text

© DMM.com NewSQL NewSQL RDB NoSQL 特長をいい ころ取りした DB す。 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テーブル対応可) 8

Slide 9

Slide 9 text

© DMM.com NewSQL 定義 NewSQL 従来 DBMS スケール き いモダン OLTPワークロード 対応す るため 新しいクラス DBMSを指します。 9 A new class of database management systems (DBMSs) called NewSQL tout their ability to scale modern on-line transaction processing (OLTP) workloads in a way that is not possible with legacy systems. 引用元: What’s Really New with NewSQL?

Slide 10

Slide 10 text

© DMM.com NewSQL 意味が広い NewSQL 定義 意味が広い 様々 DBがNewSQL 定義 当 まります。 NewSQL 呼 れ い もDBご 特徴 異 ります。 10

Slide 11

Slide 11 text

© DMM.com Spanner 代表的 NewSQL 1 Google社が開発したSpannerがあります。 Google Cloud Cloud Spanner いうサービス し 提供され います。 11

Slide 12

Slide 12 text

© DMM.com Spanner インスピレーションを受け 開発されたDB • TiDB • YugabyteDB • CockroachDB 12

Slide 13

Slide 13 text

© DMM.com TiDB TiDB PingCAP社 開発され いる NewSQL DB す。 • MySQLプロトコル互換 • マルチプラットフォーム可能 • OLTP OLAPを一 DB （HTAP） 13

Slide 14

Slide 14 text

© DMM.com TiDB アーキテクチャ 14 ストレージノード 
 
 データストアレイヤー ( iKV erver ) 
 
 コンピューティングノード 
 
 L解析レイヤー ( iDB erver ) 
 
 TiDB クエリ 増加 
 ノード追加 対応 
 TiDB TiDB 負荷分散・領域管理 
 3ノード み必要 
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加 対応 
 / Data Location
 Metadata
 PD PD PD My L データベース 対話
 aftを採用したKV バックアップを兼 備える 
 iDB 司令塔 
 ( lacement Driver ) 


Slide 15

Slide 15 text

© DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 15

Slide 16

Slide 16 text

© DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 16

Slide 17

Slide 17 text

© DMM.com TiDBストレージ TiDB TiKVクラスター 全 ノード データを分散し 配置します。 データ Region いう基本単位 管理し 、3 ノード 3面コピーします。 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 17

Slide 18

Slide 18 text

© DMM.com Leader/Follower Leader Follower 2種類 Regionがあります。 Leaderがデータ I/Oを処理し、Follower Leader バックアップ す。 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 18

Slide 19

Slide 19 text

© DMM.com Leaderがあるノード 対し I/Oする region1 I/Oする き TiKV-0、region2 I/Oする き TiKV-1 リクエスト。 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 19 write write write write

Slide 20

Slide 20 text

© DMM.com Writeがスケールする Leader 全ノード 分散し いる write リクエストが分散されます。 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 20 write write write write

Slide 21

Slide 21 text

© DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 21

Slide 22

Slide 22 text

© DMM.com ゼロダウンタイム DB ダウンタイムが発生する例 • DBインスタンス スケールアップ/スケールダウン • DBインスタンス 障害 • DB バージョンアップ 22

Slide 23

Slide 23 text

© DMM.com ダウンタイムが発生し い仕組み TiDBストレージ 仕組み よ ゼロダウンタイム 運用が可能 す。 23

Slide 24

Slide 24 text

© DMM.com ノード 障害が発生した場合 通常時 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 24 write write write write

Slide 25

Slide 25 text

© DMM.com ノード 障害が発生した場合 TiKV-1ノード 障害が発生 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 25 write write write

Slide 26

Slide 26 text

© DMM.com ノード 障害が発生した場合 region2 FollowerからLeaderを再選出 ダウンタイム ありませんが、 Leader 再選出 10秒くらいかかるため region2へ リクエスト クエリ遅延が発生します。 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 26

Slide 27

Slide 27 text

© DMM.com ノード 障害が発生した場合 region2へ データアクセスが再開 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 region Leader：IO対象 region Follower：バックアップ 27 write write write write

Slide 28

Slide 28 text

© DMM.com ゼロダウンタイム 運用が可能 28 スケールアウト ノード追加した瞬間からデータ移行が開始 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 29

Slide 29 text

© DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 29

Slide 30

Slide 30 text

© DMM.com MySQLプロトコル互換 TiDB MySQLプロトコル互換 、MySQL 利用し いたSQLクエリをそ まま利 用するこ が きます。 30

Slide 31

Slide 31 text

© DMM.com MySQL よう TiDBを利用する き 注意 TiDB 分散DB MySQL 同じ使い方をする 相性が悪いこ があります。 ex. AUTO_INCREMENTを利用したid 採番 31

Slide 32

Slide 32 text

© DMM.com 連番 id レコード 同じRegion 配置される可能性が高い。 Regionへ データ 配置 32 region1 region2 region3 region4 id name 1001 A 1002 B 1003 C 1004 D 1005 E 1006 F 1007 G

Slide 33

Slide 33 text

© DMM.com ホットスポット 発生 注意 特定 TiKVノード リクエストが集中する 分散DB 良さを引き出せ い。 33 TiKV-0 TiKV-1 TiKV-2 TiKV-3 region1 region1 region1 region3 region2 region2 region4 region3 region3 region5 region4 region5 region2 region4 region5 write write write write write write

Slide 34

Slide 34 text

© DMM.com id 採番方法 idをランダム 生成する • UUID • AUTO_RANDOM（= AUTO_INCREMENT + ランダム シャードビット） 34

Slide 35

Slide 35 text

© DMM.com 本セクション ま め NewSQL 何？ 定義上 従来 DBMS スケール き いモダン OLTPワークロード 対応するDB 全般を示します。 NewSQL 良い ころ ？ TiDBを例 出す 、Writeがスケールする & ゼロダウンタイム 運用が可能 す。 MySQLプロトコル互換 MySQL用 SQLクエリをそ まま使えます。 NewSQLを使う き 注意 ？ TiDBを例 出す 、MySQLプロトコル互換 いえ中身 分散DB す。 AUTO_INCREMENTを利用したid 採番 相性が悪いよう MySQL 同様 使い方 が き いこ もあります。 35

Slide 36

Slide 36 text

© DMM.com DMM Platform TiDB Cloud 採用 36

Slide 37

Slide 37 text

© DMM.com 本セクション ゴール ・TiDB Cloudを採用したプロダクト ？ ・TiDB Cloudへ 移行コスト 高い？ ・移行し み うだ た？ 簡潔 回答したい。 37

Slide 38

Slide 38 text

© DMM.com TiDB Cloudを採用したプロダクト DMM Platform 認可基盤 DB し TiDB Cloudを採用しました。 38

Slide 39

Slide 39 text

© DMM.com DMM Platform DMMプラットフォーム DMM 各サービス 共通し 使われる基盤 す。 会員 管理、ユーザー 認証/認可、各種決済周り、DMMポイントやtoreta+ い た電 子マネー 仕組みを提供し います。 39

Slide 40

Slide 40 text

© DMM.com マイクロサービス DMM Platform マイクロサービス API Gatewayパターンを採用し います。 40 API Gateway 認可 API 動画 会員 DMMプラットフォーム 電子書籍 ① ② ③ 決済 40

Slide 41

Slide 41 text

© DMM.com 認可API 認可API マイクロサービスへ リクエスト 認可を管理し います。 41 API Gateway 認可 API 動画 会員 DMMプラットフォーム 電子書籍 ① ② ③ 決済 41

Slide 42

Slide 42 text

© DMM.com 認可API 認可API 障害が発生 = DMM Platform 全マイクロサービス 障害が発生 絶対 落 せ いサービス 42 API Gateway 認可 API 動画 会員 DMMプラットフォーム 電子書籍 ① ② ③ 決済 42

Slide 43

Slide 43 text

© DMM.com 認可API フルリプレース • 認可APIがレガシーシステム化し おり開発効率が悪化 • DMM Platform 方針 • 技術戦略 し Goを採用 • オンプレを脱却しクラウドを活用する 43 リプレース前 リプレース先 アプリケーションコード PHP Go インフラ オンプレ GKE/EKS DB オンプレ MySQL ？

Slide 44

Slide 44 text

© DMM.com 認可API 移行先 DB 要件 • 認可API ワークロード 耐えられる • ダウンタイムが い • アプリケーションエンジニア も管理しやすいフルマネージドサービス DB • Write がスケールする • 強整合性 • データ リレーションを持たせるこ が きる（Joinが きる） • （可能 あれ 移行コストが減る ）MySQLプロトコル互換 → TiDB Cloudを採用 44

Slide 45

Slide 45 text

© DMM.com TiDB Cloud検証 https://speakerdeck.com/yuyu_hf/db-tech-showcase-2022-dmm-inspect-full-managed-newsql-tidb-cloud 45

Slide 46

Slide 46 text

© DMM.com TiDBクラスター 構成 46 クラウド AWS TiDBクラスター Region asia-northeast-1 ノードサイズ TiDB Server 4 instances 8 vCPU, 16 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB VPC Peering/AWS PrivateLink 無（インターネット経由 TLS接続） TiProxy 無 マルチテナント 有（認可API/認証API）

Slide 47

Slide 47 text

© DMM.com TiDBクラスター 構成 47 クラウド AWS TiDBクラスター Region asia-northeast-1 ノードサイズ TiDB Server 4 instances 8 vCPU, 16 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB VPC Peering/AWS PrivateLink 無（インターネット経由 TLS接続） TiProxy 無 マルチテナント 有（認可API/認証API）

Slide 48

Slide 48 text

© DMM.com TiDB Cloud マルチプラットフォーム可能 TiDB Cloud マルチプラットフォーム可能 AWS/GCPを選択 きます。 VPC PeeringやAWS PrivateLinkを設定するこ 内部通信を利用 きます。 48

Slide 49

Slide 49 text

© DMM.com AWS & インターネット経由 通信 理由 インターネット経由 通信 将来的 認可API GKE/EKS マルチプラットフォーム構成 するため、 GKE/EKS両方 アプリケーションからTiDB Cloudへリクエストを送ります。 TiDB Cloud プラットフォーム AWSを選択 肌感 すが、TiDB Cloud アップデートがTiDB Cloud on Google CloudよりTiDB Cloud AWS ほうが早い。 49

Slide 50

Slide 50 text

© DMM.com TiDBクラスター 構成 50 クラウド AWS TiDBクラスター Region asia-northeast-1 ノードサイズ TiDB Server 4 instances 8 vCPU, 16 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB VPC Peering/AWS PrivateLink 無（インターネット経由 TLS接続） TiProxy 無 マルチテナント 有（認可API/認証API）

Slide 51

Slide 51 text

© DMM.com TiProxy TiProxy クライアント-TiDB Server間 コネクションを管理するコンポーネント す。 TiProxyを有効化するこ TiDBクラスター 再起動時 コネクション 切断が発生する 可能性が低く ります。 51

Slide 52

Slide 52 text

© DMM.com TiProxy無 通常時 52 TiDB TiDB TiKV TiKV TiKV クライアント

Slide 53

Slide 53 text

© DMM.com TiProxy無 TiDB Serverを再起動する時 コネクションが切られます。 53 TiDB TiDB TiKV TiKV TiKV

Slide 54

Slide 54 text

© DMM.com TiProxy有 TiProxy クライアント TiDBクラスター間 コネクションを管理し います。 54 TiDB TiDB TiKV TiKV TiKV TiProxy

Slide 55

Slide 55 text

© DMM.com TiProxy有 TiDB Server 再起動時 別 TiDB Server リクエストを振り分けます。 55 TiDB TiDB TiKV TiKV TiKV TiProxy

Slide 56

Slide 56 text

© DMM.com TiProxy デプロイ方法 • TiProxy on Placement Driver（GA） • TiProxy on PingCAP社 EKSクラスター（Beta） → 選択肢 TiProxy on Placement Driver 一択 56

Slide 57

Slide 57 text

© DMM.com TiProxyを外した理由 TiDBクラスターを再起動する き TiProxyも再起動する TiProxyが再起動し しまう クライアント-TiProxy間 コネクション 切断が発生する ？ Placement Driver リソースを TiProxy 分ける Placement Driver 4 vCPU → Placement Driver 2 vCPU + TiProxy 2 vCPU TiProxyへ 負荷 よるPlacement Driverへ 影響が未知数。 → TiProxy on PingCAP社 EKSがGAされるま TiProxy 導入を見送りました。 57

Slide 58

Slide 58 text

© DMM.com TiDBクラスター 構成 58 クラウド AWS TiDBクラスター Region asia-northeast-1 ノードサイズ TiDB Server 4 instances 8 vCPU, 16 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB VPC Peering/AWS PrivateLink 無（インターネット経由 TLS接続） TiProxy 無 マルチテナント 有（認可API/認証API）

Slide 59

Slide 59 text

© DMM.com マルチテナント 採用 インフラコスト 削減 TiDBクラスター 可用性を担保する構成 VMインスタンスが最低5台必要。 各環境、プロダクトご TiDBクラスターを作成する コストがかかる。 TiDB マルチテナント 利用実績 PingCAP社 TiDB Cloud Serverless いうクラウドサービス マルチテナント 運用さ れ いる。 59

Slide 60

Slide 60 text

© DMM.com TiDBクラスター 構成 60 クラウド AWS TiDBクラスター Region asia-northeast-1 ノードサイズ TiDB Server 4 instances 8 vCPU, 16 GiB TiKV Server 3 instances 8 vCPU, 32 GiB ストレージ 500 GB VPC Peering/AWS PrivateLink 無（インターネット経由 TLS接続） TiProxy 無 マルチテナント 有（認可API/認証API）

Slide 61

Slide 61 text

© DMM.com アプリケーション 変更点 アプリケーションコード 変更 無し SQLクエリ 変更 無し テーブルスキーマ 変更 AUTO_INCREMENT → AUTO_RANDOM 移行コストほぼ無し！ 61

Slide 62

Slide 62 text

© DMM.com 変更点が少 か た理由 認可API アーキテクチャ 分散 DB 向い いた。 • primary keyを指定し レコードを引くSQLクエリが9割 • 分散DB 不向き JOINやORDER BY 使用し い い 一般的 RDB 使い方をし いる アプリケーションコードを変更し けれ ら い可 能性が高いかも... 62

Slide 63

Slide 63 text

© DMM.com ゼロダウンタイム DB移行 認可API ダウンタイムが許され い ゼロダウンタイム DB移行を実施。 DB移行 手法 し Strangler Fig Patternを採用しました。 オンプレ MySQL TiDB Cloud レコード 同期 sync-diff-inspector いうCLI ツールを利用しました。 63

Slide 64

Slide 64 text

© DMM.com Strangler Fig Pattern DB 向先をオンプレ MySQLからTiDB Cloudへ徐々 切り替えました。 64 App MySQL TiDB App MySQL TiDB App MySQL TiDB App MySQL TiDB Phase 1 Phase 2 Phase 3 Phase 4 read/write read/write write read/write read/write write

Slide 65

Slide 65 text

© DMM.com sync-diff-inspector MySQLプロトコル互換 DB間 データ差分を検出するCLIツール す。 • オフライン環境 レコード差分を検出 きる • 差分を検知した場合、レコード差分を修正するSQLクエリを生成する sync-diff-inspector MySQL-TiDB間 レコード差分をオンライン チェック。 65

Slide 66

Slide 66 text

© DMM.com Strangler Fig Pattern + sync-diff-inspector 66 App MySQL TiDB App MySQL TiDB App MySQL TiDB App MySQL TiDB Step 1 Step 2 Step 3 Step 4 read/write read/write write read/write read/write write sync-diff-inspector データ 同期

Slide 67

Slide 67 text

© DMM.com ゼロダウンタイム DB移行完了 無事ゼロダウンタイム DB移行完了🎉 移行時 エンドポイント p99レイテンシが最大70ms悪化。 p99レイテンシ 悪化を100msま 許容する方針だ た 許容範囲内 67

Slide 68

Slide 68 text

© DMM.com TiDB Cloudへ 移行後 所感 パフォーマンス 移行前 比べ ほぼ変化無し。 運用コスト ダウンタイム無し & 検証以外 運用作業も無し。 • TiDB バージョンアップ … 1回 • TiDBクラスター スケールアップ/スケールダウン … 5回以上 68

Slide 69

Slide 69 text

© DMM.com 当初 想定 違 いた ころ DMM TiDBクラスター Datadog連携 不具合 TiDB Cloud メトリクスをDatadog連携するこ が きます。 TiDB Cloud ダッシュボード 値 Datadog 送られ くる値 乖離がある。 Datadog 送られる値 ほうが少し大きい 監視 モニター 誤発火が発生。 TiDB Cloud以外 メトリクス Datadog 集約し いる 、Datadog メトリクスやモ ニターを一元管理 き い。 69

Slide 70

Slide 70 text

© DMM.com 本セクション ま め TiDB Cloudを採用したプロダクト ？ DMM Platform マイクロサービス群 認可基盤。ダウンタイムが許され い。 TiDB Cloudへ 移行コスト 高い？ 認可API MySQLを利用し いたが元々分散DB向き 設計がされ いた 、既存 仕組み ほ ん 手を入れるこ くDB移行 きた。 TiDBエコシステム ツールが便利 DB移行 工数を大幅 削減 きた。 移行し み うだ た？ パフォーマンス 悪化具合もほぼ無し。DB 運用コストが少 い 嬉しい。 Datadog 監視を一元管理 き い らい... 70

Slide 71

Slide 71 text

© DMM.com 運用事例 紹介 71

Slide 72

Slide 72 text

© DMM.com 毎日0時 認可API タイムアウト 件数が増加 認可API 利用し いる SQLクエリ レイテンシが上昇し いた。 • 毎日0時 TiDBクラスター パフォーマンスが微妙 悪化 • TiDB Server TiKV Server リソース まだ余裕がある 72 TiKV Server CPU使用率（max 800%）

Slide 73

Slide 73 text

© DMM.com パフォーマンス悪化 原因 毎日0時 バッチ処理 利用し いるSQLクエリ 影響？ 73

Slide 74

Slide 74 text

© DMM.com パフォーマンス悪化 原因 パフォーマンス悪化 原因 • バッチ処理 対象 テーブル レコード件数 約6,000万件あ たが、テーブル インデックスが貼られ い か た • SQLクエリを実行した き レイテンシが8秒程度かか いた インデックスを貼 か た理由 • オンプレ MySQL バッチ処理専用 Read Replicaを用意し いた • DB移行時 TiDBクラスター全体 パフォーマンス悪化 見られ か た テーブル構 見直し し か た 74

Slide 75

Slide 75 text

© DMM.com 移行後し らく経 からパフォーマンス悪化した原因 おそらくTiDBクラスター全体 cop_task数 増加が原因。 75

Slide 76

Slide 76 text

© DMM.com cop_task TiKV Coprocessor 処理されるタスクをcop_task 呼びます。 TiDB Server 処理 一部をTiKV Server pushし、TiKV Coprocessor 代わり 処理 します。 76

Slide 77

Slide 77 text

© DMM.com TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 77

Slide 78

Slide 78 text

© DMM.com TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 78

Slide 79

Slide 79 text

© DMM.com TiKV Server without TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 79

Slide 80

Slide 80 text

© DMM.com TiKV Server with TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 80

Slide 81

Slide 81 text

© DMM.com cop_task数が多い パフォーマンス悪化 TiDB Server/TiKV Server CPU使用率やメモリ使用率が上昇し い く も、 cop_task 数が多い TiDBクラスター パフォーマンスが悪化する。 過去 DMM TiDBクラスター 傾向 • cop_task数 2,000未満 … パフォーマンス悪化無し • cop_task数 6,000以上 … パフォーマンス悪化有り 81

Slide 82

Slide 82 text

© DMM.com cop_task数を減らし パフォーマンスを改善する バッチ処理 利用され いるSQLクエリ cop_task数 82

Slide 83

Slide 83 text

© DMM.com オンラインDDLを流し インデックスを作成する オンラインDDL カバリングインデックスを作成するこ しました。 カバリングインデックスを作成するデメリット ストレージ容量を逼迫する可能性があります。 → クラウドサービス 手軽 インスタンス ストレージ容量を増やせる → TiDB あれ ダウンタイム無し スケールアップ きる 83

Slide 84

Slide 84 text

© DMM.com パフォーマンス悪化を最小限 するため 方針 • オンラインDDL実行中 TiDBクラスター リソースを増やす • オンラインDDL 使用するリソースを制限する • オンラインDDL 処理時間を短縮するため 設定値を有効化する 84

Slide 85

Slide 85 text

© DMM.com オンラインDDLを流す き 各コンポーネント 負荷 TiDB Server オンラインDDLを処理する1ノード み負荷がかかる。 TiKV Server オンラインDDL 対象 データが配置され いるLeader Regionが存在 するノード全 影響があります。 85 TiDB TiDB TiKV TiKV TiKV TiDB TiDB

Slide 86

Slide 86 text

© DMM.com TiDB Server 設定変更 TiDB Server スケールアップ オンラインDDLを実行する1ノード み負荷が上がる スケールアップ一択。 8 vCPU 16 GB → 16 vCPU 32 GBへ変更する。 tidb_ddl_reorg_worker_cnt=4をセット CPUリソース 25%をオンラインDDLを実行するプロセス 割り当 る。 86

Slide 87

Slide 87 text

© DMM.com TiKV Server スケールアップ or スケールアウト スケールアップ後、スケールアップ 影響が無く るま 時間 =6h AWS EBS cool down period(= 6h) 影響を受ける。 スケールアウト後、スケールアウト 影響が無く るま 時間 =読め い スケールアウト後 Region リバランシングが実行される。 リバランシングがい 終わるか判断し らい。 → スケールアップを選択 87

Slide 88

Slide 88 text

© DMM.com TiKV Server 設定変更 TiKV Server スケールアップ 8 vCPU 32 GB → 16 vCPU 64GB import.num-threads=8をセット CPUリソース 50%をオンラインDDLを実行するプロセス 割り当 る。 tidb_ddl_enable_fast_reorg=ONをセット インデックス 作成を逐次処理 くバッチ処理 作成する。 88

Slide 89

Slide 89 text

© DMM.com オンラインDDLを流す き TiDBクラスター 設定値 変更 TiDB Server • TiDB Server スケールアップ（8 vCPU 16 GB → 16 vCPU 32 GB） • tidb_ddl_reorg_worker_cnt=4 TiKV Server • TiKV Server スケールアップ（8 vCPU 32 GB → 16 vCPU 64 GB） • tidb_ddl_enable_fast_reorg=ON • import.num-threads=8 89

Slide 90

Slide 90 text

© DMM.com オンラインDDL 結果 実行時間3分30秒。SQLクエリ p99 レイテンシが20~30ms悪化。 エンドポイントご p99 レイテンシ 最大200ms悪化。 結構性能良い！ 90 オンライン DDL実行前 オンライン DDL実行中 TiDB Server CPU使用率 8.18 % 32.18 % TiDB Server メモリ使用率 13.81% 44.43% TiKV Server CPU使用率 13.25 % 28.68 % TiKV Server メモリ使用率 - -

Slide 91

Slide 91 text

© DMM.com SQLクエリ パフォーマンス改善 バッチ処理 利用し いるSQLクエリ 実行時間 8 sec → 0.26 sec 改善。 cop_task数 151 → 6 削減。 91 before after TiDBクラスター全体 パフォーマンス悪化も改善！

Slide 92

Slide 92 text

© DMM.com パフォーマンス影響をさら 軽減させるこ も可能 TiDB オンラインDDL レコードロックせず DDLよりDMLを優先する。 ※ TiDB メタデータロック いう仕組み よる オンライン DDL 割り当 るリソースを制限するこ 、 TiDBクラスターへ パフォーマンス影響を小さくするこ が可能！ 調整 きそう 設定値 • tidb_ddl_reorg_worker_cnt • tidb_ddl_reorg_batch_size • etc… 92

Slide 93

Slide 93 text

© DMM.com TiDB Cloud ミッションクリティカル サービス 使える か？ 93

Slide 94

Slide 94 text

© DMM.com 観点 • パフォーマンス • メンテナンス • 監視・障害対応 • 学習コスト 94

Slide 95

Slide 95 text

© DMM.com パフォーマンス 認可API（＋認証API） ワークロードを捌け いる TiDBクラスター全体 最大5,000 QPS。 DB移行前 比較し 認可API p99レイテンシ 変化無し。 現在 認可API ワークロード 耐えられ いる。 95

Slide 96

Slide 96 text

© DMM.com メンテナンス ダウンタイム無 & DB 運用工数 削減可 2024年5月 ~ 現在ま 運用実績 • TiDB バージョンアップ … 1回 • TiDBクラスター スケールアップ/ダウン … 5回以上 バージョンアップ前 DB検証以外、DB 運用作業 ありません。 開発者 アプリケーション開発 集中するこ が き います。 96

Slide 97

Slide 97 text

© DMM.com 監視・障害対応 各種メトリクスを確認 きるダッシュボードがある 他社 パブリッククラウド 同程度 ダッシュボードがある。 Datadog 監視を一元管理 き い TiDB Cloud 仕様 Datadog連携が可能 す。 Datadog連携した ころDatadog 確認 きるメトリクスが実際 値より大きくモニター 誤発火が発生。 現在 Datadog メトリクスを監視し い い。 97

Slide 98

Slide 98 text

© DMM.com 監視・障害対応 ユーザー側 管理 き いプロセスがある テーブル TTLを設定した際、エッジケース 問題を踏ん 微妙 障害発生。 障害 直接原因 TiDBクラスター内部 発行されるTTL SQLクエリが原因。 障害 原因 るプロセスをkillしよう したが、TiDBクラスター内部 処理 発行された プロセス い ユーザー側からプロセスが見え い。 やむ くTiDBクラスター スケールアップ（= 再起動） プロセスをkillした。 ユーザー側 ノード スペックを維持した再起動が き い ノード 上限 スペック 達したらスケールアップ き い スケールダウン 再起 動するしか い。 ※ PingCAP社側から ノード スペックを維持した再起動が可能 98

Slide 99

Slide 99 text

© DMM.com PingCAP社 Enterprise契約する ら PingCAP社 サポート も手厚い す。 99

Slide 100

Slide 100 text

© DMM.com 学習コスト 学習コスト それ り かかるが恩恵も大きい • ワークロード 応じた細かい設定が可能 • アプリケーションへ 影響を最小限 する運用が可能 逆 、設定し い うまく運用 き いかもしれ い。 TiDB 進化が早い DB TiDB 進化が いDB 様々 便利 機能が頻度高くリリースされる。 今後TiDB デファクトスタンダード る機能がGA後 大きく方針転換するこ がある 注意が必要。 100

Slide 101

Slide 101 text

© DMM.com 使えます！ TiDB Cloud ミッションクリティカル サービス 使える か？ 101 パフォーマンス ・現行 認可API ワークロード 耐えられ いる ・今後ワークロードが増え い も耐え くれるこ 期 待！ メンテナンス ・半年運用し ダウンタイムが一度も無い ・運用コストを大幅 減らし 、開発者が開発 集中 きる 環境を実現 きる 監視・障害対応 ・Datadog 監視を一元管理 き い ・ユーザーから操作 き い項目があり、障害発生時 困 るかもしれ い 学習コスト ・学習コスト かかるが恩恵も大きい ・今後TiDB デファクトスタンダード る機能が GA後 大きく方針転換するこ がある 注意が必要

Slide 102

Slide 102 text

© DMM.com 最後 Q. NewSQL ワードを最近聞くけ 、よく知ら いし、採用す るか迷う ... DMM 認可API 問題 く利用 き います！ 少 く も半年間ダウンタイム 発生し いません！ DB 運用工数を大幅 削減し 本質的 アプリケーション開発 集中 き います！ 採用するか迷 たらDB検証し みましょう！ 102

Slide 103

Slide 103 text

© DMM.com おわり！ 103