増えすぎたデータベースと計画停止の苦労を、TiDBへの移行で解決できるか？ レバテックの挑戦［PR］
今回は「増えすぎたデータベースと計画停止の苦労を、TiDBへの移行で解決できるか？ レバテックの挑戦［PR］」についてご紹介します。
関連ワード （出勤、形式、遅延等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
ITエンジニアやクリエイター向けに転職や採用のためのプラットフォームおよびコンテンツメディアなどを提供するレバテックは、マイクロサービス化したことにより増えすぎてしまったデータベースや計画停止に必要な社内調整の困難さに直面していました。
それを解決すべく導入したのがMySQL互換でスケーラブルな特徴を持つ「TiDB」でした。
同社はPoCによってTiDBの十分な性能、アプリケーションを移植可能なMySQLとの互換性、オンラインのままバージョンアップやDDLの実行などが可能な高い可用性などを確認し、現在アプリケーションの移行作業に取りかかっているところです。
同社がいかにTiDBを評価したのか、その内容が今年（2024年）7月に行われたイベント「TiDB User Day 2024」のセッション「TiDBは銀の弾丸になるのか？ ~ レバテックの課題と新たな挑戦 ~」で語られました。
本記事ではそのセッションをダイジェストで紹介します。
（写真左から）レバテック株式会社 CTO室 テックリード 河村勇樹氏、レバレジーズ株式会社レバテック開発部 グループリーダー 中下拓也氏増えすぎたデータベースに課題を感じる
レバテックのシステムはサブシステムが多数存在する中規模から大規模な分散システムであり、マイクロサービス化されています。リポジトリ数は241、バックエンドデータベースとして使用しているAmazon RDSのインスタンス数は本番環境で49個となっています。
TiDB採用以前、マイクロサービス化したことによるAmazon RDSやAmazon Auroraのクラスタ数の増加はデータベースの調整や最適化にかかる工数の増加につながり、それが担当するSREの負担増加となっていました。
また、Amazon RDSとAmazon Auroraでは、システムを止めずにデータベーススキーマの変更やDBMSのバージョンアップを行うことに限界があり、ゼロダウンタイムを実現することが困難だったと河村氏は話します。
計画停止を実行するためには営業などの関連部署との調整が必要なこと、計画停止によるメンテナンスの実行時には開発者が営業時間外に出勤する必要があるため、開発者体験が低下するといったことも課題だったとしました。
さらに、利用していたMySQL 5.7互換のAmazon Aurora MySQL バージョン2のサポート終了が2024年10月末に予定されていたことも、次のデータベースをどうするかを検討するタイミングとして意識されていました。
そこにTiDBが現れた
そこでレバテックが目を付けたのがTiDBです。TiDBを選定したポイントは以下の通り3つありました。
1点目はMySQL互換です。MySQL 5.7と8.0のいずれにも対応しています。河村氏は、MySQLのツールやフレームワークがそのまま使えるのは魅力的だと話しました。
2点目はゼロダウンタイム実現の可能性です。オンラインでのスケールアウト、スケールインが可能ですので、メンテナンスのための計画停止が不要になります。
3点目はクラスタを一元管理できて、リソース効率や管理効率が向上できることです。散在していたクラスタをTiDBの1つのクラスタにまとめることができれば管理対象を1つにできます。
4点目はさらなる可用性の向上です。TiDBはDDLをオンラインで反映できて、インデックスの追加や削除も高速なので、可用性をこれまで以上に向上できると期待できます。
これらの利点を踏まえ、TiDBの導入に挑戦することにしました。
性能検証でなぜか測定不能に
導入にあたり行った概念検証（PoC：Proof of Concept）では、移行検証としてMySQL互換テスト、アプリケーション動作テスト、SQLパフォーマンステスト、ツール連携テスト、コスト比較などを行いました。
そのPoCにおいて中下氏は「（TiDBで）期待したパフォーマンスが出せなかったことがつまづきポイントだった」と説明します。
パフォーマンス検証では、実行頻度が高いSQLと実行速度が遅いSQL（スロークエリ）を用いて、Amazon AuroraとTiDBの性能を比較する形で行われました。
クラスタのスペックは、TiDBが「TiDB 2 Nodes 4 vCPU, 16 GiB TiKV 3 Nodes 4 vCPU, 32 GiB」、Auroraが「db.t3.small 2 vCPU, 2GiB」としました。
比較結果として、実行される頻度が高いSQLについてはAmazon AuroraとTiDBでは大きな性能差は見られませんでしたが、スロークエリでは、TiDBでは測定不能という結果となりました。
中下氏はTiDBで測定不能になった原因として、「実行計画を見るとテーブルのフルスキャンの発生頻度が高くなっています。TiDBはメモリにあまりキャッシュしないためフルスキャンの影響を受けやすいのではないか」と見立てています。
結局、TiDBのオプションとして分析エンジン機能を実現するTiFlashを導入したところ、160ミリ秒で検索が完了するという大幅な性能改善が実現できました。
パフォーマンス検証の詳細については、レバテック開発部のブログ記事「TiDBにおけるパフォーマンス検証の進め方とつまづきポイント」で解説されています。
アプリケーションの動作検証と可用性の検証
アプリケーションの動作検証では、実稼働しているアプリケーションの接続先のデータベースをTiDBに変更したところ、動作しないクエリがいくつか見つかりました。
例えばサブクエリで別のテーブルを呼び出す操作はTiDBではサポートされていなかったためにエラーが返りました。
そこで、サポートされているような形式にクエリを書き換えることで動作可能になりました。
TiDBのバージョンアップが行われているときなど、メンテナンス時における可用性も検証しました。
レバテックではTiDB Cloudを使用しているため、TiDBのアップデートはTiDB Cloudを提供しているPingCAPが実施します。
PingCAPと連携して検証したところ、TiDBのバージョンアップが行われているときでもエラーや気になる遅延は生じませんでした。
PoCを踏まえ、TiDBへの移行を開始
このPoCは2024年2月から3月にかけて実施され、結果を踏まえて移行することとし、4月と5月の2カ月で移行準備。6月からは大きめのアプリケーションの移行を開始しました。
コーポレートサイトに利用しているWordPressのバックエンドデータベースもTiDBへ移行するなど、その他のアプリケーションも随時移行を行っており、「2025年3月までに全て移行できたら」と河村氏は目標時期を明らかにしました。
同社は分析基盤としてTiDBのオプションであるTiFlashの導入やベクトル検索のTiDB Vector Searchの導入を検討しています。
ベクトル検索を導入することにより、案件検索や求人検索でのUX向上やLIKE検索による検索パフォーマンスの向上が見込めそうです。実際に活用する場合には、Amazon Bedrockと組み合わせることになりそうだと河村氏は語ります。
最後に河村氏は「TiDBは銀の弾丸ではありません。まずやるべきことは（スロークエリの性能検証で発覚したフルスキャンが頻発していたことなど）既存データベース設計や課題と向き合うことです」と話して講演をまとめました。
≫TiDB User Day 2024
（本記事はPingCAP Japan提供のタイアップ記事です）