DMMプラットフォームにおけるTiDBの導入から運用まで

TiDB User Day 2024の登壇資料です。

1. DMMプラットフォームにおける TiDBの導入から運用まで @pospome
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMMプラットフォーム Twitter:@pospome
3. 目次 1. New SQLを採用した背景 2. Google Cloud Spanner vs TiDB/TiDB Cloud 3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
4. 目次 1. New SQLを採用した背景 2. Google Cloud Spanner vs TiDB/TiDB Cloud 3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
5. DMMプラットフォームについて 扱う領域：DMM会員、決済、DMMポイント、不正対策など エンジニア数：120名以上 開発チーム数：16チーム マイクロサービス数：約40サービス ピーク時のリクエスト：19,000RPS
6. レガシーシステムのリプレイスプロジェクト インフラのクラウド化 & Goへのrewriteする必要がある。 • 認証チーム オンプレ, MySQL, Java, Cassandra, Couchbase • 認可チーム オンプレ, MySQL, PHP, Redis
7. クラウドでもMySQLを使うのか? MySQLを利用することに対する懸念 1. マスターノードが単一障害点 a. 認証認可が止まるとDMMが止まる。 2. バージョンアップ時のダウンタイム a. DMMはメンテを入れるのが面倒。 3. Writeが水平スケールしない a. 各種サービスの都合でリクエストが増える。
8. NoSQLの検討 現実的に厳しい。 • Writeが水平にスケールし、 バージョンアップ時のダウンタイムもない。 • MySQLのデータ構造をNoSQL向けに変更する必要がある。 • コードの改修もまあまあ発生する。 • NoSQLを使いこなすための学習コストがかかる。 ◦ 例：JOINがない、トランザクションがない、などなど・・・。
9. New SQLの採用を検討した
10. New SQLの特徴 中長期的に要件を満たせるDBだと感じた。 • バージョンアップ時にダウンタイムがない。 • Writeがスケールする。 • 強整合性を持つ。 • 耐障害性が高い。
11. New SQLの特徴 • RDBに比べるとレイテンシは高くなる。 ◦ ノード間の通信が発生する。 ◦ データが複数のノードに分散する。 ◦ レプリカ間の整合性を取る処理が必要になる。 • 費用が高くなる傾向にある。 ◦ 同じリソース量の場合はRDBの方が高いパフォーマンスを出せる。 • MySQL, NoSQLの上位互換ではない。 ◦ 適材適所である。
12. Google Cloud Spanner を使おう
13. PingCAPの大エースから謎のDMが来た・・・ このDMはノリなのでは? (´・ω・`)
14. TiDBの特徴 • Spannerの論文を参考に開発されたOSSのNewSQLである。 • MySQL互換 ◦ MySQLのSQLやテーブル定義がそのまま使える。 ◦ ここに価値を感じたので検討候補に入れた。 認証チームも認可チームもMySQLを利用しており、 開発・運用作業やエコシステムをそのまま活かせる。
15. MySQL互換
16. MySQL互換 TiDB独自の仕様は コメント構文で定義することで、 MySQLで有効な構文として 扱うことができる。 MySQL互換を徹底している。
17. TiDB Cloudについて • TiDBを開発しているPingCAPが提供するDBaaSである。 • AWS, Google Cloud に対応している。 • WebUIの管理画面がある。 クラスターのスケールアップや各種メトリクスが確認できる。
20. TiDB Cloudについて • DMMプラットフォームではTiDB Cloudを採用することになる。 ◦ DevOpsを実現するため。 ▪ オンプレのMySQLはインフラ部への作業依頼 & 待ちが発生した。 ▪ 認証チーム、認可チームでインフラ運用が完結するように。
21. 目次 1. New SQLを採用した背景 2. Google Cloud Spanner vs TiDB/TiDB Cloud 3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
22. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
23. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
24. Spannerのざっくりシステムアーキテクチャ
25. 補足：詳細バージョン
26. TiDBのシステムアーキテクチャ
27. 双方のシステムアーキテクチャについて • TiDBはSpannerを参考に開発されただけあって似ている。 ◦ コンピューティングとストレージを分割している。 ◦ Placement Driverによってデータ配置を調整している。 • SpannerはGoogleのインフラレベルで設計されており、 グローバルスケールで高可用性を持つDBになっている。 ◦ Clossus（分散ストレージ） ◦ True Time API（GPS & 原子時計） • TiDBはあくまでソフトウェアである。
28. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
29. パフォーマンス（QPS & レイテンシ） • ノード上のデータ配置、実行するクエリなどに依存するので なんとも言えない。 ◦ TiDBはオンプレにもホスティングできる。 • 強整合性を保証したSELECTのQPSはSpannerの方が高いと思う。 ◦ レプリカの仕様に違いがあるため。
30. TiDBのレプリカ • TiDBはデータをレプリカとして TiKVノードに複製する。 • クエリはリーダーにのみ 向けられる。 • フォロワーは あくまでも バックアップである。
31. Spannerのレプリカ • SpannerはTiDBでいうフォロワーにもアクセスできる。 • フォロワーは 自身が持つデータが 最新かどうかを リーダーに問い合わせる 必要がある。 • リクエストを レプリカに分散できる。
32. パフォーマンス（QPS & レイテンシ） • 強整合性を保証したSELECTのQPSはSpannerの方が高いと思う。 ◦ Spannerはフォロワーに負荷分散できるため。 ◦ リーダーに問い合わせる処理が発生するので、 レイテンシは高くなりそう。 ◦ GPS, 原子時計を利用しているTrue Time APIによって ノード間の時刻差を限りなく小さくできる点も 貢献しているかもしれない。
33. パフォーマンス（JOIN） • Spannerはインターリーブという機能を備えている。 ◦ 親子関係にあるデータを物理的に同じ場所に配置することで 複数のノードからデータをかき集めることがなくなる。 ◦ JOINに強くなる。 ◦ Spannerはグローバルスケールなので こういった最適化が必要なのかもしれない。
34. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
35. 既存DBとの互換性 • TiDBはMySQL互換である。 ◦ 前述した通り一部の機能は利用できない。 • SpannerはPostgreSQL互換を備えている。 ◦ MySQLを利用しているレガシーシステムを PostgreSQLに対応する改修をいれることで Spannerを利用することができる。
36. PGAdapterを利用しなければいけない • SpannerをPostgreSQL互換で 利用するにはPGAdapterという プロキシを利用しなければいけない。 • Cloud Runでホスティングしたり、 サイドカーとして稼働させる。
37. Spanner & PGAdapterは見送った 以下の理由で見送った。 • MySQLに依存したリソースをPostgreSQLに移行する工数がかかる。 どの程度の工数がかかるか読めない。 • PGAdapterと付き合っていかなければいけない。 Spannerはフルマネージドなのにプロキシの運用が発生してしまう。 リプレイスの都合上、オンプレ環境で稼働させる必要がある。 • Spannerを利用するなら覚悟を決めてネイティブ対応した方がよさそう。
38. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
39. OLAP（オンライン分析処理） • New SQLはデータが複数のノードに散るので、 各種分析に必要な集計処理（sum, average, etc）が苦手である。 ◦ RDBも得意というわけではない。 • TiDBは分析処理をサポートしている（HTAP）。 TiFlash（列指向のストレージコンポーネント）を 導入することによってOLAPが可能になる。
41. TiDBにおける分析処理の実現方法 • TiKVのデータをTiFlashにも保存する。 ◦ データを2重で持つことになるが、TiDBが同期してくれる。 • 集計クエリをTiFlashに投げる。 ◦ MySQL互換のクエリを利用することができる。 ▪ OLTP, OLAPを透過的に扱うことができる。 ◦ TiFlashに適したクエリは自動的にTiFlashに投げてくれるが、 明示的に指定することもできる。
42. TiFlashのコスパについて • TiFlashノードを常時稼働させる必要があるのでコスパは微妙。 ◦ 推奨環境は CPU 48コア, Memory 128GB, 2ノード である。 • 可用性を気にしないなら1ノードでも問題ない。 ◦ 分析用途なら1ノードでもよさそう。 ◦ TiDB Cloudの最小構成だと月額980ドルくらい。
43. 補足：TiFlashの分散ストレージ & コンピューティング • TiDB 7.0 以降で利用できる TiFlashのアーキテクチャである。 • 以下のコンポーネントで構成される。 ◦ Write Node ◦ Compute Node ◦ S3 • コスパ良くTiFlashを使える仕組み。
44. OLAP（オンライン分析処理） • TiDBはHTAPをサポートしている。 TiFlash（列指向のストレージコンポーネント）を 導入することによってOLAPが可能になる。 • SpannerはHTAPをサポートしていない。 ◦ BigQueryと連携する必要がある。
45. SpannerとBigQueryの連携 • Change Streamsを利用してデータをBQに連携する。 ◦ Spannerから送られる更新情報を DataflowやストリーミングのAPIを利用してBQに連携する。 • BQのクエリ連携を利用する。 ◦ BQがSpannerのデータを直接クエリする（コピーしない）。 ◦ BQネイティブに比べるとパフォーマンスが劣る可能性がある。 ◦ BQがサポートしないデータ型は扱えない。 別の型にキャストする必要がある。
46. SpannerのData Boost • SpannerのOLTPで 利用されるノードとは 別のノードを用意し、 任意のクエリを実行できる。 • 既存のOLTPに影響を与えない。 • クエリ実行にかかった リソースのみ課金される。
47. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
48. ローカル開発 • TiDBはtiupというCLIツールを利用すると、 ローカルPCに軽量な形でTiDBを立ちあげることができる。 ◦ 本物のTiDBが立ち上がるので各種検証にも利用できる。 ◦ OSSならではのメリットである。 • Spannerは開発/テスト用途のエミュレーターを提供している。 ◦ 本番相当のAPIを提供しているがあくまでエミュレーターである。 ◦ SpannerはクライアントとgRPCで通信するので、 本物のSpannerを立ててローカルからアクセスすればいーのでは。
49. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
50. クラウド費用 • どちらが安いかは一概には言えない。 ◦ パフォーマンス（QPS, レイテンシ）次第になってしまう。 ◦ Enterprise Discount Program(EDP)のような割引も絡んでくる。
51. Spanner vs TiDB/TiDB Cloud 1. システムアーキテクチャ 2. パフォーマンス 3. 既存DBとの互換性 4. OLAP（オンライン分析処理） 5. ローカル開発 6. クラウド費用 7. GCPとの連携
52. GCPとの連携 • SpannerはGCのサービスなので各種GCサービスとの連携がある。 ◦ IAMによるアカウント管理 ◦ Cloud Logging, Cloud Monitoring ◦ BigQueryとの連携 ◦ Lookerとの連携 ◦ Change Streamsによる更新内容のストリーミング
53. 結論：Google Cloud Spanner vs TiDB • Spannerの方が完成度が高い。 • Googleの資金力や開発力に勝つのは難しい。 ◦ 特にインフラも含めて最適化されている点はどうしようもない。 • クラウドサービスとしての品質もGoogle Cloudには敵わない。 ◦ 今まで積み上げてきた実績やエコシステムが存在する。
54. SpannerはTiDBの直接的な競合になるのか? 意外と棲み分けができているのでは? • TiDBはOSSなのでオンプレでのホスティングが可能である。 • MySQL互換 ◦ エコシステムをそのまま利用できる。 ◦ 既存コードに手を入れず、DBを移行することができる。 ▪ レガシーシステムにとっては嬉しい。 ◦ エンジニアの学習コストを低く抑えることができる。 • AWS利用者はTiDB Cloudを利用できる。
55. DMMプラットフォームはTiDB Cloudを採用した • Spannerほどではないが十分実用に耐える品質になっている。 ◦ GAFAのようなビッグテックならまだしも、 日本国内の企業であれば十分利用できる。 • レガシーシステムをリプレイスするDMMプラットフォームでは “MySQL互換” が決め手となってTiDB Cloudを選択した。 ◦ 試しにMySQLからTiDBに向き先を変えてE2Eテストを実行したら そのまま通った。
56. 移行作業を振り返って • エンジニアを2人ほど貼り付けて大体半年くらいかかった。 ◦ カナリアリリースやデータ同期チェック期間による待ちが あったので実際にかかった工数はもっと少ない。 • 移行に必要な実装はダブルライトくらい。 ◦ ダウンタイムが許されないので無停止で移行した。 ◦ レガシーアプリケーションながらも 既存の Insert, Update, Delete をコピペするだけなので サクサク進めることができた。
57. 移行後のレイテンシについて • 認証チームのアプリケーションのレイテンシは 全体的に20~30msecほど上がった。 ◦ 許容できる範囲内なので問題なし。
58. 目次 1. New SQLを採用した背景 2. Google Cloud Spanner vs TiDB/TiDB Cloud 3. TiDB Cloudで本番アプリケーションを運用してみて実際どうか
59. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
60. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
61. TiDB Cloudは安定して動くのか? • DMMプラットフォームはAWS上で半年ほどTiDB Cloudを 利用しているが今のところ安定して動いている。 • 現状のQPSはSELECT, INSERT, UPDATE, DELETE の合計で 約 4,500 QPSくらい。 ◦ TiDB(CPU 8コア, Memory 16GB) * 3台 ◦ TiKV(CPU 8コア, Memory 32GB) * 3台
62. TiDB Cloudは安定して動くのか? • 過去にあったトラブルは以下である。 ◦ キャパプラをミスってレイテンシが悪化した。 ◦ TiKVのバグに遭遇した。 バージョンアップで解消した。
63. TiDB Cloudは安定して動くのか? • TiDBノードのCPU利用率が80%になるとレイテンシが悪化する。 ◦ 80%未満 … 数ミリ〜数十ミリ秒のレイテンシ ◦ 80%以上 … 数百ミリ秒のレイテンシ • TiDBノードのCPU使用率が80%を超えないように キャパプラしている。
64. TiDB Cloudは安定して動くのか? • リプレイスが完了すると約15,000QPSくらいになる想定である。 ◦ 今後の機能追加やRedisを廃止するとQPSはさらに増える。
65. TiDB Cloudは安定して動くのか? • Writeが水平スケールするので、 DMMの各サービスからのスケール依頼に怯えなくてよくなった。 ◦ 例「来月のイベントで5000RPSくらいリクエスト増えるんですけど、大丈夫 ですか?」
66. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
67. コスパはどう? • 中長期的に要件を満たせるDBが手に入ったのは嬉しいが、 コスパがいいわけではないと思う。 • RDBで済むならRDBにした方が良いと思う。
68. 別チームではコスパが理由でTiDBの採用を見送った • AWS Auroraと同等のQPSを出そうとすると インフラ費用が2倍以上かかるので採用を見送った。 レイテンシの悪化はアプリケーション全体で60msec程度だった。 ◦ シンプルに Aurora がすごい。 • 十分なリソースを用意することができれば、 アプリケーション全体のレイテンシの悪化は 100msec以内に収まる感じがする。 • NewSQLはRDBの上位互換ではない。
69. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
70. バージョンアップ戦略 • TiDB Cloudにはロールバック機能がないので一発勝負である。 ◦ 保存したデータまでロールバックすることはできないので、 TiDBとしてロールバック機能をサポートするのは難しい。 • ロールバックするにはロールバック用のクラスタを立てて、 アプリケーションの向き先を変える必要がある。 ◦ データの整合性がどこまで保証されるか不明。
71. できるだけ安全にバージョンアップするために • リリースノートで下位互換性を確認する。 • tiupでバージョンアップ対象のTiDBを立ち上げて、 E2Eテストを流すことでクエリの動作を保証する。 • 最新バージョンの1つ前のマイナーバージョンを利用する。 ◦ 枯れた実装を選択することで動作を保証する。 • 開発用のクラスターで様子を見てから本番用のクラスターを バージョンアップする。 ◦ 本番相当の負荷は来ないので参考程度。
72. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
73. MySQL互換が嬉しい • 既存の開発作業、運用作業、エコシステムに影響なし。 • エンジニアが持つMySQLの知見をそのまま活用できる。 ◦ TiDB移行後に新機能実装が入ったが今まで通りこなせた。 ◦ MySQLの知識を持っているエンジニアは多いので、 新しくチームに参加した人の学習コストが低い。
74. MySQL互換が嬉しい • GitOpsで任意のSQLを実行できる仕組み ◦ gooseというマイグレーションツールを利用している。 • テーブル構成図をGitHub上で確認できる仕組み ◦ tblというドキュメント生成ツールを利用している。
75. そんなに甘くないMySQL互換 • TiDBはMySQL互換だが、裏側はTiDB & TiKVで構成されている。 モノとしてはMySQLとは別物である。 • TiDBを利用して開発・運用するための学習コストがかかる。 ◦ MySQLの知見が100%役に立つわけではない。 ◦ TiDB, TiKVのキャパプラやトラブルシューティングは 試行錯誤している。 ◦ エンタープライズサポートは契約した方がいい。 ▪ 月額費用の20%がサポート費用として上乗せされる。
76. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
77. 意外と便利なTTL機能 • TiDBはテーブルにTTL属性を持たせることができる。 ◦ 認証認可領域はアクセストークンやログインセッションなどの 有効期限を持つデータが多いので意外と利用する機会が多い。
78. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
79. 監視 • TiDB CloudはDatadog, New Relicと連携することができる。 • Datadog, New Relic上のメトリクスが高く出てしまう。 ◦ TiDB Cloudのインフラが原因らしい。 ◦ Datadog, New Relicの監視やダッシュボードが使い物にならない。 ▪ 特に監視は誤発火するので困る。 • TiDB Cloudの管理画面を利用するしかない。
80. TiDB Cloudの管理画面が使いづらい • 各種メトリクスが最大で1週間分しか表示できない。 ◦ 直近1ヶ月のメトリクスを確認しようとすると、 1週間分のメトリクスを4回確認しなければいけない。 • アラートがメールで通知されるのみ。 ◦ 受信したメールをSlack通知する仕組みを作った。
81. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
82. Redisを廃止しようかな • 認証チーム、認可チームのレガシーシステムはRedisを利用している。 ◦ SET, GETが2msec未満くらい。 • Write/Readが水平にスケールするのでTiDBに寄せることが可能。 ◦ 単純なKey-Valueデータの操作は4~15ミリ秒で済む。 ◦ キャッシュのパージ戦略を考慮しなくていい。 ◦ システムアーキテクチャがシンプルになる。 ◦ SQLによる高度なデータ操作が可能になる。 • 費用が高くなりそうなので要検討。
83. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
84. オートスケーラーが欲しい • QPSに応じてスケールイン・アウトして欲しい。 ◦ コスパ良くなる。 ◦ 想定外のスパイクに対応できるようになる。
85. 目次 1. TiDB Cloudは安定して動くのか 2. コスパはどう? 3. バージョンアップ戦略 4. MySQL互換が嬉しい 5. 意外と便利なTTL機能 6. 監視 7. Redis廃止しようかな 8. オートスケーラー 9. マルチテナント型クラスター
86. マルチテナント型クラスター • TiDBはマルチテナントを想定して作られている。 ◦ 例：複数のアプリケーションのDBを1つのクラスターに載せる。 ◦ 例：各アプリケーションのテスト環境を 　　単一のクラスターで実現する。 ◦ 例：Webアプリケーションとバッチアプリケーションが 　　同じDBにアクセスする。 • マルチテナント構成ではノイジーネイバーが問題になる。
87. リソース制御機能 • マルチテナントをサポートする機能としてリソース制御機能がある。 ◦ TiDBのユーザー、セッション、ステートメントごとに 利用できるリソースを制御できる。 ◦ ノイジーネイバーを防ぐことができる。
88. リソース制御機能とバックアップの相性が悪い • TiDB Cloudのバックアップ機能がクラスター単位なので、 バックアップをリストアすると全データが一緒に巻き戻ってしまう。 ◦ DB単位でバックアップできるようになって欲しい。 • いまいちマルチテナントしづらい。 ◦ DMMプラットフォームでもマルチテナント型クラスターを 検討しているが困っている。
89. まとめ • プロダクトとしての完成度はSpannerの方が高い。 ◦ Googleによってインフラレベルで最適化されている。 • TiDBも良いプロダクトであり、Spannerとの棲み分けができてる。 ◦ 国内の企業であれば十分使える。 ◦ オンプレの会社やMySQL利用者に刺さる。 • TiDB Cloudは安定して動くが、管理画面が使いづらい。 ◦ なんだかんだ実用に耐える形になっているので プロダクト設計上手いなと思った。