MySQL互換で簡単に拡張可能なTiDB Cloudとは。CEDECの講演内容を振り返る

[2022/10/03 12:00]

　8月23日から25日まで開催された日本最大のゲーム開発者会議「CEDEC 2022」では，数多くのゲーム関連セッションが行われたが，ここではTiDB Cloud関連のセッションについて紹介する。講演タイトルは「ゲーム業界で採用されているMySQL互換フルマネージメントサービスのNewSQLデータベース『TiDB Cloud』」で，登壇者はPingCAP シニアソリューションアーキテクトの水戸部章生氏だ。

　TiDBは「タイデービー」と読む。Tiはチタニウムの意らしいのだが，英語だと「タイテイニアム」みたいに読まれるので「タイ」の読みとなる。イメージキャラクターは鯛だそうだ。

　そのTiDB Cloudは何かと言うと，PingCAPが開発した「MySQL互換のフルマネージドなクラウドデータベース」である。
　MySQLは，いまや最もポピュラーなデータベース（以下DB）ソフトなのであまり説明はいらないだろう。そのMySQLを使うのと同じ感じで扱えるという意味だ。

PingCAP シニアソリューションアーキテクト水戸部章生氏

　「フルマネージド」というのは，サーバーの管理からサービスに至るまでまとめてやってくれる体制のことで，DBを構築して使うだけで，あとのことはすべてお任せにできる。
　クラウドは単一サーバーではなく，複数のサーバーをまとめて運用する技術であり，負荷に応じて規模を変更できるような仕組みであり，DBでそれを行うわけだ。

　ということで，「簡単に負荷分散可能だけどMySQL使うのと同じ手間で済むDBがあるぞ」ということが分かれば，8割方説明は終わったようなものだ。

　Free to Playのモバイルゲームなどでは，同時接続ユーザー数の推定が困難だ。よく分からないところでバズって想定以上にプレイヤーが集まってしまった場合，サーバーの負荷が許容範囲を超える可能性はある。とくにDBは要注意だろう。TiDB Cloudはそんな懸念を吹き飛ばしてくれるかもしれない新世代のDBサービスなのだ。

　講演は（当然ながら）DBを使うような人向けに行われていたので，実際の内容を紹介する前に簡単に基礎的なところをまとめておきたい。

　さて，DBは使うと便利だが，それなりに負荷の高い処理でもあり，DBの負荷分散というと別に今に始まったものではなく，かなり以前から問題にはなっていた。対応としてはいくつかの段階がある。

1. 単体DBの性能を上げる
　DBが重かったら，工夫して性能を上げる方向がまずある。

DBをきちんと正規化・最適化しろ
無駄なトランザクションを送るな
キャッシュを使え

今までは上記のようなところに落ち着いていたと思う。CPUやストレージといったハードウェアの高速化もこの部類に入る。どうしてもレスポンス遅れが許されない場合はオンメモリモードを使えといった，単一のDBサーバーでのトランザクション性能を上げていく方法が最初にあった。

2. レプリケーションを作る
　抜本的な負荷分散としてレプリケーションを作る（DBを丸ごと複製する）方向もある。
　DBのレプリケーションを作る場合は中身を丸ごとコピーした読み出し用のDBを多数用意して，主に読み出し処理を分散していく。ほとんどのWebアプリでは書き込みより読み込みのほうがはるかに多かったので，読み出しを並列化し，書き込みはマスターDBに対してのみ行われる方式が多かった。こういった管理をDBの垂直分割という。
　垂直分割の場合，DB全体が多重化されているのでマスターDBが飛んだとしても，ほかのDBをマスターとしてすぐに立て直すことができる。

