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

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

関連ワード（下記、多数、限界等）についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

複数のデータベースに負荷分散を行い、スケーラビリティを高める代表的な方法の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の採用ハードルが下がったとも話しました。