なぜAuroraではなくTiDBなのか？　gumiが「ジョジョ」新作で選んだ、脱シャーディング戦略

TiDB検証で直面した2つの課題　gumiはどう乗り越えたのか

　TiDB Cloud導入に向けて検証が始まったのは、リリースの約半年前（2025年3月頃）のこと。比較対象は、gumiで使い慣れているAmazon Auroraだ。

　検証の過程で、2つの技術的課題に直面する。1つ目は、採用しているWebアプリケーションフレームワーク「Django」とTiDBの相性だ。TiDBでは、クラスタ化インデックスとしてのプライマリキー設計が性能に直結する。そのため、アクセスパターンに沿った複合主キー／複合インデックス設計が推奨されるが、10年以上にわたりDjangoは標準機能の複合主キーとしてサポートされていなかった。

　gumiの井上虎太郎氏は、「DjangoのORM（Object-Relational Mapping）が複合主キーに対応していないことは、TiDBの性能を引き出す上で問題となります。もし公式対応がなされなければ、社内でDjangoのORMを独自改修して対応することも考えていました。しかし、後のメンテナンスを考えると、避けたかったのです」と振り返る。

　このとき、偶然にも検証を進めていた時期に幸運が訪れる。Djangoのコミュニティで長年議論されていた複合主キー対応のプルリクエストがマージされ、公式機能としてリリースされたのだ。

　「通常であれば次のメジャーバージョンまで待たされるような機能追加が、たまたま検証のタイミングでリリースされました。これにより標準機能のままで、TiDB推奨のデータ設計が可能になったのです」（井上氏）

　2つ目の課題は、レイテンシーの問題だった。従来のAmazon Aurora環境では、多少非効率なクエリ（いわゆるN+1問題など）があっても、単一リージョン内での低レイテンシーなアクセスに支えられ、目立った遅延は現れにくかった。一方、TiDBのような分散型アーキテクチャでは、ノード間通信などのオーバーヘッドが積み重なるため、同じN+1クエリでも分散配置されたデータに対して多数のラウンドトリップが発生し、高レイテンシーとして顕著に表れるケースがある。

　そこでgumiでは、データベース側のチューニングだけでなく、社内ライブラリ自体の改修を実施した。同社 井上氏は、「TiDBの特性に合わせて、N+1問題が発生しないようにクエリを最適化し、既存の社内フレームワークをTiDBに対応させる形でチューニングを行いました。Amazon Auroraと同等のレスポンスとはいきませんが、実用に耐えうる性能を確保できています」と述べる。

負荷試験で見えたディスク性能の限界　ピンチを救ったPingCAPのサポート

　アプリケーションの実装が進み、リリースに向けた最終フェーズにおける負荷試験において、新たな問題が明らかになった。想定していたリクエスト数（RPS）に対し、パフォーマンスが伸び悩む事象が発生したのだ。

　このとき、ボトルネックとなっていたのはディスクの書き込み性能（IOPS）だった。分散データベースであるTiDBは、計算リソースとストレージリソースを独立してスケールできる強みをもつが、特定の構成ではディスクI/Oが限界に達していた。

　この問題について、TiDBの開発元であるPingCAP社がサポートに入っている。井上氏は、「負荷試験の期間中は、1日に何度も問い合わせを行うほど密に連携をとりました。夜間の問い合わせにも即座に対応してもらえ、パラメータの調整や構成の見直しについても、具体的なアドバイスをもらえたことが問題の解決につながりました」と語る。

　従来のデータベースであれば、ディスク性能を上げるためにはインスタンスタイプを変更したり、データの再配置を行ったりする。そのため、長時間のメンテナンスが必要になるケースは多い。一方、TiDBは稼働したままノードを追加し、リソースを拡張できる。

　gumi 古谷正一氏は、「ディスク性能が足りないと判明した際にも、ダウンタイムなしでディスクリソースを追加（スケールアウト）することで解決できました。リリース直前の切迫した状況下、サービスを止めずに性能問題を解消できたことは、TiDBのアーキテクチャならではの強みだと実感しました」と話す。

　こうしてgumiでは、アプリケーションのコードを大きく変更することなく、インフラ側のスケール操作とチューニングにより、本番運用に耐えうる環境を整えた。バックアッププランとして用意していたAmazon Auroraへの切り戻しを実行することなく、TiDB Cloudによる大型タイトルのローンチを無事に迎えられたのだ。