3. DBを水平分割する
　垂直分割ではマスターDBへの書き込みがネックになり，書き込みが多いサービスでは最悪，機能停止してしまうこともある。そしてゲームは書き込みが多いサービスだ。
　DBを丸ごとコピーしてマスターDBの分身を作っていくのではなく，DBのテーブルごとに分けるなどで，すべてのDBで書き込みも行っていくような分割方法もある。これは水平分割と呼ばれる。すべてがマスターDBでもあるマルチマスター方式だ。
　水平分割ではサーバーごとにデータが重複しないようにテーブルを分割する手法（シャーディング）や多少重複するフレキシブルなやり方などがある。
　書き込みがそれぞれで行われると，同期のタイミング次第ではデータに不整合が起きることも考えられる。どれかのDBが落ちてしまうとデータの整合性も取れなくなる。それぞれの処理は正しく行われていても，全体として見ると一貫性に問題が出る可能性は残ってしまうのだ。そのためデータの一貫性を保つための処理が必要になるのだが，それはDBの外（アプリ側）で実装しなければならない。
　なお，水平分割と垂直分割は同時に行うことも可能だ。

4. NoSQLを使う
　少ししてNoSQLという概念が出てきた。これはクラスター化を前提にしたような非リレーショナルDBで，MongoDBとかCassandraなどの製品がある。
　また，キーとなる識別子と値をセットで扱うことで（識別子を指定すると値が返ってくる）非常に単純なDBを構築する手法をKVS（Key Value Store）と呼んでおり，これもSQLを使わない方式である。
　これらの手法ではSQLを使った複雑な検索などはできないが，単純なデータアクセスなら非常に高速に行え，リニアに水平拡張しやすいDBとなっている。性能や拡張性などがオンラインゲーム向きであることから，ゲーム業界でも比較的使われているDBだろう。
　これらは水平拡張しやすい半面，データの整合性は保証されておらず，整合性を取るための処理はアプリ側で行う必要がある。単にデータの読み書き以外の処理がゲーム側で必須になっている。

ゲーム開発でのDBの課題

　オンラインゲームで許容量以上のアクセスがくるとどうなってしまうのか，どのように対処すればいいのか？　過去にコナミデジタルエンタテインメントでリードプログラマをやっていたという水戸部氏は，自身の経験からDBの負荷対策の難しさを語っていた。
　サービスで想定以上のユーザーが集まってしまったため，DBが応答しなくなりサービス停止になってしまったのだという。アプリについては比較的簡単に負荷分散できたものの，DBについてはかなり苦戦し，大量のシャーディングを行うことでようやく対応を終えている。

　処理としては，DBをユーザー単位で水平分割し，アイテム単位で垂直分割するというものだった。これに伴い，アプリ側でも水平垂直分割用のクラスを作成し，テーブルをまたぐ結合処理に改修が必要になったという。

　さらに，DBサーバーを細かく分けたことで，トランザクションでのデータロストの危険が発生してしまったこと，負荷の調整がしにくくなったこと，ゲームの分析が1クエリではできなくなったなど，副次的な問題が発生してしまったそうだ。

　DBが止まることで（ユーザーが集まっている時期に）サービスが停止し，大きな機会損失となったほか，DBのスケーリングがアプリ本体にまで影響してゲームプログラマの手を煩わせることになった。これも，プログラマのリソースをゲーム本体に集中させたい会社としては，損失と言えるだろう。

NewSQL（TiDB Cloud）を使う

　前述の諸方式に対して，TiDBはNewSQLと呼ばれる種類のDBだと水戸部氏は説明していた。
　前述のようにNoSQLは優れた面もあるのだが，簡単に水平拡張できる半面，管理が緩く，データの一貫性は保証されない。それを嫌うとゲーム側で実装しなければならないものも多く，NoSQLに移行したものの管理が面倒でMySQLに戻したといった要望が出てくる事例も多いのだという。

　TiDB Cloudでは，NoSQLのようなシャーディングを使用することでデータの書き込み速度を上げるとともに，DB側でデータの一貫性を保証する仕組みを取り込むことで余計な手間をかけずに使えるようになっている。また，フロントエンドはMySQL互換であり，複雑なSQLを使った検索も実行できる。

