「まさに寝られるデータベース」と太鼓判を押すワケとは
記事公開日：2024年3月27日
国内フードデリバリー市場で急成長するmenuは、業界最大シェアを目指して顧客満足度を高めるための新たな施策を次々に打ち出している。より良いサービスを迅速に展開するために欠かせないのがITインフラの柔軟性と俊敏性であり、決済を含むため信頼性や安全性の確保も重要だ。同社ではこれらの要求を満たすため、従来のモノリスアーキテクチャからマイクロサービス化を進めている。
開発者負担軽減と拡張性向上を目指しマイクロサービス化に取り組む
デリバリー・テイクアウトアプリ「menu」を開発・運営するmenuは、2018年にレアゾン・ホールディングスのグループ会社として設立された。設立時はテイクアウト事業からスタートし、新型コロナウィルスによる市場環境の変化を受けて、2020年4月にはフードデリバリー事業に新規参入している。
国内フードデリバリー市場は出前館やUber Eatsといった競合他社が早期参入しており、menuは後発優位性を確保している最中だ。2021年6月にはKDDIとレアゾン・ホールディングス、menuの3社が資本業務提携したことで、ジョイントベンチャーとしてKDDIのアセットを活用したビジネス拡大を図っている。
こうした体制強化もあり、menuは2023年12月より2ヵ月連続で国内フードデリバリーアプリにおけるダウンロード数1位を獲得するまでの成長を遂げている。事業拡大にあわせて既存ITインフラのスケールアップ／スケールアウトで対応してきたが、限界も見えていた。そこでデリバリービジネスを開始して1年後の2022年頃から、新たにマイクロサービス化に舵を切っている。
「当時利用していたサービスのスケールアップも残り1段階しかなくなり、このままでは駄目だと考えていました」というのは、レアゾン・ホールディングス 取締役 CTO & CHROでmenu CTOを務める丹羽隆之氏だ。
株式会社レアゾン・ホールディングス 取締役 CTO & CHRO、menu株式会社 CTO 丹羽隆之氏
拡張性の限界に加えて、ビジネスの拡大とともに膨れ上がったモノリスアーキテクチャのシステム環境では、サービス実装にともなうエンジニアの学習コストも高くなってしまう。マイクロサービス化することで、新たに開発するアプリケーションの影響範囲を分離できるため、「エンジニアが新規開発する際に認知しておくべき範囲を小さくし、負担を減らしたいと考えました」と同社 サービス開発部 Expertの木村友士氏は話す。
複数のシステムが複雑に絡みあっていると、1つの関連システムを理解しているだけでは影響範囲が判断できない。だからこそ、ドメイン毎に疎結合のアーキテクチャにすることで影響を限定し、エンジニアの負荷を下げたいと考えたのだ。
悩んだデータベース選定 Spannerでなく「TiDB」に軍配
マイクロサービス化に舵を切った一方、すべてのメンバーが同様の経験をしているわけではない。だからこそ、“マイクロサービス環境をどう構築していけば良いか”を見極めるために必要なのは“トライ&エラー”だ。「マイクロサービス化はゼロベースと言っても過言ではなく、まずは他社事例を知るところから着手し、王道と言われているアプローチを選びました」と木村氏。一般的なアーキテクチャに則った設計に従い、環境構築は進められることとなる。
menu株式会社 サービス開発部 Expert 木村友士氏
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株式会社 サービス開発部 Expert 窪田浩之氏
これを踏まえて、最初に本番環境で適用したのがmenuアプリケーションのお知らせ機能だ。参照系の処理が中心だったことから、アプリケーションに大きく手を入れずに稼働できており、これを皮切りにマイクロサービス化したサービスのデータベースにTiDB Cloudを適用している。
スモールスタートでマイクロサービス化、“TiDB化”を進めることで少しずつ実績を積んでいき、開発陣の経験値も積み上げていった。そして2024年4月には、いよいよ新機能をマイクロサービス環境下でTiDBを利用して実現するという。
menuでデリバリー注文をすると利用できるおまけ機能（※公開に向けて一部ユーザーに試験公開中）でこの組み合わせを採用したのだ。とはいえ、「基本的にMySQLで設計するときと変わらずに進められました。トランザクションは多くなりますが、そこはTiDBの高拡張性と高性能を信頼しており、これまでのソーシャルゲームで培った経験からも『TiDBで問題ない』との確信がありました」と木村氏は自信を見せる。
もちろん、開発の際に苦労がなかったわけではない。MySQL互換ではあるが、“完全に同じもの”ではなかったこと。また参照系のクエリが極めて多い場合には、レイテンシーが遅くなるケースもあったという。これらの課題は、PingCAPのサポート担当者とやり取りすることで迅速に解決できたとして、「事前にサポートが手厚いとの噂を聞いていましたが、本当でした」と木村氏は述べる。
menuが試してわかった、マイクロサービスとTiDBの相性
大型の機能追加において採用されたマイクロサービスとTiDBの組み合わせ、「アプリケーション開発者はTiDBの内部構造を意識せずとも、MySQLとして扱えばTiDBの利用において苦労することはありません」と窪田氏。また、「TiDBでは、一時的にサービス負荷が上昇することに対する不安がない点も評価できます。MySQLでは必要な性能を確保するために細かなチューニングが求められましたが、TiDBでは現状はチューニングを実施することなく利用できています」と木村氏は話す。
加えて、開発から運用に至るまでの状況をモニタリングダッシュボードでリアルタイムに把握可能だ。「以前、CMキャンペーンを打った際にリソースが足りず、一晩中システムに貼り付いて対処したこともありました。しかし、今ではダッシュボードで確認してコンソールで設定するだけで、簡単にスケールアウトできます。まさにTiDBは『寝られるデータベース』でしょう」と木村氏は語る。
また、拡張性を得るためにMySQLのシャーディングを利用すれば、レプリケーションの同期遅延などに悩まされることになるが「TiDBにはそういったことも一切ありません」と丹羽氏。もちろん、分散データベースである以上はネットワークのオーバーヘッドがあり、レイテンシー面で不利になるだろう。だからこそ、そうした得手不得手を認識した上でアプリケーションを設計し、TiDBを活用することが重要だ。menuにおいても、すべてがTiDBに置き換わるのではなく、適宜棲み分けて利用していく。
既存システムにおいてマイクロサービス化が難しいアプリケーションや機能は、無理して作り替えるのではなく、API化などで緩やかにマイクロサービスへ対応していく。それ以外の切り出せるものから順次マイクロサービス化を進めて、TiDBも適用する。ある程度のマイクロサービス化が進めば、たとえば配達クルーに注文を割り当てるような複雑な処理についても他サービスへの影響を意識する必要がなくなり、最適化に向けたトライ&エラーがしやすくなるという。
他にもTiDBには、「テーブルに対してオンラインでDDLでの実行ができ、リソースコントロールという機能により、異なるサービス間でのリソースの干渉を抑制することができます。これはマイクロサービスとの相性も良いでしょう」と木村氏。サービス負荷の予測が難しいようなサービスでは、TiDBを選択肢に入れるべきだと言う。既にMySQLのシャーディングで苦労しているのなら、TiDBは簡単に使えるだろう。
なお、今度は“TiFlash”（トランザクションデータのリアルタイム分析を可能にするカラムナストレージでTiDBのコンポーネントの1つ）などを利用したデータ活用なども視野に入れており、menuにおけるTiDBの適用範囲はさらに広がりそうだ。
「それぞれのデータベースに得意、不得意があります。そして、TiDBは得意な部分が多いのです。そこをしっかりと見極めて使っていきます」と丹羽氏は言い、TiDBはNoSQLの良いところとRDBMSの良いところをあわせ持ち、安心して使えるものだと評価するのだった。
出典：EnterpriseZine / DB Online – 「「menu」が試してわかったマイクロサービスとTiDBの相性、デリバリー事業の急成長を支えられるか 〜「まさに寝られるデータベース」と太鼓判を押すワケとは〜」(2024年3月27日)
