TiDBは銀の弾丸になるのか？ ~ レバテックの課題と新たな挑戦 ~ TiDB User Day 2024

by Tech Leverages

Slide 1

Slide 1 text

TiDBは銀の弾丸になるのか？〜レバテックの課題と新たな挑戦〜レバテック株式会社河村勇樹 / 中下拓也

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

レバテックについて

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

システムの現状

Slide 10

Slide 10 text

|　© 2024 Levtech Co., Ltd. 10 ● 中〜大規模な分散システム ○ サブシステムが複数存在 ○ マイクロサービス化 ● リポジトリ数(archived:false) ○ 241 repositories ■ ※ 2024/07/01 現在 ● RDSインスタンス数(本番環境) ○ 49 個 ■ ※ 2024/07/01 現在レバテックに関わるシステムシステムの現状レバテックの大まかな構成図

Slide 11

Slide 11 text

TiDBに移行を決めた背景

Slide 12

Slide 12 text

Slide 13

Slide 13 text

|　© 2024 Levtech Co., Ltd. 13 ● 開発組織に対してRDSやAuroraのクラスターが増えすぎた ○ システム（マイクロサービス）が増えたことが大きな要因 ○ 約80人の開発組織に対して約50個のインスタンス ● SREが工数とコストに追われてしまう日々 ○ DB運用に問題が発生した際にSREの工数が奪われる ■ クラスターの数だけSREは運用問題と戦う ○ それぞれのクラスターごとに最適なスペック調整が必要 ■ 無駄に高いスペックを設定すると無駄なお金のコストになる ”リソース・管理効率”の課題感はかなり高かった TiDBに移行を決めた背景 SREの人たち

Slide 14

Slide 14 text

|　© 2024 Levtech Co., Ltd. 14 ● RDSやAuroraではゼロダウンタイムの実現が難しい ○ DDLの反映やアップグレード時にはメンテナンスが必要 ● メンテナンスによる様々な弊害 ○ 関係者の調整コストが高い ■ サービスやシステムが増えると関係者も多くなる ■ DBを停止させるためにはサービス・広告の停止が必要 ○ 開発者体験の低下 ■ サービス・広告の停止はできる限り利用者が少ない夜間に行う ■ 開発者は夜間に出勤して対応する必要がある RDSやAuroraの”可用性”には限界がある TiDBに移行を決めた背景

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

|　© 2024 Levtech Co., Ltd. 17 DBを載せ替えるチャンスは今（2024年）しかない TiDBに移行を決めた背景現在利用しているAurora MySQL 2のサポートが切れてしまうリザーブドインスタンス（RI）の購入するかもすごく悩ましい SREが課題としていたDBの”リソース・管理効率”を改善したい DB起因による”メンテナンスを削減”して”幸せな開発者体験”を構築したい

Slide 18

Slide 18 text

※ 銀の弾丸ではございません。笑

Slide 19

Slide 19 text

選定ポイントのご紹介

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Part 1 - まとめ -

Slide 25

Slide 25 text

|　© 2024 Levtech Co., Ltd. 25 ● クラスターを一元管理化 SREによるリソース・管理効率を向上 ● ゼロダウンタイムの実現 Online DDLの機能も含めるとメンテナンスを含めた計画停止も大幅に削減が可能 ● リソース・管理効率の改善は急務サービス・システムの拡大と分散により発生した課題 ● メンテナンスによる様々な弊害関係者の調整コストも高く、開発者体験も低下 ● Aurora MySQL 2のサポート切れ DBを変更するタイミングは今（2024年）しかない MySQL互換のNew SQL TiDBで課題解決に挑戦 DBに関連した課題を解決するチャンス到来 TiDBに移行を決めた背景 - まとめ -

Slide 26

Slide 26 text

PoCの概要とつまづいたこと

Slide 27

Slide 27 text

Slide 28

Slide 28 text

PoCでつまづいたこと

