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

Auroraによるシャーディング運用の限界……「TiDB」に白羽の矢

　gumiといえば、長年にわたりモバイルゲーム業界で、高度な技術力を有してきた企業だ。これまでデータベースに関しては、大量のトラフィックを安定して処理するため、水平分割（シャーディング）を中心としたアーキテクチャを採用してきた。

　具体的には、Amazon Auroraをベースとして、アプリケーション側のライブラリで分散トランザクションやデータ分割を制御するような形だ。この構成で十分な実績を積んできたが、運用面では課題もあった。

　「データベースを物理的に分割して負荷を分散させる手法は、スケーラビリティを確保できる反面、構成変更のたびにメンテナンスが必要になります。ユーザーのデータを守るために不可欠な処理とはいえ、スケールイン／スケールアウトの際にサービスを停止しなければならない点は、機会損失や運用コストの面で長年の課題でした」と、gumi CTOの清水佑吾氏は語る。

　清水氏が率いるインフラチームでは、既存の構成に安住することなく、常に次世代の技術トレンドを注視してきた。データの分散処理に関しても、AppleによるFoundationDBの買収やGoogle Cloud Spannerの登場など、データベース層で分散処理を行う「NewSQL」の動向を追いかける中、数年前から有力な選択肢としてリストアップされていたのが「TiDB Cloud」だ。

　「社内の分析基盤や小規模なツールではTiDB導入の実績があり、MySQL互換であることや運用の手軽さは把握していました。しかし、ゲームの本番環境、それも大型タイトルとなると話は別です。技術的に有望であることは理解しつつも、実際に採用するには適切なタイミングと案件が必要でした」（清水氏）

　そして、実際にTiDB Cloudを本番導入する好機は、「ジョジョの奇妙な冒険 オラオラオーバードライブ」のプロジェクト始動とともに訪れた。gumiの福岡拠点でアプリケーション開発を主導する的野礼峰氏から、「新しいデータベース技術を使いたい」との要望が上がったのだ。

　的野氏は、「従来の水平分割・垂直分割におけるアプローチは、エンジニアに高度な知識が求められます。一方、新しいメンバーが参画した際の学習コスト、開発の労力は削減したいと考えていました。また、物理サーバーを大量に並べた際の管理コストや、後から構成を変更する難しさも懸念点でした。そこで、柔軟に対応できるTiDBのメリットを享受したかったのです」と説明する。

　こうしてインフラチームが温めていた技術戦略と、アプリケーションチームのニーズが合致し、gumiにおけるTiDB Cloudの導入プロジェクトがスタートした。