トラフィックが予測できないオンラインゲームのローンチでも、NewSQLの動的サイジングは十分に機能したのか？［PR］

これまでトランザクション機能を備えたリレーショナルデータベースの性能を、柔軟に拡大、縮小することは容易ではないとされてきました。しかし最近になってPingCAP社のTiDB（タイデービー）に代表される、いわゆるNewSQLと呼ばれるスケーラブルなリレーショナルデータベースの登場によってその常識が変わろうとしています。

NewSQLでは一般に、データベースを分割して処理する「シャーディング」をデータベースエンジン配下で透過的に行う機能を備えています。このシャーディングによる分散処理で、トランザクション処理を備えつつスケーラブルなリレーショナルデータベースを実現しているのです。

しかし果たしてこのスケーラビリティは、例えばオンラインゲームのローンチのような、トラフィックの予測が難しい状況でも十分に機能するのでしょうか？

昨年（2024年）6月にモバイル向けオンラインゲームのタイトル「PANDOLAND（パンドランド）」をローンチしたワンダープラネットは、そのバックエンドデータベースとしてNewSQLのTiDBを採用。

実際にTiDBでの運用がどうであったのかが、2024年8月に行われたゲーム開発者向け技術カンファレンス「CEDEC 2024」のセッション「DBの新トレンド？ リアルタイムサイジング ～ パンドランドにおけるTiDB運用の裏側」で語られました。

セッションには、ワンダープラネット株式会社執行役員 VPoE兼EDMO室長 開哲一（ひらきのりかず）氏とPingCAP株式会社 日下太智（くさかたいち）氏が登壇。

オンランゲームのバックエンドデータベースという環境において、TiDBを用いてスケーラビリティを実現する上での設計のポイント、ローンチ時のトラフィックに無事に対応できたかどうか、課題と解決方法などが率直に語られました。

その内容をダイジェストで紹介しましょう。

シャーディングの課題を解決するためにTiDBを導入

ワンダープラネットはオンラインゲームのバックエンドデータベースにMySQLを採用しています。その上で負荷分散のテクニックとしてデータベースを分割するシャーディングを採用しています。ただしこれまで、シャーディングの設計や運用はすべてマニュアル操作によって行ってきました。

マニュアル操作によるシャーディングは、設計時に慎重なデータベース分割が行われ、アプリケーション側の対応も必要です。また、シャーディングを変更してスケールインやスケールアウトを実行する際には計画的なダウンタイムが必要となります。

同社にとって、こうした煩雑なマニュアル操作やダウンタイムの存在が課題となっていました。その解決策として期待されたのが、MySQL互換でダウンタイムなくスケールイン、スケールアウト可能なリレーショナルデータベースを実現したTiDBでした。

参考：Amazon Auroraのシャーディングによる負荷分散を、スケーラブルなNewSQLデータベース「TiDB」で置き換えへ。高負荷なオンラインゲームにも耐えると評価［PR］

TiDBをスケーラビリティが必要な場所に採用

パンドランドは、ワンダープラネットにとってTiDBを採用する最初のゲームタイトルとなります。同社の開氏は、パンドランドにおいてユーザーデータなど大量の書き込みが発生する、スケーラブルな処理が必要な部分にTiDBを採用したと説明します。

マスターデータに関しては読み込み処理が中心であるためレプリカで容易にスケールできること、データベース内のオブジェクトそのものの構成を変更するDDL（スキーマ変更など）処理がストレージのノードが物理的に分散しているTiDBよりも高速であることなどの理由で、Amazon Aurora MySQLが使われています。

設計や実装で意識したこと

ワンダープラネットの開氏は、TiDBがシャーディングを行う際にプライマリーキーを用いるために、TiDBを用いたデータベースの設計と実装においてはプライマリーキーの作成に気をつけたと説明します。

「プライマリキーが連番で続いていると、データの書き込み時に特定のノードへのアクセスが集中してホットスポット化しやすいので、十分にランダムなものにしなければいけない、という点に気をつけました」（開氏）。

また、スケールインやスケールアウトなど、TiDBのスケールを変更するときに一時的なコネクション断が発生するため、アプリケーション側でコネクション断が発生しても大丈夫なように作っておく点にも注意したとしました。

「弊社ではアプリケーション側でリトライ処理等々を実装していて、これによってダウンタイムがなく、オンラインでポチっとスケールを変更できる、というのを実現しています」（開氏）。

TiDBを実際に導入するときにやったこと

こうしてデータベースの設計やアプリケーションの実装を終え、ワンダープラネットは2024年6月24日、パンドランドのローンチを迎えることになります。

「もちろん事前に負荷試験をして、これぐらいの台数だなという想定をしてはいますが、最初はもう全く負荷が読めないのは皆様ご存知かなと思います。

どれぐらいのキャパで待ち受けるか悩むのですが、TiDBは停止することなくさくっとサイズの変更ができるために大きめのキャパにして待ち構えるのがやりやすくて、今回は想定の負荷の3倍ぐらいの構成で待ち受けました」（開氏）。

ただ、同じキャパシティを構成するにしても、たくさんのノードを並べるのがいいのか、それともスペックの高いノードを少数並べるのかいいのか、PingCAPの日下氏に相談したところ、スペックの高いノードを並べる方が良いとアドバイスをもらったとのことです。

「先ほどプライマリキーのところで書き込みのホットスポットが生じないように、という説明が出てきましたが、これは読み取りにおいても同様です。

