TiDBへの道

Akira Yamamoto

2024年8月14日 13:17

こんにちは、くふうAIスタジオでエンジニアをしている山本です。
現在の仕事はマネジメントがメインですので、手を動かす機会は減っているのですが、その代わり技術選定などに関わる機会は増えています。

今回は、念願叶って弊社で導入することになった、新しいデータベースTiDB のお話をしようと思います。

が、その前に現状の課題からお話しさせてください。

課題

MySQL, PostgreSQL, Oracle Database など、既存のRDBMSは素晴らしい製品なので、広く利用されており、ご存知の方は多いと思います。
しかし、長期間運用していると様々な問題に遭遇します。

例えば、

テーブルが予想以上に肥大化してしまい、シャーディングやパーティショニングなどのデータ分割が必要になる
書き込みの変動に対して、スケールアップ or ダウンでしか対応できないので、その度にダウンタイムが発生してしまい、調整が必要になる
定期的にバージョンアップをしないといけないが、その度にダウンタイムが発生するので、調整が必要になる
- メジャーバージョンの場合は、さらに動作検証やアプリケーション改修などが発生する

などが挙げられます。

弊社はAWS上にインフラを構築しているため、基本的には Amazon RDS, Amazon Aurora を使用しています。

AWSのサービスは常に進化していますので、これらの問題もかなり緩和されてはいるのですが、やはり対応するのは面倒です。
特に弊社は Zaim 、トクバイ、みんなのウェディング、オウチーノなど歴史あるサービスが多く、使用しているデータベースの数も多いため、思ったより頻繁に発生してエンジニアの時間を奪って行きます。
しかし、やらないという選択肢はありません。

やらないといけない仕事ではあるのですが、やりたくない。
どうしたらいいのでしょうか？

解決策

これらの課題は、 RDBMS が分散システムを前提としていないがゆえに発生しているような気がします。実際、NoSQLである Amazon OpenSearch では上記のような課題が発生したことがありません。

NoSQLという選択肢

そこで、まずは RDBMS ではなく NoSQL データベースを使うという方法を考えてみます。この場合、Amazon DynamoDB や Apache Cassandra などが候補に上がりますが、新規サービスならともかく既存サービスとなると、あまり現実的とは言えません。
アプリケーションの改修やデータ移行が大変な上に、RDBMSとは考え方が異なるので、学習コストも馬鹿になりません。

NewSQLという選択肢

それに対して、NewSQL はとてもいい解決策だと思います。
既存のRDBMSとほぼ同じ機能を備えた上で、分散システムであるという特性上、前述の課題をほぼ全て解決できます。この場合、Vitess、Cloud Spanner、CockroachDB などが候補に上がりますが、SQLの互換性やトランザクションの違いを意識しなければならず、移行にはそこそこのコストがかかりそうです。

そもそも論的に

以上のように、解決策はなくはないのですが、解決することによって得られるメリットと、解決するためのコストが見合う気がしません。
そもそも、データベースはサービスの基幹ですので、おいそれと触るわけにもいきません。

おそらく、前述の課題を解決するだけではダメなのでしょう。

そんな時、TiDBを知りました。

TiDBとは

TiDBはPingCAP社が開発を主導しているOSSのデータベースです。

NewSQLに分類されるデータベースで、MySQLと高い互換性があり、分散システムであるが故に高い可用性を持っています。
OSSを自前で運用するのは辛いものがありますが、PingCAP社が提供している TiDB Cloud を利用すれば問題はなさそうです。

また、前述の課題に対しても、以下のようにほぼ解決できます

データが自動で分割されて保存されるので、テーブルが肥大化しても気にしなくていい
書き込みも無停止で自由にスケールできる。そもそもReader/Writerの区別がない
ローリングアップデートが可能なため、無停止でバージョンアップが可能

さらに、以下のような機能が目を引きました。

リソースコントロール

弊社にたくさんのデータベースが存在する理由は、大小様々なサービスが数多く存在するからです。1つのデータベースに複数のサービスが接続するような状況では、サービスの可用性に問題が出てきます。

例えば、Aというサービスの負荷が上がったら、Bというサービスも接続できなくなる。という状況は到底許容できません。

それに対して、TiDBにはリソース制御の機能が存在し、ユーザー／セッション／クエリごとにリソース割り当てが可能です。つまり、Aというサービスの負荷が上がったとしても、Bというサービスには影響が出ない、という状況が作れるということです。

これをうまく利用すると、データベースの数自体を減らせますし、なにより、複数サービスのデータを結合して検索することが可能になります。

HTAP(Hybrid Transactional and Analytical Processing)

データの重要性は日々増しており、データの分析ができることは必須要件となっています。しかし、分析のためのクエリは大量のデータに対して行われるため、負荷やスピードの観点から通常の行指向データベースでは辛いものがあります。
そのため、列指向データベースである Amazon Redshift や BigQuery にデータを移して、そこで実行することになるのですが、それにはデータパイプラインを組み立て、メンテナンスしていく必要があります。

それに対して、TiDBには TiFlashという列指向データを追加する機能がありますので、行指向と列指向のデータを同時に持てます。
前述のリソースコントロールで負荷の問題も解決できますので、RedshiftやBigQuery の代替までは難しいかもしれませんが、削減効果は期待できそうです。
また、移行のタイムラグがないため、リアルタイムの分析が可能になります。

小さな一歩

しかし、これだけで経営層を説得するのは難しそうです。これまでの話はあくまで謳い文句ですので、実際に試してみる必要があると思いました。
そこで、社内で開発している情報共有ツール「Kajero」のデータベースをTiDBに置き換えてみたところ、驚くほどすんなりと移行が成功しました。

Rails で構築されているサービスなのですが、データを移行して接続先を変更するだけで動いたのはさすがに驚きました。

これはいけそうな気がします。

その結果

他社の公開事例をもとに想定コストを計算したところ、金銭的なメリットはあまりなさそうという計算になりましたが、

運用にかかるコストは確実に削減できそうであること
データベースを1つにできれば、サービス間で相互にデータ参照が可能になること
BigQuery, Redshift を削減でき、それらでは難しいニアリアルタイムの分析が可能になること

などを訴えて、経営層の理解もあり、どうにかPoC予算の獲得に成功しました。
これが2024年2月末の話で、4月あたりからPoCに着手。
このまま何もなければ、今月末、2024年8月末にはトクバイのデータベースをTiDBに置き換えられそうです。

PoCの話は、実際に手を動かしてくれたメンバーに譲ります。
この際、非常に手厚いサポートをして頂いたPingCAP社の方々にはとても感謝しています。この場を借りてお礼を申し上げます。

最後に

定型ですが、くふうAIスタジオでは、採用活動を行っています。
（AX＝AI eXperience（UI/UX における AI/AX）とAI Transformation（DX におけるAX）の意味を持つ当社が唱えた造語）くふうカンパニーグループのサービスの企画開発運用を主な事業とし、非エンジニアさえも当たり前にAIを使いこなせるよう、積極的なAI利活用を推進しています。（サービスの一例：累計DL数1,000万以上の家計簿アプリ「Zaim」、月間利用者数1,600万人のチラシアプリ「トクバイ」等） AXを活用した未来を一緒に作っていく仲間を募集中です。ご興味がございましたら、以下からカジュアル面談のお申込みやご応募等お気軽にお問合せください。

この記事が気に入ったらサポートをしてみませんか？