　こういった特徴を持つTiDB Cloudは3つのレイヤーで構成されている。表層となるのはSQL解析レイヤーで，TiDB Cloudで「TiDB」と呼ばれている部分は，実はMySQL互換のSQLを解析してKVSでアクセスできるようにする役目を果たしている。

　データの管理自体はデータストアレイヤーとなるTiKV（Key Value）が行っており，基本的にKVSでデータを管理している。SQLをそのまま実行することはできないが，簡単な検索などは解析レイヤーではなくデータストアレイヤーに処理がオフロードされるので，分散によって効率を上げることができる。その際には最大256キーをまとめてバッチ処理するので，ネットワーク負荷の軽減と書き込みの高速化が図られている。

　これらをつなぐデータベースの構成や管理部分がTiDBの心臓部といえる部分であり，管理レイヤーはPD（Placement Driver）Clusterで管理されている。TiKVからは定期的に情報が送られてきており，その状況によってノードを分割したり，統合したりといった処理や，スケジュール管理を自動で行ってくれる。クエリ情報などもここで収集されている。
　データベースの分散にはRaftというアルゴリズムが使用されているが，これはNewSQLでは定番となっているものだ。

　1つのPD Clusterは3ノードの冗長構成となっており，データの信頼性を高められている。2つのバックアップを備えたストレージだが，圧縮が行われているので，通常のMySQLのデータと比較してもサイズは同等なのだという。

　このような構成で分散処理を行うTiDB Cloudの性能は，理論上，秒間300万～400万クエリを処理可能だという（水戸部氏の検証では100万クエリくらいが現実的のようだ）。容量は無限大だが，実用上は600TBくらいまでは性能を維持したまま拡張できるとのこと。

　TiDB Cloudの特徴の一つにノーメンテ運用がある。つまり，ゲームのアップデートなどでもサービスを停止する必要はない。アップデートが公平に公開されないのも問題なので普通は止めると思うが，やろうと思えばそういうこともできるわけだ。こういったノーメンテの連続運用が可能で大量の処理も高信頼性を保ったまま実行できるということで，ゲーム以外での活用も行われている。東京ゲームショウ2022の会場で聞いた話では，PayPayのバックエンドはTiDBが使われているのだそうだ。

　これらの基本コンポーネントにプラスしてTiFLASH Clusterというものを追加すると，1コマンドでクラスターを同期してくれて，分析クエリを高速で処理できるようになる。MySQLでは集計に5分ほどかかっていた大容量データがTiFLASHを使うことで，1秒未満で集計できるようになるのだそうだ。

　TiDB Cloudはマルチプラットフォームに対応しており，現状ではAmazon Web Services，Google Cloud Platformに対応している。Azureへの対応は2024年に行われる予定だという。AWSからGCPに移るかといった場合でも，プラットフォームに依存する部分がない。
　また，「外部クラウドはちょっと……」という場合でも，オンプレミス環境で構築することも可能となっている。さらには，開発環境として，PC上でクラスタを使わない構成で立ち上げることもできるそうだ。

　ということで，これまでのDBの問題点をほとんど潰したようなDBとなっているわけで，ゲームでの活用も期待できる。ただ，複雑なSQLの解析などを含んだクラウドということで，一般のDBだと数msの処理がレスポンスには16～20msかかるということで，超高速なゲームには向かない（DBを多用しているとは思えないが）。とはいえ，モバイルのオンラインゲームであれば，通信遅延のバラツキで隠蔽されるレベルであり，そういったゲームにはとくにむいているDBではありそうだ。

　なお，その実力と将来性によってか，最近，MySQLのInnoDBのR&DヘッドであったSunny Brains氏がPingCAPに合流してきたそうで，今後はTiDBのさらなる発展も期待される。

　プログラム上はDB周りの処理はMySQLとまったく同一で大丈夫であり，どんなに人が来てもDBで落ちることはない環境は誰しも求めるものだろう。小規模なところでは，フルマネージドサービスの提供によってDBの運用からも解放されるというのも魅力的に思えるかもしれない。水戸部氏は，サポートがすべて日本語でOKな点もメリットとしてアピールしていた。