カプコンが“AAAタイトル”を支える共通基盤に「TiDB」を選んだ理由　無停止基盤のつくりかたとは

MySQLとの「互換性の壁」を乗り越えた、数々のチューニング

　TiDBへの移行において、最も大きな課題となったのは“MySQLとの互換性”だった。特に「AUTO_INCREMENT」の仕様の違いが懸念されたと福井氏は語る。TiDBは、MySQLと100％の互換性があるわけではなく、ストアドプロシージャやトリガーなど、一部機能はサポートされていない。

　たとえば、AUTO_INCREMENTに関して、TiDBのデフォルト設定ではIDの発番が完全に昇順にならないため、MySQLと異なる挙動を示す。これは発番部分のボトルネックを避け、スケールさせるための設計であり、“MySQL互換モード”を採用すれば昇順となるが、ストレージへの書き込み時には、単一ポイントに負荷が集中する「ホットスポット」の可能性や、更新性能にも上限が発生する。

　そこでカプコンは、グローバル展開とクロスプラットフォーム対応を進める上で、「Auto_Random」というTiDBの独自機能をAuto_INCREMENTで採用した。これはIDをランダムに発番することで、データがTiKVノードに分散して保存されるというもの。これによりホットスポットの発生を抑制し、パフォーマンスとスケーラビリティを最大化できる。当初、MySQL互換モードやMySQL互換モードでのホットスポット回避も検討されたが、最終的にはパフォーマンスとスケーラビリティを重視し、Auto_Randomが最適と判断された。

　カプコンではTiDBへの移行検証の結果、アプリケーション側に致命的なエラーの発生はなく、RPS/QPSにおいても想定以上の性能がでることを確認している。クエリの応答時間はAurora MySQLと比較して若干遅いものの、許容範囲内に収まった。また、オンラインでのバージョンアップや構成変更、リプレースに向けたデータ移行も正常に実施できることを確認し、全体としてコストの最適化・削減が見込めることも判断できたという。

　さらに導入時には、さまざまな工夫と性能改善に取り組んでいる。アプリケーションのユニットテストでは、プライマリーキーが乱数になることにともない、リスト比較のクエリで順序違いが発生する。そのため、明示的に「ORDER BY」を使用するか、あるいは集合比較するように改修された。ローカル環境でのDDLがMySQL時と比較して遅い、という課題に対しては、TiDB v8.3.0へのバージョンアップと特定のパラメーター設定によるチューニングで、約105秒から約22秒へと大きく改善している。

　加えて、TiKVのI/Oの遅延やコミットの遅延がCPU使用率70％を超えたとき顕著になる問題に対しては、TiKVストレージのチューニングとして、非同期I/Oの有効化と同時処理数の増加を行った。これによりコミットの応答時間は20〜40％改善し、CPU使用率70％以下でのQPSは10〜15％向上。ただし、これらの設定変更は運用上の注意が必要だと福井氏は注意を促す。

　コネクションプーリング・維持においては、ProxySQLの設定次第で、ノードの追加時やローリングアップデート後の再起動したTiDBノードへの接続がうまくいかない問題が発生した。これを解決するためにProxySQLやアプリケーション側でのコネクション維持のチューニングを行い、比較検証を実施、アプリケーション側でのコネクション維持は管理が難しいため、ProxySQLを利用している。コミュニケーションプーリングや維持を導入することで、TiDBノードのCPU使用率を25〜50％削減できることが確認でき、ノード台数削減によるコスト削減効果も期待できたという。