Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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

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を用いてどのように解決しようとしているのか、また、移行時に発生した問題や移行に伴い行っている取り組みについてご紹介します。

Tech Leverages

July 03, 2024
Tweet

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © 2024 Levtech Co., Ltd. 2 経歴 • システム戦略 /

    アーキテクト / DevOps推進 • 採用 / 技術広報 レバテック株式会社 CTO室 テックリード 河村 勇樹 YUKI KAWAMURA
  2. | © 2024 Levtech Co., Ltd. 3 レバレジーズ株式会社レバテック開発部 グループリーダー 中下 拓也 TAKUYA

    NAKASHITA 経歴 • エンジニアリングマネージャー / 採用 • 運用改善 / セキュリティ・監査強化
  3. | © 2024 Levtech Co., Ltd. 4 Part 1 • レバテックについて

    • TiDBに移行を決めた背景 Part 2 • PoCの概要とつまづいたこと • 移行に向けて工夫したポイント • TiDB Serverlessの活用 Part 3 • TiDB活用の今後 • まとめ アジェンダ INDEX
  4. | © 2024 Levtech Co., Ltd. 7 事業ポートフォリオ レバテックについて エージェント プログラミングス

    クール コンテンツ メディア プラット フォーム ダイレクト リクルーティング ITエンジニア・クリエイターの フリーランス・転職・就職・教育の すべてを備える採用プラットフォーム エージェントを中心に、求人媒体、 プログラミング教育まで IT専門職のキャリアを厚くサポート。
  5. | © 2024 Levtech Co., Ltd. 10 • 中〜大規模な分散システム ◦ サブシステムが複数存在

    ◦ マイクロサービス化 • リポジトリ数(archived:false) ◦ 241 repositories ▪ ※ 2024/07/01 現在 • RDSインスタンス数(本番環境) ◦ 49 個 ▪ ※ 2024/07/01 現在 レバテックに関わるシステム システムの現状 レバテックの大まかな構成図
  6. | © 2024 Levtech Co., Ltd. 12 POINT 01 DBの可用性向上 POINT

    02 2024年はDBを載せ替えるチャンス POINT 03 TiDBへの移行を決めたポイント リソース・管理効率の向上
  7. | © 2024 Levtech Co., Ltd. 13 • 開発組織に対してRDSやAuroraのクラスターが増えすぎた ◦ システム(マイクロサービス)が増えたことが大きな要因

    ◦ 約80人の開発組織に対して約50個のインスタンス • SREが工数とコストに追われてしまう日々 ◦ DB運用に問題が発生した際にSREの工数が奪われる ▪ クラスターの数だけSREは運用問題と戦う ◦ それぞれのクラスターごとに最適なスペック調整が必要 ▪ 無駄に高いスペックを設定すると無駄なお金のコストになる ”リソース・管理効率”の課題感はかなり高かった TiDBに移行を決めた背景 SREの人たち
  8. | © 2024 Levtech Co., Ltd. 14 • RDSやAuroraではゼロダウンタイムの実現が難しい ◦ DDLの反映やアップグレード時にはメンテナンスが必要

    • メンテナンスによる様々な弊害 ◦ 関係者の調整コストが高い ▪ サービスやシステムが増えると関係者も多くなる ▪ DBを停止させるためにはサービス・広告の停止が必要 ◦ 開発者体験の低下 ▪ サービス・広告の停止はできる限り利用者が少ない夜間に行う ▪ 開発者は夜間に出勤して対応する必要がある RDSやAuroraの”可用性”には限界がある TiDBに移行を決めた背景
  9. | © 2024 Levtech Co., Ltd. 16 • MySQL 5.7互換であるAurora MySQL

    2のサポートが切れる • 利用しているRDSがほとんどAurora MySQL 2を利用していた ◦ リザーブドインスタンス(RI)を購入するか一番迷うタイミングでもあった 2024年はMySQLにおいて大きな壁が立ちはだかる TiDBに移行を決めた背景
  10. | © 2024 Levtech Co., Ltd. 17 DBを載せ替えるチャンスは今(2024年)しかない TiDBに移行を決めた背景 現在利用しているAurora MySQL

    2のサポートが切れてしまう リザーブドインスタンス(RI)の購入するかもすごく悩ましい SREが課題としていたDBの”リソース・管理効率”を改善したい DB起因による”メンテナンスを削減”して”幸せな開発者体験”を構築したい
  11. © 2024 Levtech Co., Ltd. TiDBの選定ポイント 20 • 既存のツールやフレームワークも そのまま使える

    • MySQL 互換性のサポートも充実 している MySQL互換 v5.7 / v8.0にも対応
  12. © 2024 Levtech Co., Ltd. TiDBの選定ポイント 21 • オンラインでのスケールアウト・イ ンが可能

    • ダウンタイムが発生しないため、計 画停止が不要に ゼロダウンタイムの実現 計画停止からの脱却
  13. © 2024 Levtech Co., Ltd. • クラスターを1つにすることで管理対象 を1つにすることができる • Resource

    Controlの機能により、 リソース消費の偏りも防ぐことも可能 TiDBの選定ポイント 22 クラスターを一元管理化 リソース・管理効率を向上
  14. © 2024 Levtech Co., Ltd. • Online DDL機能により反映時も 無停止で可能 •

    インデックス・カラムの追加や変更 も高速 TiDBの選定ポイント 23 可用性向上 DDLもオンラインで反映 Aurora 3.0 TiDB インデックス追加 △ ⚪ インデックス削除 △ ◎ カラム追加 ◎ ◎ カラム変更 △ ⚪ ※ 運用中に生じるDDLの性能
  15. | © 2024 Levtech Co., Ltd. 25 • クラスターを一元管理化 SREによるリソース・管理効率を向上 •

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

    ◦ アプリケーション動作テスト ◦ SQLパフォーマンステスト • ツール連携テスト ◦ 機能検証 ◦ 可用性(ゼロダウンタイム)の確認 ◦ リソースコントロール検証 • その他 ◦ AWSとGCPのコスト比較 PoCの概要 PoCの概要とつまづいたこと
  17. | © 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)
  18. | © 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 測定不能!!!
  19. | © 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 なぜ計測不能だったのか? パフォーマンス検証の進め方とつまづきポイント
  20. | © 2024 Levtech Co., Ltd. 34 • EXPLAINの結果からテーブルのフルスキャンは結構発生していた ◦ つまり、TiDBってフルスキャンの影響を結構受けやすいものなのか?

    • じゃあ、なぜAurora MySQLではなんとかなっていたのか? ◦ おそらく、Auroraはインメモリにキャッシュしてくれるところが大きいのだと思う • 逆に、なぜTiDBではなんとかならないのか? ◦ TiDBはメモリにキャッシュをあまりしない構造なのでフルスキャンの影響は大きい ◦ Auroraでもメモリにのらないくらいデータが多い場合は都度読むことになるので 同じ事象になると考えられる ここまでの事象から立てた仮説 パフォーマンス検証の進め方とつまづきポイント
  21. | © 2024 Levtech Co., Ltd. 35 スペックを上げてみる • 効果なし TiFlashを導入してみる

    • 大きく改善 • スコア ◦ Average: 2.326 seconds • 特に効果が出たクエリ ◦ %keyword%のLIKEの中間一致 ▪ 2.8s -> 160ms 結局、どうしたのか? パフォーマンス検証の進め方とつまづきポイント
  22. | © 2024 Levtech Co., Ltd. 38 MySQL互換ではあるが動作しないクエリも存在した ERROR 1235 (42000):

    This version of TiDB doesn't yet support 'subquery in ON condition' アプリケーションでの動作検証 PoCの概要とつまづいたこと
  23. | © 2024 Levtech Co., Ltd. 40 TiDBのバージョンアップ時に可用性を検証 • TiDB CloudのCluster

    アップデートはオペレーターによる実施 • アップデート実施時に10名弱でアプリケーションを操作 アプリケーションでの動作検証 PoCの概要とつまづいたこと
  24. | © 2024 Levtech Co., Ltd. 41 TiDBのバージョンアップ時に可用性を検証 • TiDB CloudのCluster

    アップデートはオペレーターによる実施 • アップデート実施時に10名弱でアプリケーションを操作 ◦ エラーや気になる遅延はなかった アプリケーションでの動作検証 PoCの概要とつまづいたこと
  25. | © 2024 Levtech Co., Ltd. 43 RDS の binlog_format が

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

    MIXED • DMSにて差分(cdc)でのデータ移行不可 • ダウンタイム 最小約6時間 RDS の binlog_format を ROW • DMSにて差分(cdc)でデータ移行可能 • ダウンタイム 最小約15分 PoCの概要とつまづいたこと 全てのRDSにおける binlog_format を ROW に変更 変更時のダウンタイムを最小限にする 移行時に問題になったこと〜DBのログフォーマット〜
  27. | © 2024 Levtech Co., Ltd. 46 TiDB向けにDB Userとリソースグループの作成を内製化 • DB

    Userの作成 ◦ 作成したユーザーの権限設定 ◦ 作成したユーザー情報をAWS SecretManagerに保存 • リソースグループの作成 ◦ リソースグループの RU設定 ◦ 属するユーザー設定 Resource Control作成の自動化 移行時に工夫したこと
  28. | © 2024 Levtech Co., Ltd. 47 TiDB向けにDB Userとリソースグループの作成を内製化 • DB

    Userの作成 ◦ 作成したユーザーの権限設定 ◦ 作成したユーザー情報をAWS SecretManagerに保存 • リソースグループの作成 ◦ リソースグループの RU設定 ◦ 属するユーザー設定 Resource Control作成の自動化 移行時に工夫したこと
  29. | © 2024 Levtech Co., Ltd. 48 • 開発環境の TiDB Dedicated

    を業務時間外に自動停止 • Github Actions の Cron で実行 • TiDB Cloud の API を利用 • Script は TypeScript で実装 平日:15時間起動、土日:停止 開発環境のコストが約半分 開発環境のTiDBの定期起動停止を自動化 移行時に工夫したこと 詳細はテックブログ
  30. | © 2024 Levtech Co., Ltd. 49 • 今まで ◦ 各DB・システムごとにGUI環境はばらばら

    • 前提 ◦ Chat2Query は現状ユーザー単位で制限不可 ◦ 統制観点から個別にアクセスさせない ◦ 開発者がDBを閲覧するインターフェイスを統一 • 結果 ◦ phpmyadminでDBアクセスする環境を統一 phpmyadminでDBアクセスする環境を統一 移行時に工夫したこと
  31. | © 2024 Levtech Co., Ltd. 51 • 社内ツール ◦ Four

    Keysの可視化 • Wordpressを利用したサービス ◦ コーポレートサイト Serverlessの導入事例 Serverlessの活用
  32. | © 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の活用
  33. | © 2024 Levtech Co., Ltd. 53 Serverlessの利用 Serverlessの活用 ぶっちゃけServerlessどう? 小規模や新規プロダクトには良さそう

    Aurora Serverless と比較して初回の応答が早い 無料枠やコストの上限設定が可能
  34. | © 2024 Levtech Co., Ltd. 55 移行スケジュール 今後の方針 2024 2025

    1月 6月 12月 3月 PoC 1アプリ移行 WPリリース 10月 随時アプリ移行
  35. | © 2024 Levtech Co., Ltd. 56 移行スケジュール 今後の方針 2024 2025

    1月 6月 12月 3月 PoC 1アプリ移行 WPリリース 10月 随時アプリ移行 Aurora MySQL v2 標準サポート終了
  36. | © 2024 Levtech Co., Ltd. 57 • 分析基盤としてのTiDB ◦ 現在は”BigQuery”を利用中

    • データ連携が不要になる ◦ Aurora → BigQuery ◦ 連携にFivetranなどを利用 • 懸念 ◦ Google スプレッドシートとの連携 ◦ データ加工レイヤーをどうするか TiFlashの活用 TiDB活用の今後
  37. | © 2024 Levtech Co., Ltd. 58 • 現在 ◦ Public

    Beta ◦ Serverlessのみ利用可能 • 検討案 ◦ 案件検索などの検索UX向上 ◦ 既存のLIKE検索による検索パ フォーマンスの向上 • 実現方法 ◦ Amazon Bedrockを利用 ベクトル検索 Vector Search TiDB活用の今後 TiDB (Serverless) × Amazon Bedrockで始めるRAGアプリケーション入門!
  38. | © 2024 Levtech Co., Ltd. 60 • TiDBへの移行を決めた3つのポイント ◦ 「リソース・管理効率の向上」

    ◦ 「DBの可用性向上」 ◦ 「2024年はDBを載せ替えるチャンス」 • TiDBへの移行はそう簡単ではない ◦ パフォーマンスも場合によっては低下する ◦ 今まで利用していたMySQLのクエリが使えないこともある ◦ 移行に向けてbinlog_formatを変更したり準備が必要 まとめ