特定のノードにのみ負荷が集中してしまう状況は、TiDBなどNewSQLにとってはよりコストパフォーマンス良くDBを利用するうえでボトルネックとなってしまいます。ローンチ前に充分な試験を実施したうえでボトルネックを特定し対策できていれば良いのですが、現実的にはなかなか難しいでしょう。

パンドランドでは、並べるノード数を増やすことで分散具合を多少大きくしておくよりも、事前に把握できなかった特定ノードへの負荷集中に対するリスクヘッジ、という観点で手を打っておいたほうが良いと考えたため、1台あたりのスペックを少し大きめにしましょうとお話ししました」（日下氏）。

思ったよりスケールダウンできず、想定外のコストも……

ローンチ後、多めに設定していたTiDBのキャパシティの縮小は特に問題なく行え、これ自体はTiDBのスケーラブルな機能の恩恵を受けることができてよかったと思うものの、当初の想定とは違う部分もあったと開氏は話ます。

「キャパを縮小する際にノード数を減らすスケールインと、各ノードのサイズを小さくするスケールダウンがありますが、想像よりもスケールダウン、つまりノードサイズの縮小ができなかったこと。もう1つは、データ転送にかかる通信費、トランスファーコストが想定外に高くついたことです。これらについてPingCAPさんに相談しました。」

相談を受けた日下氏が見た状況は次のようなものでした。

「状況を端的に見ていくと、まず（TiDB内部で使われているキーバリューストアである）TiKV（タイケーヴィー）のCPU使用率が全体的に高い。その中でも特定のTiKVノードに負荷が集中していました。

前提として、今回お使いいただいているTiDB Cloud Dedicatedというサービスでは各コンポーネント単位で同一スペックであるという必要があるため、特定のノードに負荷が集中しているとそのノードが性能上のボトルネックになりそれ以上スケールダウンできなくなります。

目的はあくまでもコスト削減であったため、この状況を解決するには特定のTiKVノードの負荷を全体に分散させていく必要がありました。

そこで3つの工夫をしました。1つ目はCached Table（キャッシュドテーブル）、2つ目はFollower Read（フォローワーリード）、3つ目はプライマリーキーやインデックスの最適化です」（日下氏）。

キャッシュドテーブルでホットスポットを解決

キャッシュドテーブルは主にホットスポットの解決のために採用されました。

通常、TiDBではデータはTiKVから読み取られます。キャッシュドテーブルではこれを、コンピュートノードであるTiDBノードから読むようにすることでキャッシュを効かせる機能だと説明されました。

これにより特定のTiKVノードへの負荷軽減が期待できます。ただしこれを使う場合には、テーブルのサイズや更新頻度などの前提条件があるとされました。

キャッシュドテーブルの設定はAlter Tableの実行で簡単にできたと開氏は振り返りました。

トランスファーコストも削減へ

2つ目のフォロワーリードでは、主にトランスファーコストの解決のための工夫です。

TiDBでは、可用性のために複数のアベイラビリティゾーン（AZ）に分散されたTiKVのノードからの読み取りが行われます。前提として、TiKVノードは各アベイラビリティゾーンに分散して配置されており、各々のTiKVノードはデータのレプリカを持っています。

通常の読み取りは、「Leader」として設定されたレプリカを持つTiKVノードから行われます。一方「フォロワーリード」による読み取りでは、Leaderではなく、TiDBノードと同一AZにある「Follower」として設定されたレプリカを持つTiKVノードからデータを読むことができます。これによりAZを超えたコストの高い通信を抑制できるのです。

ただし、フォローリードした場合はレイテンシに影響が出る可能性が高まるため、段階的に設定を進めていくことが適切だとされました。

3つ目のプライマリーキーやインデックスの最適化は、より効率的あるいは高速なクエリの実行のための工夫です。

TiDBはプライマリーキーでデータを検索するのが一番効率がよいため、テーブル設計の時点でどういうクエリが行われるか、主にWhere句の条件を意識してプライマリーキーの設定をしていただくとよい、と日下氏は説明します。

「例えば、ユーザーIDの列と時刻の列を持ったテーブルがあるとして、あるユーザーのデータを時系列の範囲で検索をしたいという要件があったとき、TiDBの仕組みを踏まえるとプライマリーキーをユーザーIDと時刻の列の両方が含まれる複合プライマリーキーとしたほうが全体的に負荷が軽減される、といった提案をさせていただきました」（日下氏）。

ローンチ後の大型イベントも無事に乗り切る

開氏はこうした3つの工夫を行った結果さらなるスケールダウンが可能になり、ノード数はだいたい半分に、データトランスファーコストも約40%削減ができたと話します。

その上で、7月に行われたパンドランドのゲーム内大型イベントにおいても無事に乗り切ったうえで、次のようにTiDBの採用を振り返りました。

「直前にTiDBのキャパを増やしておいて、トラフィックのピークを乗り切ったらダウンスケールでアジャストしていく、みたいなことが以前よりも気楽にやれるようになって、コストのフィッティングという意味では非常に良いと思っていますし、危なくなったらちょっと増やせば乗り切れるので、安心感みたいなところもあるかなと思います」（開氏）。

開氏の話を受けて日下氏も、今回説明したようなノウハウを含めて多くの人にTiDBを使い倒していってほしいと話し、セッションを終えました。

≫TiDB Cloud Dedicated | MySQL互換の分散型データベース | PingCAP株式会社

（本記事はPingCAP Japan提供のタイアップ記事です）