はじめに

本記事はGoogle Cloud Next 2024 Day1(2024/8/1)において menu の窪田氏が講演された「"menu"のデータ基盤戦略 ~TiDBとGoogle Cloud~」のレポートです(レポートではデータベース選定にフォーカスしてます)。

公式セッション紹介

フードデリバリーサービス「menu」はモノリスなアーキテクチャーで構成されていましたが、現在はマイクロサービス化がすすめられており、このマイクロサービス化に合わせてデータ基盤全体の見直しも行っています。活用するDBの選択は、成長するサービスにおける学習コストと先々想定される運用負荷の観点で大きな悩みどころでした。本セッションでは、menuがマイクロサービスの中でDBをどのように使い分けているか、データ基盤周りの選択や活用方法について、その中でTiDBをどのように使っているのかなどをご紹介します。

発表資料

現時点では未公開

概要／おすすめポイント

menuでは Cloud SQL for MySQLを利用しているが、システム全体としてモノリシックなアーキテクチャでリリースや追加開発の辛さを感じており、TiDBを採用して移行を行っているとのことでした。
具体的に Cloud SQLでの課題感と何故TiDBを採用するに至ったのかが述べられていたため、同じような課題を抱えている方の参考になるかと思いました。

セッション内容の紹介

前提としては、Cloud SQL for MySQL Enterprise を利用しており、HA構成＆ほぼ上限値のCPU・メモリ設定で利用していました。(Cloud SQLの上限は 96vCPU、624 GBになります)

現状の課題として以下三点を挙げられていました。

レプリケーション遅延
- 商品情報更新の際の大量の insert, update, delete が実行され、レプリカラグが発生する (リードが多くリードレプリカを多用しているため遅延の影響が大きい)
メンテナンス時の課題
- 数十秒のメンテ時間が発生する(Enterprise Plusでは1秒未満になったので解決されるかも？)
ピークへの対応
- プロモーション時の負荷対策、お昼時や夕飯時のピーク負荷対策、商品情報更新時の負荷対策、などが実施し辛い

それぞれ、TiDBで以下のように解決されるとのことでした。

レプリケーション遅延
- writeのスケールが可能となるため、大量のwriteへの対応が可能
メンテナンス時の課題
- フルマネージド・無停止(ただし接続は瞬断)
ピークへの対応
- スケールアウトが可能(ただし現在はそこまでの性能は不要で最低構成)

また、若干レイテンシは増加するものの、menuさんの要件にはほぼ影響がなく、またこちらもmenuさんのシステムではMySQLからTiDBへの切替による非互換もほぼ発生せずそのまま利用できた、という話でした。

Spannerとの比較

Google CloudのSpannerと比較した結果、以下の理由によりTiDBを利用することになったとのことでした。とはいえ、Google Cloudのサービスとしては洗練されていると評価されてはいました。

Spannerの学習コストが高い
MySQL互換ではない(ORMが対応していない)

Cloud SQL Enterprise Plusとの比較

元々検討時においては、Cloud SQL Enterprise Plusが発表されていなかったため、今回改めて比較されたとのことです。

既にCloud SQLの限界近くになっているため、Plusを採用しても上限が見えている
負荷の波への対応やwriteのスケールはできない

まとめ

現時点ではCloud SQLとTiDBを併用することで、新しいサービス開発時に選択肢を持たせることができている、特に開発者側からはどちらもMySQLとして利用することができるため、純粋なアプリ要件で決めることができるのことが良いところとの話でした。

先日のDB Tech ShowcaseでもTiDBのセッションでは利用者側の学習コストが不要で、かつフルマネージドで利用負荷が小さいという事をいろいろなセッションで聞きましたが、同じところがやはり効いてくるのだな、と感じました。
その他にもTTLやTiUPなどの小ネタがありましたので、興味ある方は資料公開されたら見てみるかTiDBのドキュメントを参照ください。