クラウドネイティブなNewSQLで実現するミッションクリティカルなアプリケーションの運用

CloudNative Days Winter 2024の登壇資料です。
https://event.cloudnativedays.jp/cndw2024/talks/2387

Transcript

1. © DMM.com クラウドネイティブ NewSQL 実現する ミッションクリティカル アプリケーション 運用 CloudNative Days Winter 2024 合同会社DMM.com プラットフォーム開発本部 い （@yuyu_hf） 1
2. © DMM.com 自己紹介 い （@yuyu_hf） ➢ 合同会社DMM.com（2019/04 - 現在） ◦ プラットフォーム開発本部 認可チーム ➢ 認可APIをフルリプレースし います ◦ PHP → Go ◦ MySQL → TiDB Cloud ◦ オンプレ → GKE/EKS 2 2
3. © DMM.com 本セッション い 2024年05月 認可API 利用し いるDBをオンプレ MySQLからクラウドネイティブ NewSQL あるTiDB Cloud 移行しました。 TiDB Cloudを運用し し らく経 使 みた所感 い 話します。 3
4. © DMM.com 本セッション 対象者 NewSQL ワードを最近聞くけ 、 よく知ら いし、採用するか迷う ... 思 いる人 ぜひ聞い ほしい。 NewSQLを採用する き 参考 し ください。 4
5. © DMM.com 今日話すこ 1. NewSQL 概要 2. DMM Platform TiDB Cloud 採用 3. 運用事例 紹介 4. TiDB Cloud ミッションクリティカル サービス 使える か？ 5
6. © DMM.com NewSQL 概要 6
7. © DMM.com 本セクション ゴール ・NewSQL 何？ ・NewSQL 良い ころ ？ ・NewSQLを使う き 注意 ？ 簡潔 回答したい。 7
8. © 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
9. © 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?
10. © DMM.com NewSQL 意味が広い NewSQL 定義 意味が広い 様々 DBがNewSQL 定義 当 まります。 NewSQL 呼 れ い もDBご 特徴 異 ります。 10
11. © DMM.com Spanner 代表的 NewSQL 1 Google社が開発したSpannerがあります。 Google Cloud Cloud Spanner いうサービス し 提供され います。 11
12. © DMM.com Spanner インスピレーションを受け 開発されたDB • TiDB • YugabyteDB • CockroachDB 12
13. © DMM.com TiDB TiDB PingCAP社 開発され いる NewSQL DB す。 • MySQLプロトコル互換 • マルチプラットフォーム可能 • OLTP OLAPを一 DB （HTAP） 13
14. © 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 ) 

15. © DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 15
16. © DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 16
17. © 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
18. © 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
19. © 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
20. © 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
21. © DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 21
22. © DMM.com ゼロダウンタイム DB ダウンタイムが発生する例 • DBインスタンス スケールアップ/スケールダウン • DBインスタンス 障害 • DB バージョンアップ 22
23. © DMM.com ダウンタイムが発生し い仕組み TiDBストレージ 仕組み よ ゼロダウンタイム 運用が可能 す。 23
24. © 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
25. © 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
26. © 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
27. © 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
28. © 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も対応
29. © DMM.com TiDB 特徴 ・Writeがスケールする ・ゼロダウンタイム 運用が可能 ・MySQLプロトコル互換 29
30. © DMM.com MySQLプロトコル互換 TiDB MySQLプロトコル互換 、MySQL 利用し いたSQLクエリをそ まま利 用するこ が きます。 30
31. © DMM.com MySQL よう TiDBを利用する き 注意 TiDB 分散DB MySQL 同じ使い方をする 相性が悪いこ があります。 ex. AUTO_INCREMENTを利用したid 採番 31
32. © 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
33. © 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
34. © DMM.com id 採番方法 idをランダム 生成する • UUID • AUTO_RANDOM（= AUTO_INCREMENT + ランダム シャードビット） 34
35. © DMM.com 本セクション ま め NewSQL 何？ 定義上 従来 DBMS スケール き いモダン OLTPワークロード 対応するDB 全般を示します。 NewSQL 良い ころ ？ TiDBを例 出す 、Writeがスケールする & ゼロダウンタイム 運用が可能 す。 MySQLプロトコル互換 MySQL用 SQLクエリをそ まま使えます。 NewSQLを使う き 注意 ？ TiDBを例 出す 、MySQLプロトコル互換 いえ中身 分散DB す。 AUTO_INCREMENTを利用したid 採番 相性が悪いよう MySQL 同様 使い方 が き いこ もあります。 35
36. © DMM.com DMM Platform TiDB Cloud 採用 36
37. © DMM.com 本セクション ゴール ・TiDB Cloudを採用したプロダクト ？ ・TiDB Cloudへ 移行コスト 高い？ ・移行し み うだ た？ 簡潔 回答したい。 37
38. © DMM.com TiDB Cloudを採用したプロダクト DMM Platform 認可基盤 DB し TiDB Cloudを採用しました。 38
39. © DMM.com DMM Platform DMMプラットフォーム DMM 各サービス 共通し 使われる基盤 す。 会員 管理、ユーザー 認証/認可、各種決済周り、DMMポイントやtoreta+ い た電 子マネー 仕組みを提供し います。 39
40. © DMM.com マイクロサービス DMM Platform マイクロサービス API Gatewayパターンを採用し います。 40 API Gateway 認可 API 動画 会員 DMMプラットフォーム 電子書籍 ① ② ③ 決済 40
41. © DMM.com 認可API 認可API マイクロサービスへ リクエスト 認可を管理し います。 41 API Gateway 認可 API 動画 会員 DMMプラットフォーム 電子書籍 ① ② ③ 決済 41
42. © DMM.com 認可API 認可API 障害が発生 = DMM Platform 全マイクロサービス 障害が発生 絶対 落 せ いサービス 42 API Gateway 認可 API 動画 会員 DMMプラットフォーム 電子書籍 ① ② ③ 決済 42
43. © DMM.com 認可API フルリプレース • 認可APIがレガシーシステム化し おり開発効率が悪化 • DMM Platform 方針 • 技術戦略 し Goを採用 • オンプレを脱却しクラウドを活用する 43 リプレース前 リプレース先 アプリケーションコード PHP Go インフラ オンプレ GKE/EKS DB オンプレ MySQL ？
44. © DMM.com 認可API 移行先 DB 要件 • 認可API ワークロード 耐えられる • ダウンタイムが い • アプリケーションエンジニア も管理しやすいフルマネージドサービス DB • Write がスケールする • 強整合性 • データ リレーションを持たせるこ が きる（Joinが きる） • （可能 あれ 移行コストが減る ）MySQLプロトコル互換 → TiDB Cloudを採用 44
45. © DMM.com TiDB Cloud検証 https://speakerdeck.com/yuyu_hf/db-tech-showcase-2022-dmm-inspect-full-managed-newsql-tidb-cloud 45
46. © 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）
47. © 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）
48. © DMM.com TiDB Cloud マルチプラットフォーム可能 TiDB Cloud マルチプラットフォーム可能 AWS/GCPを選択 きます。 VPC PeeringやAWS PrivateLinkを設定するこ 内部通信を利用 きます。 48
49. © DMM.com AWS & インターネット経由 通信 理由 インターネット経由 通信 将来的 認可API GKE/EKS マルチプラットフォーム構成 するため、 GKE/EKS両方 アプリケーションからTiDB Cloudへリクエストを送ります。 TiDB Cloud プラットフォーム AWSを選択 肌感 すが、TiDB Cloud アップデートがTiDB Cloud on Google CloudよりTiDB Cloud AWS ほうが早い。 49
50. © 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）
51. © DMM.com TiProxy TiProxy クライアント-TiDB Server間 コネクションを管理するコンポーネント す。 TiProxyを有効化するこ TiDBクラスター 再起動時 コネクション 切断が発生する 可能性が低く ります。 51
52. © DMM.com TiProxy無 通常時 52 TiDB TiDB TiKV TiKV TiKV クライアント
53. © DMM.com TiProxy無 TiDB Serverを再起動する時 コネクションが切られます。 53 TiDB TiDB TiKV TiKV TiKV
54. © DMM.com TiProxy有 TiProxy クライアント TiDBクラスター間 コネクションを管理し います。 54 TiDB TiDB TiKV TiKV TiKV TiProxy
55. © DMM.com TiProxy有 TiDB Server 再起動時 別 TiDB Server リクエストを振り分けます。 55 TiDB TiDB TiKV TiKV TiKV TiProxy
56. © DMM.com TiProxy デプロイ方法 • TiProxy on Placement Driver（GA） • TiProxy on PingCAP社 EKSクラスター（Beta） → 選択肢 TiProxy on Placement Driver 一択 56
57. © 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
58. © 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）
59. © DMM.com マルチテナント 採用 インフラコスト 削減 TiDBクラスター 可用性を担保する構成 VMインスタンスが最低5台必要。 各環境、プロダクトご TiDBクラスターを作成する コストがかかる。 TiDB マルチテナント 利用実績 PingCAP社 TiDB Cloud Serverless いうクラウドサービス マルチテナント 運用さ れ いる。 59
60. © 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）
61. © DMM.com アプリケーション 変更点 アプリケーションコード 変更 無し SQLクエリ 変更 無し テーブルスキーマ 変更 AUTO_INCREMENT → AUTO_RANDOM 移行コストほぼ無し！ 61
62. © DMM.com 変更点が少 か た理由 認可API アーキテクチャ 分散 DB 向い いた。 • primary keyを指定し レコードを引くSQLクエリが9割 • 分散DB 不向き JOINやORDER BY 使用し い い 一般的 RDB 使い方をし いる アプリケーションコードを変更し けれ ら い可 能性が高いかも... 62
63. © DMM.com ゼロダウンタイム DB移行 認可API ダウンタイムが許され い ゼロダウンタイム DB移行を実施。 DB移行 手法 し Strangler Fig Patternを採用しました。 オンプレ MySQL TiDB Cloud レコード 同期 sync-diff-inspector いうCLI ツールを利用しました。 63
64. © 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
65. © DMM.com sync-diff-inspector MySQLプロトコル互換 DB間 データ差分を検出するCLIツール す。 • オフライン環境 レコード差分を検出 きる • 差分を検知した場合、レコード差分を修正するSQLクエリを生成する sync-diff-inspector MySQL-TiDB間 レコード差分をオンライン チェック。 65
66. © 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 データ 同期
67. © DMM.com ゼロダウンタイム DB移行完了 無事ゼロダウンタイム DB移行完了🎉 移行時 エンドポイント p99レイテンシが最大70ms悪化。 p99レイテンシ 悪化を100msま 許容する方針だ た 許容範囲内 67
68. © DMM.com TiDB Cloudへ 移行後 所感 パフォーマンス 移行前 比べ ほぼ変化無し。 運用コスト ダウンタイム無し & 検証以外 運用作業も無し。 • TiDB バージョンアップ … 1回 • TiDBクラスター スケールアップ/スケールダウン … 5回以上 68
69. © DMM.com 当初 想定 違 いた ころ DMM TiDBクラスター Datadog連携 不具合 TiDB Cloud メトリクスをDatadog連携するこ が きます。 TiDB Cloud ダッシュボード 値 Datadog 送られ くる値 乖離がある。 Datadog 送られる値 ほうが少し大きい 監視 モニター 誤発火が発生。 TiDB Cloud以外 メトリクス Datadog 集約し いる 、Datadog メトリクスやモ ニターを一元管理 き い。 69
70. © DMM.com 本セクション ま め TiDB Cloudを採用したプロダクト ？ DMM Platform マイクロサービス群 認可基盤。ダウンタイムが許され い。 TiDB Cloudへ 移行コスト 高い？ 認可API MySQLを利用し いたが元々分散DB向き 設計がされ いた 、既存 仕組み ほ ん 手を入れるこ くDB移行 きた。 TiDBエコシステム ツールが便利 DB移行 工数を大幅 削減 きた。 移行し み うだ た？ パフォーマンス 悪化具合もほぼ無し。DB 運用コストが少 い 嬉しい。 Datadog 監視を一元管理 き い らい... 70
71. © DMM.com 運用事例 紹介 71
72. © DMM.com 毎日0時 認可API タイムアウト 件数が増加 認可API 利用し いる SQLクエリ レイテンシが上昇し いた。 • 毎日0時 TiDBクラスター パフォーマンスが微妙 悪化 • TiDB Server TiKV Server リソース まだ余裕がある 72 TiKV Server CPU使用率（max 800%）
73. © DMM.com パフォーマンス悪化 原因 毎日0時 バッチ処理 利用し いるSQLクエリ 影響？ 73
74. © DMM.com パフォーマンス悪化 原因 パフォーマンス悪化 原因 • バッチ処理 対象 テーブル レコード件数 約6,000万件あ たが、テーブル インデックスが貼られ い か た • SQLクエリを実行した き レイテンシが8秒程度かか いた インデックスを貼 か た理由 • オンプレ MySQL バッチ処理専用 Read Replicaを用意し いた • DB移行時 TiDBクラスター全体 パフォーマンス悪化 見られ か た テーブル構 見直し し か た 74
75. © DMM.com 移行後し らく経 からパフォーマンス悪化した原因 おそらくTiDBクラスター全体 cop_task数 増加が原因。 75
76. © DMM.com cop_task TiKV Coprocessor 処理されるタスクをcop_task 呼びます。 TiDB Server 処理 一部をTiKV Server pushし、TiKV Coprocessor 代わり 処理 します。 76
77. © DMM.com TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 77
78. © DMM.com TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 78
79. © DMM.com TiKV Server without TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 79
80. © DMM.com TiKV Server with TiKV Coprocessor 引用元: https://tikv.github.io/tikv-dev-guide/understanding-tikv/coprocessor/intro.html 80
81. © DMM.com cop_task数が多い パフォーマンス悪化 TiDB Server/TiKV Server CPU使用率やメモリ使用率が上昇し い く も、 cop_task 数が多い TiDBクラスター パフォーマンスが悪化する。 過去 DMM TiDBクラスター 傾向 • cop_task数 2,000未満 … パフォーマンス悪化無し • cop_task数 6,000以上 … パフォーマンス悪化有り 81
82. © DMM.com cop_task数を減らし パフォーマンスを改善する バッチ処理 利用され いるSQLクエリ cop_task数 82
83. © DMM.com オンラインDDLを流し インデックスを作成する オンラインDDL カバリングインデックスを作成するこ しました。 カバリングインデックスを作成するデメリット ストレージ容量を逼迫する可能性があります。 → クラウドサービス 手軽 インスタンス ストレージ容量を増やせる → TiDB あれ ダウンタイム無し スケールアップ きる 83
84. © DMM.com パフォーマンス悪化を最小限 するため 方針 • オンラインDDL実行中 TiDBクラスター リソースを増やす • オンラインDDL 使用するリソースを制限する • オンラインDDL 処理時間を短縮するため 設定値を有効化する 84
85. © DMM.com オンラインDDLを流す き 各コンポーネント 負荷 TiDB Server オンラインDDLを処理する1ノード み負荷がかかる。 TiKV Server オンラインDDL 対象 データが配置され いるLeader Regionが存在 するノード全 影響があります。 85 TiDB TiDB TiKV TiKV TiKV TiDB TiDB
86. © 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
87. © DMM.com TiKV Server スケールアップ or スケールアウト スケールアップ後、スケールアップ 影響が無く るま 時間 =6h AWS EBS cool down period(= 6h) 影響を受ける。 スケールアウト後、スケールアウト 影響が無く るま 時間 =読め い スケールアウト後 Region リバランシングが実行される。 リバランシングがい 終わるか判断し らい。 → スケールアップを選択 87
88. © 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
89. © 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
90. © 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 メモリ使用率 - -
91. © DMM.com SQLクエリ パフォーマンス改善 バッチ処理 利用し いるSQLクエリ 実行時間 8 sec → 0.26 sec 改善。 cop_task数 151 → 6 削減。 91 before after TiDBクラスター全体 パフォーマンス悪化も改善！
92. © DMM.com パフォーマンス影響をさら 軽減させるこ も可能 TiDB オンラインDDL レコードロックせず DDLよりDMLを優先する。 ※ TiDB メタデータロック いう仕組み よる オンライン DDL 割り当 るリソースを制限するこ 、 TiDBクラスターへ パフォーマンス影響を小さくするこ が可能！ 調整 きそう 設定値 • tidb_ddl_reorg_worker_cnt • tidb_ddl_reorg_batch_size • etc… 92
93. © DMM.com TiDB Cloud ミッションクリティカル サービス 使える か？ 93
94. © DMM.com 観点 • パフォーマンス • メンテナンス • 監視・障害対応 • 学習コスト 94
95. © DMM.com パフォーマンス 認可API（＋認証API） ワークロードを捌け いる TiDBクラスター全体 最大5,000 QPS。 DB移行前 比較し 認可API p99レイテンシ 変化無し。 現在 認可API ワークロード 耐えられ いる。 95
96. © DMM.com メンテナンス ダウンタイム無 & DB 運用工数 削減可 2024年5月 ~ 現在ま 運用実績 • TiDB バージョンアップ … 1回 • TiDBクラスター スケールアップ/ダウン … 5回以上 バージョンアップ前 DB検証以外、DB 運用作業 ありません。 開発者 アプリケーション開発 集中するこ が き います。 96
97. © DMM.com 監視・障害対応 各種メトリクスを確認 きるダッシュボードがある 他社 パブリッククラウド 同程度 ダッシュボードがある。 Datadog 監視を一元管理 き い TiDB Cloud 仕様 Datadog連携が可能 す。 Datadog連携した ころDatadog 確認 きるメトリクスが実際 値より大きくモニター 誤発火が発生。 現在 Datadog メトリクスを監視し い い。 97
98. © DMM.com 監視・障害対応 ユーザー側 管理 き いプロセスがある テーブル TTLを設定した際、エッジケース 問題を踏ん 微妙 障害発生。 障害 直接原因 TiDBクラスター内部 発行されるTTL SQLクエリが原因。 障害 原因 るプロセスをkillしよう したが、TiDBクラスター内部 処理 発行された プロセス い ユーザー側からプロセスが見え い。 やむ くTiDBクラスター スケールアップ（= 再起動） プロセスをkillした。 ユーザー側 ノード スペックを維持した再起動が き い ノード 上限 スペック 達したらスケールアップ き い スケールダウン 再起 動するしか い。 ※ PingCAP社側から ノード スペックを維持した再起動が可能 98
99. © DMM.com PingCAP社 Enterprise契約する ら PingCAP社 サポート も手厚い す。 99
100. © DMM.com 学習コスト 学習コスト それ り かかるが恩恵も大きい • ワークロード 応じた細かい設定が可能 • アプリケーションへ 影響を最小限 する運用が可能 逆 、設定し い うまく運用 き いかもしれ い。 TiDB 進化が早い DB TiDB 進化が いDB 様々 便利 機能が頻度高くリリースされる。 今後TiDB デファクトスタンダード る機能がGA後 大きく方針転換するこ がある 注意が必要。 100
101. © DMM.com 使えます！ TiDB Cloud ミッションクリティカル サービス 使える か？ 101 パフォーマンス ・現行 認可API ワークロード 耐えられ いる ・今後ワークロードが増え い も耐え くれるこ 期 待！ メンテナンス ・半年運用し ダウンタイムが一度も無い ・運用コストを大幅 減らし 、開発者が開発 集中 きる 環境を実現 きる 監視・障害対応 ・Datadog 監視を一元管理 き い ・ユーザーから操作 き い項目があり、障害発生時 困 るかもしれ い 学習コスト ・学習コスト かかるが恩恵も大きい ・今後TiDB デファクトスタンダード る機能が GA後 大きく方針転換するこ がある 注意が必要
102. © DMM.com 最後 Q. NewSQL ワードを最近聞くけ 、よく知ら いし、採用す るか迷う ... DMM 認可API 問題 く利用 き います！ 少 く も半年間ダウンタイム 発生し いません！ DB 運用工数を大幅 削減し 本質的 アプリケーション開発 集中 き います！ 採用するか迷 たらDB検証し みましょう！ 102
103. © DMM.com おわり！ 103