Slide 29

Slide 29 text

① パフォーマンス検証の進め方とつまづきポイント

Slide 30

Slide 30 text

Slide 31

Slide 31 text

|　© 2024 Levtech Co., Ltd. 31 パフォーマンス検証の進め方パフォーマンス検証の進め方とつまづきポイント 1. パフォーマンス検証に利用するクエリを洗い出す実行される頻度が高いSQLと実行速度が遅いSQL（スロークエリ）を用意特徴：%keyword%のようなLIKEの中間一致やフルスキャンが走っているクエリ 2. 比較検証に扱うAuroraのクラスターを作成 TiDB：TiDB 2 Nodes 4 vCPU, 16 GiB TiKV 3 Nodes 4 vCPU, 32 GiB Aurora：db.t3.small 2 vCPU, 2GiB 3. TiDBにデータを取り込む対象のDBからdumpファイルを取得しTiDBにImport ※ TiDBのデフォルトの文字セットがutf8mb4になるので注意 4. パフォーマンス検証に利用するツールの準備 mysqlslapを採用 5. パフォーマンス評価する際の数値を設定対象DBに紐づくサービスのSLI/SLOから一部抜粋して採用 → 5分間で3000リクエストを全て200（OK）

Slide 32

Slide 32 text

|　© 2024 Levtech Co., Ltd. 32 パフォーマンス検証の結果パフォーマンス検証の進め方とつまづきポイント Aurora TiDB 実行される頻度が高いSQL Average: 0.252 seconds Minimum: 0.203 seconds Maximum: 0.494 seconds Average: 0.251 seconds Minimum: 0.209 seconds Maximum: 0.378 seconds 実行速度が遅いSQL（スロークエリ） ※ LIKE中間一致など Average: 0.558 seconds Minimum: 0.511 seconds Maximum: 0.653 seconds 測定不能！！！

Slide 33

Slide 33 text

|　© 2024 Levtech Co., Ltd. 33 結果 ● Query Durationも平均15sだったとりあえずやってみたけどだめだったこと ● ANALYZE（統計）が効いていない？ ○ ANALYZE TABLE t1; ● 統計情報の読込がタイムアウト? ○ tidb_stats_load_sync_wait ● TopNの統計情報を利用してみる？ ○ tidb_default_string_match_selectivity ● ジョブの滞留時間を減らしてみる？ ○ tidb_load_based_replica_read_threshold なぜ計測不能だったのか？パフォーマンス検証の進め方とつまづきポイント

Slide 34

Slide 34 text

|　© 2024 Levtech Co., Ltd. 34 ● EXPLAINの結果からテーブルのフルスキャンは結構発生していた ○ つまり、TiDBってフルスキャンの影響を結構受けやすいものなのか？ ● じゃあ、なぜAurora MySQLではなんとかなっていたのか？ ○ おそらく、Auroraはインメモリにキャッシュしてくれるところが大きいのだと思う ● 逆に、なぜTiDBではなんとかならないのか？ ○ TiDBはメモリにキャッシュをあまりしない構造なのでフルスキャンの影響は大きい ○ Auroraでもメモリにのらないくらいデータが多い場合は都度読むことになるので同じ事象になると考えられるここまでの事象から立てた仮説パフォーマンス検証の進め方とつまづきポイント

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

②アプリケーションでの動作検証

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

③ データ移行問題

Slide 43

Slide 43 text

|　© 2024 Levtech Co., Ltd. 43 RDS の binlog_format が MIXED ● DMSにて差分（cdc）でのデータ移行不可 ● ダウンタイム　最小約6時間 RDS の binlog_format を ROW ● DMSにて差分（cdc）でデータ移行可能 ● ダウンタイム　最小約１５分 PoCの概要とつまづいたこと移行時に問題になったこと〜DBのログフォーマット〜

Slide 44

Slide 44 text

