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

複数のデータベースに負荷分散を行い、スケーラビリティを高める代表的な方法の1つに「シャーディング」があります。

シャーディングによる分散処理には、例えばあるテーブルのプライマリキーが偶数の値はサーバAに、奇数はサーバBに分散させるような方法（水平分割）、あるいは「商品名」「価格」「在庫数」「画像へのリンク」の4列を持つテーブルを、「商品名」「価格」と「在庫数」「画像へのリンク」の2列ごとのテーブルに分割して別々のサーバに受け持たせる方法（垂直分割）などがあります。

『週刊少年ジャンプ』の創刊50周年を記念して製作されたゲーム「ジャンプチ ヒーローズ」やパズルRPG「クラッシュフィーバー」「アリスフィクション」をはじめとする人気ゲームの開発や運用を行うワンダープラネット社も、大規模なトラフィックが集中するオンラインゲームのバックエンドデータベースを実現するために、シャーディングを用いてきました。

例えば同社が運用するあるオンラインゲームのバックエンドは、複数台のAmazon Aurora MySQLサーバを用いてシャーディングによる分散処理をし、それぞれのサーバがリードレプリカを持つことで、全体として多数のサーバを稼働させています。

ただしシャーディングには、適切なデータの分割の設計が難しく、アプリケーションのロジックがシャーディング後のデータベースの構造に依存するため複雑になったり、データが複数のシャードに分散するため集計が難しくなるなどのデメリットがあります。

また、シャーディングによって分散させるデータベースサーバの台数の増減はデータベースの分割や統合、データの移動があることから計画も入念に行う必要があり、変更時にはデータベースサーバの計画停止が伴うなど、運用上の難しさもあります。

ワンダープラネットも、まさにそうしたシャーディングの課題に直面していました。

アプリケーション開発とデータベース運用の複雑さが課題に

同社CTOの吉谷幹人氏は、シャーディングによる複雑さが悩みだったと次のように話します。

「シャーディングの複雑さは以前から悩みでした。どのサーバにリクエストを投げなくてはいけないかをアプリケーション側で把握しておかなくてはいけないので、アプリケーションが複雑になるだけでなく、アプリケーションとデータベースが容易に切り離せなくなっているなど、シャーディングを採用することで開発の難易度が上がっています。

データベースの保守性も下がってしまいます。例えば、1台のサーバに障害があってもシステム障害になりやすいですし、サーバ台数の縮小にも限界があるため、本当なら1台のサーバだけで対応できる負荷であっても複数台で動かさなくてはならないこともあり、費用がかさみます」。

また、これまでの課題を次のように指摘します。「弊社にとって、新しいゲームを開発することは新しいビジネスを作り込んでいくようなものです。本来は、面白いゲームを届けることに開発を集中させたいのですが、新しいゲームを立ち上げるたびにどのくらいの負荷が予想されて、どうシャーディングするかなども考えなくてはなりません。

できれば、そういうことを気にせずゲームの開発に集中できるようなソリューションが欲しいと思っていました」。

下記はシャーディングを用いて多数のAmazon Aurora MySQLのデータベースサーバを運用しているシステムの例です。これらのサーバにどのようにデータを分散配置するべきか、シャーディングの設計を行い、アプリケーションはそれを意識した開発をしなければなりません。

同社はこうしたシャーディングの課題を解決するべく、AWSのNoSQLデータベースであるDynamoDBやGoogle Cloudの分散データベースCloud Spannerなども検討しましたが、同社が期待するようなソリューションではなかったとのことでした。

シャーディング機構を内部に備えたTiDB

そうしたソリューションを模索しているなかで、2022年夏頃に同社執行役員VPoEの開哲一氏が「TiDB」の情報を知ります。

TiDBは、いわゆる「NewSQL」と呼ばれる、新たに登場したスケーラブルなリレーショナルデータベースの一種です。

TiDBはデータベースエンジン内部にシャーディング機構による分散データベース機能が備わっており、ノードを増やすことで性能が向上するスケーラビリティを備えているのが最大の特徴です。その上でMySQL互換のインターフェイスを備えており、一部の例外を除いて従来のMySQLアプリケーションはそのまま動作します。

つまりTiDBではユーザー自身がシャーディングをしなくともスケーラブルなデータベースが実現でき、しかもMySQLと同様のクエリをそのまま実行できる特長を備えています。

開氏はこうしたNewSQLの特長を持つTiDBが、同社が抱えるシャーディングについての課題を解決するのではないかと考え、開発元であるPingCAPに問い合わせ、詳しい説明を受けることにしました。

「説明を受けて、これは使えそうだなと思いました」と開氏。CTOの吉谷氏も「ちょうど次のゲーム開発の負荷をどうするかという問題に当たっていたタイミングでもありました。新規開発ごとに何らかのレベルアップしたいなと考えていたなかで、ではTiDBを検討してみよう、となりました」と、両者ともにTiDBの導入について前向きになったと当時を振り返ります。

無停止でのスケールアップ・ダウンを確認。互換性も問題なし

2022年秋にはTiDBの評価試験を開始。数カ月をかけてスケーラビリティや互換性などを中心に評価を行い、次のような結論を下します。

「スケーラビリティの面では、無停止でのスケールアップ、スケールダウンなどを試しました。TiDBは無停止でできることを確認できて、これまでのシャーディングでの課題は解消できそうです。

MySQLとの互換性の面では、これまでAmazon Aurora MySQLのデータベースをそのままTiDBに載せ替えてもそのまま同じSQLが使えたので、十分な互換性があると評価しました」（吉谷氏）。

また試験環境において、Amazon Aurora MySQLからTiDBへ載せ替えたデータベースをダンプし、再びAmazon Aurora MySQLへ簡単にリストアできることも確認できたため、万が一TiDBへの移行後に何らかの問題が発覚したとしても、すぐにAmazon Aurora MySQLへの運用に戻せるという安心感から、TiDBの採用ハードルが下がったとも話しました。

TiDBの導入でシャーディングが不要に

これらの評価結果を踏まえ、同社はTiDBの採用を決定。現在開発が進められているタイトルのバックエンドデータベースとして、AWS上のマネージドサービス「TiDB Dedicated」がすでに導入されています。

TiDB Dedicatedの導入によりシャーディングは不要となり、システム構成は下図のように単一のTiDB Dedicatedが配置されます。負荷の変動時もTiDB Dedicatedによりスケールアウト・イン（アップ・ダウン）がダウンタイムなく行えるため、計画停止が不要となりました。

執行役員VPoEの開氏は、これでアプリケーション側がシャーディングを意識する必要がなくなり「開発現場がめちゃくちゃ楽になった」と導入の効果を話します。

「（ロジックで）リードとライトの向きを考えなくてもよくなるので、アプリケーション側でそういったミスがなくなるのは大きい」と評価。

CTOの吉谷氏も、TiDB Dedicatedの導入によって面白いゲームの開発に集中できる環境が実現できていると感じていると話します。

TiDB Dedicatedの導入によってこれまで解決できなかった課題を解決できるようになったワンダープラネット。同社はこれまでよりさらに豊かで楽しめるオンラインゲームを多くのユーザーに届けるようになることでしょう。

≫PingCAP株式会社 - TiDB Cloud

（本記事はPingCAP株式会社提供のタイアップ記事です）