悩んだデータベース選定 Spannerでなく「TiDB」に軍配
マイクロサービス化に舵を切った一方、すべてのメンバーが同様の経験をしているわけではない。だからこそ、“マイクロサービス環境をどう構築していけば良いか”を見極めるために必要なのは“トライ&エラー”だ。「マイクロサービス化はゼロベースと言っても過言ではなく、まずは他社事例を知るところから着手し、王道と言われているアプローチを選びました」と木村氏。一般的なアーキテクチャに則った設計に従い、環境構築は進められることとなる。
menuが採用したのは、ドメイン駆動設計（DDD）に基づいたソフトウェアアーキテクチャ「オニオンアーキテクチャ」だ。既に利用していたGoogle CloudのGoogle Kubernetes Engine（GKE）に加え、データベースは慣れていたCloud SQL for MySQLを選択した。このとき分散データベースのGoogle Spannerも検討したが、「当時は利用していたオブジェクト・リレーショナル・マッピング・ライブラリとの相性が悪く、さらにSpannerを新規習得するための学習コストもかかることからCloud SQLを選びました」と振り返るのはサービス開発部 Expertの窪田浩之氏だ。
このような構成で試行錯誤していた窪田氏は、とあるクラウドネイティブコンピューティングのイベントで取り上げられていた「TiDB」を知ることとなる。既にCloud SQLではスケールアップの限界は見えていた。これ以上拡張するには「MySQLのシャーディングを使うしかありません。しかし、一度シャーディングしてしまえばレプリカも増えていき、その管理だけでなく縮退運用を行うことも難しくなります」と丹羽氏。そうした苦労を過去に、ゲーム業界などで何度も経験してきたと振り返る。
ここで白羽の矢が立ったのがTiDBだ。分散データベースのTiDBなら、事業規模の拡張にあわせて柔軟に拡張できる。また、増えていくクラスターデータベースの運用管理についてもマネージドサービス「TiDB Cloud」を利用すれば手間がかからない。シャーディングを避けるという意味ではSpannerも条件を満たすが、新たな学習コストが必要だ。その点、TiDBは分散データベースであり、MySQLとの互換性もある。さらに運用を考慮しても「TiDB Cloudにはモニタリングダッシュボードもあり、これがあれば夜もゆっくり寝られます」と木村氏は笑みをこぼす。
TiDBの評判の良さを社内外で聞いた丹羽氏は、menuのマイクロサービス化にともなうデータベースとして有効だと判断し、2022年11月にはローカル環境での構築・検証を実施している。MySQLベースで構築されたアプリケーションのデータベースをTiDBに切り替えて動かしてみたところ、動作に何ら問題ないことが確認できたとして「複雑なSQLがなかったことから、接続先を切り替えただけですんなり動きました」と窪田氏は述べる。
これを踏まえて、最初に本番環境で適用したのがmenuアプリケーションのお知らせ機能だ。参照系の処理が中心だったことから、アプリケーションに大きく手を入れずに稼働できており、これを皮切りにマイクロサービス化したサービスのデータベースにTiDB Cloudを適用している。
スモールスタートでマイクロサービス化、“TiDB化”を進めることで少しずつ実績を積んでいき、開発陣の経験値も積み上げていった。そして2024年4月には、いよいよ新機能をマイクロサービス環境下でTiDBを利用して実現するという。
menuでデリバリー注文をすると利用できるおまけ機能（※公開に向けて一部ユーザーに試験公開中）でこの組み合わせを採用したのだ。とはいえ、「基本的にMySQLで設計するときと変わらずに進められました。トランザクションは多くなりますが、そこはTiDBの高拡張性と高性能を信頼しており、これまでのソーシャルゲームで培った経験からも『TiDBで問題ない』との確信がありました」と木村氏は自信を見せる。
もちろん、開発の際に苦労がなかったわけではない。MySQL互換ではあるが、“完全に同じもの”ではなかったこと。また参照系のクエリが極めて多い場合には、レイテンシーが遅くなるケースもあったという。これらの課題は、PingCAPのサポート担当者とやり取りすることで迅速に解決できたとして、「事前にサポートが手厚いとの噂を聞いていましたが、本当でした」と木村氏は述べる。