|　© 2024 Levtech Co., Ltd. 44 RDS の binlog_format が MIXED ● DMSにて差分（cdc）でのデータ移行不可 ● ダウンタイム　最小約6時間 RDS の binlog_format を ROW ● DMSにて差分（cdc）でデータ移行可能 ● ダウンタイム　最小約１５分 PoCの概要とつまづいたこと全てのRDSにおける binlog_format を ROW に変更変更時のダウンタイムを最小限にする移行時に問題になったこと〜DBのログフォーマット〜

Slide 45

Slide 45 text

移行の際に工夫したこと

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

|　© 2024 Levtech Co., Ltd. 48 ● 開発環境の TiDB Dedicated を業務時間外に自動停止 ● Github Actions の Cron で実行 ● TiDB Cloud の API を利用 ● Script は TypeScript で実装平日:15時間起動、土日：停止開発環境のコストが約半分開発環境のTiDBの定期起動停止を自動化移行時に工夫したこと詳細はテックブログ

Slide 49

Slide 49 text

|　© 2024 Levtech Co., Ltd. 49 ● 今まで ○ 各DB・システムごとにGUI環境はばらばら ● 前提 ○ Chat2Query は現状ユーザー単位で制限不可 ○ 統制観点から個別にアクセスさせない ○ 開発者がDBを閲覧するインターフェイスを統一 ● 結果 ○ phpmyadminでDBアクセスする環境を統一 phpmyadminでDBアクセスする環境を統一移行時に工夫したこと

Slide 50

Slide 50 text

TiDB Serverlessの活用

Slide 51

Slide 51 text

Slide 52

Slide 52 text

|　© 2024 Levtech Co., Ltd. 52 ● Wordpress を利用したサービス ○ Collationを「utf8mb4_general_ci」に設定を変更 ■ Wordpressのデフォルトは「utf8mb4_unicode_520_ci」 ○ TiDBの初期値では関数が利用出来ない ■ SET GLOBAL tidb_enable_noop_functions=1 ○ コストの上限値は初期は多めに設定しつつ徐々に最適化予定 ■ 初期値は「100$」に設定 Serverlessの導入時に発生した問題 Serverlessの活用

Slide 53

Slide 53 text

Slide 54

Slide 54 text

TiDB活用の今後

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

|　© 2024 Levtech Co., Ltd. 58 ● 現在 ○ Public Beta ○ Serverlessのみ利用可能 ● 検討案 ○ 案件検索などの検索UX向上 ○ 既存のLIKE検索による検索パフォーマンスの向上 ● 実現方法 ○ Amazon Bedrockを利用ベクトル検索 Vector Search TiDB活用の今後 TiDB (Serverless) × Amazon Bedrockで始めるRAGアプリケーション入門！

Slide 59

Slide 59 text

まとめ

Slide 60

Slide 60 text

|　© 2024 Levtech Co., Ltd. 60 ● TiDBへの移行を決めた３つのポイント ○ 「リソース・管理効率の向上」 ○ 「DBの可用性向上」 ○ 「2024年はDBを載せ替えるチャンス」 ● TiDBへの移行はそう簡単ではない ○ パフォーマンスも場合によっては低下する ○ 今まで利用していたMySQLのクエリが使えないこともある ○ 移行に向けてbinlog_formatを変更したり準備が必要まとめ

Slide 61

Slide 61 text

TiDBは銀の弾丸ではありません！笑まずやるべきことは既存のDB設計や課題と向き合うことが大切！

Slide 62

Slide 62 text

宣伝

Slide 63

Slide 63 text

開発職向け会社紹介資料プロダクトや開発組織についてご紹介しています。レバテック開発部テックブログ日々の開発におけるリアルをお届けしています！カジュアル面談フォーム気軽にご応募ください！いろんなお話しましょう！

Slide 64

Slide 64 text

ご静聴ありがとうございました！！！懇親会でもお話ししましょう！！！