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

# TiDB User Day 2024
#TiUD #TiUD2024
https://pingcap.co.jp/tidb-user-day/

# タイムテーブル
13:05 - 13:35 TiDBは銀の弾丸になるのか？ ~ レバテックの課題と新たな挑戦 ~

# 概要
「レバテック」は、ITエンジニアと開発組織の挑戦と成長を加速させるための採用プラットフォームです。ビジョンとして、「日本を、IT先進国に。」を掲げ、多角的に事業拡大を続けています。事業拡大を続ける中で課題となったのが、「DBのリソース・管理効率」と「開発者体験」の低下です。そんな課題を解決できる可能性として現れたのが「TiDB」です。本セッションでは、レバテックの課題をTiDBを用いてどのように解決しようとしているのか、また、移行時に発生した問題や移行に伴い行っている取り組みについてご紹介します。

Transcript

1. TiDBは 銀の弾丸になるのか？ 〜 レバテックの課題と新たな挑戦 〜 レバテック株式会社 河村 勇樹 / 中下 拓也
2. |　© 2024 Levtech Co., Ltd. 2 経歴 • システム戦略 / アーキテクト / DevOps推進 • 採用 / 技術広報 レバテック株式会社 CTO室 テックリード 河村 勇樹 YUKI KAWAMURA
3. |　© 2024 Levtech Co., Ltd. 3 レバレジーズ株式会社レバテック開発部　グループリーダー 中下 拓也 TAKUYA NAKASHITA 経歴 • エンジニアリングマネージャー / 採用 • 運用改善 / セキュリティ・監査強化
4. |　© 2024 Levtech Co., Ltd. 4 Part 1 • レバテックについて • TiDBに移行を決めた背景 Part 2 • PoCの概要とつまづいたこと • 移行に向けて工夫したポイント • TiDB Serverlessの活用 Part 3 • TiDB活用の今後 • まとめ アジェンダ INDEX
5. レバテックについて
6. |　© 2024 Levtech Co., Ltd. 6 VISIONとMISSION レバテックについて
7. |　© 2024 Levtech Co., Ltd. 7 事業ポートフォリオ レバテックについて エージェント プログラミングス クール コンテンツ メディア プラット フォーム ダイレクト リクルーティング ITエンジニア・クリエイターの フリーランス・転職・就職・教育の すべてを備える採用プラットフォーム エージェントを中心に、求人媒体、 プログラミング教育まで IT専門職のキャリアを厚くサポート。
8. |　© 2024 Levtech Co., Ltd. 8 何をつくっているか レバテックについて コンテンツメディア Q&Aプラットフォーム 採用管理ツール 案件/求人サイト スマホアプリ LP/サービスサイト
9. システムの現状
10. |　© 2024 Levtech Co., Ltd. 10 • 中〜大規模な分散システム ◦ サブシステムが複数存在 ◦ マイクロサービス化 • リポジトリ数(archived:false) ◦ 241 repositories ▪ ※ 2024/07/01 現在 • RDSインスタンス数(本番環境) ◦ 49 個 ▪ ※ 2024/07/01 現在 レバテックに関わるシステム システムの現状 レバテックの大まかな構成図
11. TiDBに移行を決めた背景
12. |　© 2024 Levtech Co., Ltd. 12 POINT 01 DBの可用性向上 POINT 02 2024年はDBを載せ替えるチャンス POINT 03 TiDBへの移行を決めたポイント リソース・管理効率の向上
13. |　© 2024 Levtech Co., Ltd. 13 • 開発組織に対してRDSやAuroraのクラスターが増えすぎた ◦ システム（マイクロサービス）が増えたことが大きな要因 ◦ 約80人の開発組織に対して約50個のインスタンス • SREが工数とコストに追われてしまう日々 ◦ DB運用に問題が発生した際にSREの工数が奪われる ▪ クラスターの数だけSREは運用問題と戦う ◦ それぞれのクラスターごとに最適なスペック調整が必要 ▪ 無駄に高いスペックを設定すると無駄なお金のコストになる ”リソース・管理効率”の課題感はかなり高かった TiDBに移行を決めた背景 SREの人たち
14. |　© 2024 Levtech Co., Ltd. 14 • RDSやAuroraではゼロダウンタイムの実現が難しい ◦ DDLの反映やアップグレード時にはメンテナンスが必要 • メンテナンスによる様々な弊害 ◦ 関係者の調整コストが高い ▪ サービスやシステムが増えると関係者も多くなる ▪ DBを停止させるためにはサービス・広告の停止が必要 ◦ 開発者体験の低下 ▪ サービス・広告の停止はできる限り利用者が少ない夜間に行う ▪ 開発者は夜間に出勤して対応する必要がある RDSやAuroraの”可用性”には限界がある TiDBに移行を決めた背景
15. |　© 2024 Levtech Co., Ltd. 15 ※ レバテックのマーケティング責任者のコメント できる限りサービスやユーザーに影響が起きないようにメンテナンスすべき 努力目標としてメンテナンスはできる限り発生しない状態にしたい メンテナンス発生時にサービスを停止してはいけないわけではない 余談：レバテックは止められないサービスではない TiDBに移行を決めた背景
16. |　© 2024 Levtech Co., Ltd. 16 • MySQL 5.7互換であるAurora MySQL 2のサポートが切れる • 利用しているRDSがほとんどAurora MySQL 2を利用していた ◦ リザーブドインスタンス（RI）を購入するか一番迷うタイミングでもあった 2024年はMySQLにおいて大きな壁が立ちはだかる TiDBに移行を決めた背景
17. |　© 2024 Levtech Co., Ltd. 17 DBを載せ替えるチャンスは今（2024年）しかない TiDBに移行を決めた背景 現在利用しているAurora MySQL 2のサポートが切れてしまう リザーブドインスタンス（RI）の購入するかもすごく悩ましい SREが課題としていたDBの”リソース・管理効率”を改善したい DB起因による”メンテナンスを削減”して”幸せな開発者体験”を構築したい
18. ※ 銀の弾丸ではございません。笑
19. 選定ポイントのご紹介
20. © 2024 Levtech Co., Ltd. TiDBの選定ポイント 20 • 既存のツールやフレームワークも そのまま使える • MySQL 互換性のサポートも充実 している MySQL互換 v5.7 / v8.0にも対応
21. © 2024 Levtech Co., Ltd. TiDBの選定ポイント 21 • オンラインでのスケールアウト・イ ンが可能 • ダウンタイムが発生しないため、計 画停止が不要に ゼロダウンタイムの実現 計画停止からの脱却
22. © 2024 Levtech Co., Ltd. • クラスターを１つにすることで管理対象 を１つにすることができる • Resource Controlの機能により、 リソース消費の偏りも防ぐことも可能 TiDBの選定ポイント 22 クラスターを一元管理化 リソース・管理効率を向上
23. © 2024 Levtech Co., Ltd. • Online DDL機能により反映時も 無停止で可能 • インデックス・カラムの追加や変更 も高速 TiDBの選定ポイント 23 可用性向上 DDLもオンラインで反映 Aurora 3.0 TiDB インデックス追加 △ ⚪ インデックス削除 △ ◎ カラム追加 ◎ ◎ カラム変更 △ ⚪ ※　運用中に生じるDDLの性能
24. Part 1 - まとめ -
25. |　© 2024 Levtech Co., Ltd. 25 • クラスターを一元管理化 SREによるリソース・管理効率を向上 • ゼロダウンタイムの実現 Online DDLの機能も含めるとメンテナンスを含 めた計画停止も大幅に削減が可能 • リソース・管理効率の改善は急務 サービス・システムの拡大と分散により発生した課題 • メンテナンスによる様々な弊害 関係者の調整コストも高く、開発者体験も低下 • Aurora MySQL 2のサポート切れ DBを変更するタイミングは今（2024年）しかない MySQL互換のNew SQL TiDBで課題解決に挑戦 DBに関連した課題を 解決するチャンス到来 TiDBに移行を決めた背景 - まとめ -
26. PoCの概要とつまづいたこと
27. |　© 2024 Levtech Co., Ltd. 27 • 移行検証 ◦ MySQLの互換テスト ◦ アプリケーション動作テスト ◦ SQLパフォーマンステスト • ツール連携テスト ◦ 機能検証 ◦ 可用性（ゼロダウンタイム）の確認 ◦ リソースコントロール検証 • その他 ◦ AWSとGCPのコスト比較 PoCの概要 PoCの概要とつまづいたこと
28. PoCでつまづいたこと
29. ① パフォーマンス検証の進め方とつまづきポイント
30. |　© 2024 Levtech Co., Ltd. 30 パフォーマンス検証の進め方とつまづきポイント どこにつまづくのかというと... 期待していたパフォーマンスが出ませんでした。笑 ※ 簡単に説明させていただきます ※ 決して、TiDBやAuroraを批判するものではございません笑
31. |　© 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）
32. |　© 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 測定不能！！！
33. |　© 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 なぜ計測不能だったのか？ パフォーマンス検証の進め方とつまづきポイント
34. |　© 2024 Levtech Co., Ltd. 34 • EXPLAINの結果からテーブルのフルスキャンは結構発生していた ◦ つまり、TiDBってフルスキャンの影響を結構受けやすいものなのか？ • じゃあ、なぜAurora MySQLではなんとかなっていたのか？ ◦ おそらく、Auroraはインメモリにキャッシュしてくれるところが大きいのだと思う • 逆に、なぜTiDBではなんとかならないのか？ ◦ TiDBはメモリにキャッシュをあまりしない構造なのでフルスキャンの影響は大きい ◦ Auroraでもメモリにのらないくらいデータが多い場合は都度読むことになるので 同じ事象になると考えられる ここまでの事象から立てた仮説 パフォーマンス検証の進め方とつまづきポイント
35. |　© 2024 Levtech Co., Ltd. 35 スペックを上げてみる • 効果なし TiFlashを導入してみる • 大きく改善 • スコア ◦ Average: 2.326 seconds • 特に効果が出たクエリ ◦ %keyword%のLIKEの中間一致 ▪ 2.8s -> 160ms 結局、どうしたのか？ パフォーマンス検証の進め方とつまづきポイント
36. |　© 2024 Levtech Co., Ltd. 36 パフォーマンス検証の進め方とつまづきポイント パフォーマンス検証の進め方とつまづきポイント テックブログ（Zenn） 詳細はテックブログを 参照してください！
37. ②アプリケーションでの動作検証
38. |　© 2024 Levtech Co., Ltd. 38 MySQL互換ではあるが動作しないクエリも存在した ERROR 1235 (42000): This version of TiDB doesn't yet support 'subquery in ON condition' アプリケーションでの動作検証 PoCの概要とつまづいたこと
39. |　© 2024 Levtech Co., Ltd. 39 MySQL互換ではあるが動作しないクエリも存在した アプリケーションでの動作検証 PoCの概要とつまづいたこと
40. |　© 2024 Levtech Co., Ltd. 40 TiDBのバージョンアップ時に可用性を検証 • TiDB CloudのCluster アップデートはオペレーターによる実施 • アップデート実施時に10名弱でアプリケーションを操作 アプリケーションでの動作検証 PoCの概要とつまづいたこと
41. |　© 2024 Levtech Co., Ltd. 41 TiDBのバージョンアップ時に可用性を検証 • TiDB CloudのCluster アップデートはオペレーターによる実施 • アップデート実施時に10名弱でアプリケーションを操作 ◦ エラーや気になる遅延はなかった アプリケーションでの動作検証 PoCの概要とつまづいたこと
42. ③ データ移行問題
43. |　© 2024 Levtech Co., Ltd. 43 RDS の binlog_format が MIXED • DMSにて差分（cdc）でのデータ移行不可 • ダウンタイム　最小約6時間 RDS の binlog_format を ROW • DMSにて差分（cdc）でデータ移行可能 • ダウンタイム　最小約１５分 PoCの概要とつまづいたこと 移行時に問題になったこと〜DBのログフォーマット〜
44. |　© 2024 Levtech Co., Ltd. 44 RDS の binlog_format が MIXED • DMSにて差分（cdc）でのデータ移行不可 • ダウンタイム　最小約6時間 RDS の binlog_format を ROW • DMSにて差分（cdc）でデータ移行可能 • ダウンタイム　最小約１５分 PoCの概要とつまづいたこと 全てのRDSにおける binlog_format を ROW に変更 変更時のダウンタイムを最小限にする 移行時に問題になったこと〜DBのログフォーマット〜
45. 移行の際に工夫したこと
46. |　© 2024 Levtech Co., Ltd. 46 TiDB向けにDB Userとリソースグループの作成を内製化 • DB Userの作成 ◦ 作成したユーザーの権限設定 ◦ 作成したユーザー情報をAWS SecretManagerに保存 • リソースグループの作成 ◦ リソースグループの RU設定 ◦ 属するユーザー設定 Resource Control作成の自動化 移行時に工夫したこと
47. |　© 2024 Levtech Co., Ltd. 47 TiDB向けにDB Userとリソースグループの作成を内製化 • DB Userの作成 ◦ 作成したユーザーの権限設定 ◦ 作成したユーザー情報をAWS SecretManagerに保存 • リソースグループの作成 ◦ リソースグループの RU設定 ◦ 属するユーザー設定 Resource Control作成の自動化 移行時に工夫したこと
48. |　© 2024 Levtech Co., Ltd. 48 • 開発環境の TiDB Dedicated を業務時間外に自動停止 • Github Actions の Cron で実行 • TiDB Cloud の API を利用 • Script は TypeScript で実装 平日:15時間起動、土日：停止 開発環境のコストが約半分 開発環境のTiDBの定期起動停止を自動化 移行時に工夫したこと 詳細はテックブログ
49. |　© 2024 Levtech Co., Ltd. 49 • 今まで ◦ 各DB・システムごとにGUI環境はばらばら • 前提 ◦ Chat2Query は現状ユーザー単位で制限不可 ◦ 統制観点から個別にアクセスさせない ◦ 開発者がDBを閲覧するインターフェイスを統一 • 結果 ◦ phpmyadminでDBアクセスする環境を統一 phpmyadminでDBアクセスする環境を統一 移行時に工夫したこと
50. TiDB Serverlessの活用
51. |　© 2024 Levtech Co., Ltd. 51 • 社内ツール ◦ Four Keysの可視化 • Wordpressを利用したサービス ◦ コーポレートサイト Serverlessの導入事例 Serverlessの活用
52. |　© 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の活用
53. |　© 2024 Levtech Co., Ltd. 53 Serverlessの利用 Serverlessの活用 ぶっちゃけServerlessどう？ 小規模や新規プロダクトには良さそう Aurora Serverless と比較して初回の応答が早い 無料枠やコストの上限設定が可能
54. TiDB活用の今後
55. |　© 2024 Levtech Co., Ltd. 55 移行スケジュール 今後の方針 2024 2025 1月 6月 12月 3月 PoC 1アプリ移行 WPリリース 10月 随時アプリ移行
56. |　© 2024 Levtech Co., Ltd. 56 移行スケジュール 今後の方針 2024 2025 1月 6月 12月 3月 PoC 1アプリ移行 WPリリース 10月 随時アプリ移行 Aurora MySQL v2 標準サポート終了
57. |　© 2024 Levtech Co., Ltd. 57 • 分析基盤としてのTiDB ◦ 現在は”BigQuery”を利用中 • データ連携が不要になる ◦ Aurora → BigQuery ◦ 連携にFivetranなどを利用 • 懸念 ◦ Google スプレッドシートとの連携 ◦ データ加工レイヤーをどうするか TiFlashの活用 TiDB活用の今後
58. |　© 2024 Levtech Co., Ltd. 58 • 現在 ◦ Public Beta ◦ Serverlessのみ利用可能 • 検討案 ◦ 案件検索などの検索UX向上 ◦ 既存のLIKE検索による検索パ フォーマンスの向上 • 実現方法 ◦ Amazon Bedrockを利用 ベクトル検索 Vector Search TiDB活用の今後 TiDB (Serverless) × Amazon Bedrockで始めるRAGアプリケーション入門！
59. まとめ
60. |　© 2024 Levtech Co., Ltd. 60 • TiDBへの移行を決めた３つのポイント ◦ 「リソース・管理効率の向上」 ◦ 「DBの可用性向上」 ◦ 「2024年はDBを載せ替えるチャンス」 • TiDBへの移行はそう簡単ではない ◦ パフォーマンスも場合によっては低下する ◦ 今まで利用していたMySQLのクエリが使えないこともある ◦ 移行に向けてbinlog_formatを変更したり準備が必要 まとめ
61. TiDBは銀の弾丸ではありません！笑 まずやるべきことは 既存のDB設計や課題と向き合うことが大切！
62. 宣伝
63. 開発職向け会社紹介資料 プロダクトや開発組織についてご紹介しています。 レバテック開発部テックブログ 日々の開発におけるリアルをお届けしています！ カジュアル面談フォーム 気軽にご応募ください！いろんなお話しましょう！
64. ご静聴ありがとうございました！！！ 懇親会でもお話ししましょう！！！