3つの先行事例から学ぶ、「TiDB」を上手く使いこなす術──「分散」と「統合」の振り子関係の変遷

「単一障害点」をTiDBに置き換えで打破　インフラをシンプルに

ケース3：異種混合データベース環境におけるRDBとNoSQLの統合

　3つ目に見るのは、RDBとNoSQLの統合という、両者の特徴を兼ね備えたNewSQLらしい事例である。

　DMM.comでは、認証APIの基盤としてMySQL、Couchbase、Cassandraという3つのデータベースを利用していた。認証APIは障害が発生すると60以上のサービスにすべてアクセスができなくなるミッションクリティカルな機能であるため高い可用性が求められるが、MySQLのマスタノードが単一障害点になってしまっていた。また、新たな機能が実装されるたびに3つのデータベースに対する機能追加が必要となり、開発効率に問題を抱えていた。3つのデータベースに習熟しなければならないというのも、エンジニアの学習コストを高くしていた。MySQLはリードレプリカ構成をとることでreadはスケールさせられるが、writeがスケールできないというケース1と同じ弱点を抱えていることも、将来的な不安としてあった。

　これらの課題に対して、DMM.comはTiDB Cloudを利用することで大幅にインフラの簡素化を実施。TiDBはMySQL互換であり、移行と開発効率のコストが下げられる点が大きなメリットであった。MySQLのマスタノードが単一障害点になってしまうという可用性の問題も解消した。そしてwrite/readともにスループットをスケールさせることができるようになった。これはケース1でも見た通りである。

振り子のように揺れながら進化する「統合」と「分散」の歴史

　レバテックとDMM.comの事例はどちらも、分散したデータストアの統合という共通した問題意識から出発してTiDBを導入した。歴史を振り返れば、かつてはデータベースというのはモノリシックなRDBが主流であった。それがマイクロサービスなどのアーキテクチャの進展により、分散データストアが一般化した。

　しかし、それによって運用効率の悪化などの問題が顕在化すると、今度はNewSQLによる再統合の流れが来ている、という状況である（しかし、そのNewSQLの中身はというと、第1回で見たように分散データベースなのが若干話をややこしくしている）。データベースに限った話ではないが、システムの世界というのはこのように統合と分散の間を振り子のように揺れながら技術の進化が促されるところがある。今後も、この「統合と分散」という軸でシステムを眺めてみると、思考を整理するのに役立つと思う。

　最終回となる第3回では、TiDBの特長の一つであるHTAPというコンセプトについて、ユースケースを見ながらその可能性を探ってみたいと思う。これもまた、データベースの統合による「スーパーデータベース」の創出という、データベースが長らく実現しようと挑戦してきた「夢」への挑戦である。