AuroraからTiDBへテンポよく移行　本番移行後のトラブルも“スケール対応”で乗り越えて刷新

課題はコストとシャーディングの運用負荷　6年目を迎える人気ゲームのデータベース刷新へ

　「笑顔あふれるセカイを増やす」というパーパスを掲げ、スマートフォン向けのオンラインゲームの企画、開発・運用をメイン事業としているオルトプラス。同社が運用する人気音楽ゲームは運用6年目を迎え、プロジェクト継続にともないデータベース環境に課題を抱えていた。Amazon Aurora DBクラスターを最大で3台使用していたが、これが運用コストの負担となっていた。

　また、コストだけでなく、運用面では「シャーディング」が運用負荷を増大させていた。Amazon Aurora環境では、ユーザーIDをレンジで分割するレンジ・シャーディングを採用し、3つのクラスターで運用。アクティブユーザーが多いクラスターのリソース使用割合だけが高くなってしまい、リソース使用率にも偏りが生じていた。特にゲームのイベント開催時など、ユーザー流入のコントロールが難しい状況下では、リソースの調整には苦労していたと、オルトプラスの浦谷和茂氏は振り返る。

　一般的にAmazon Auroraはスケールアップを得意とするデータベースであり、シャーディング環境下でのリソース調整は難しく、結果的にシャーディングの管理が複雑化し、運用の手間が増加していた。浦谷氏は、そうした運用環境を「地獄のようだ（笑）」と表現する。

「TiDB Cloud」採用の決め手は？　“徹底検証”した経験を活かす場面も

　実は浦谷氏、これまでゲームの開発・運用など、多数のプロジェクトに携わってきた経験をもつ人物。特にデータベースの構築に数多く関わり、TiDBを“徹底検証”した経験をもつなど、TiDBの優位性はよく理解していた。

　「（TiDBは）書き込みのスケールアウトが可能な分散データベースとして評価できる」と浦谷氏。オルトプラスに入社した当初から、既存のデータベース環境の課題をTiDBなら解決できると考えていたという。

　今回、6年目を迎える人気タイトルにTiDBを推進した最大の理由は、TiDBによるデータと負荷の自動分散、つまり「シャーディングが不要になる」点だ。これにより単一クラスターでの運用が可能となり、リソースの調整が柔軟に行えるようになる。浦谷氏は、TiDBによりコスト削減と同時にシャーディングの問題が解決できると考えたのだ。

　また、TiDBを選択したもう一つの決め手が「MySQLとの高い互換性」だった。NewSQLデータベースにはPostgreSQL互換のものが多い中、TiDBはMySQLとの互換性が高い。特にゲーム業界ではMySQLが浸透しており、既存の知識やツールを活かしやすく、「互換性の高さを考えるとTiDB一択でした」と浦谷氏は振り返る。

　もちろん、互換性が高いとは言っても完全に同じものではない。そこで移行前には、互換性の検証を重点的に実施。「APIコールで正しく実行されるのか」「通常のMySQLと同じ動きをするのか」といった点にフォーカスした一方、性能やアーキテクチャに関する検証は行っていない。これは先述したように浦谷氏がTiDBのアーキテクチャやパフォーマンスを把握しており、これまでの経験から十分に担保できると確信していたからだ。

　また、TiDBと一口に言っても、セルフマネージド型とフルマネージド型の「TiDB Cloud」がある。移行にあたっては、後者を採用することで運用負荷を軽減できることも、TiDBへの移行を決断する判断材料となった。「TiDB Cloudは、クラスター全般の管理を行う『PD（Placement Driver）』がPingCAPの管理下にあるため、運用側は『TiDB』と『TiKV』の運用に注力できる」と浦谷氏。インターフェースは極めてシンプルかつ直感的なため、引き継ぎなども容易に行える。

　加えて、柔軟なスケールアウト／スケールアップが可能であり、パフォーマンスや安定性が求められる本番環境での利用に最適だと判断した。

「切り戻しはしない」覚悟──本番移行の裏側

　本番環境への移行は、通常のメンテナンス作業のために用意されている6時間以内に実施する必要があった。そこで時間を計測しながらリハーサルを繰り返し、6時間以内に収まる見通しが立った上で移行作業を実施。移行ツールとして、Amazon AuroraからのエクスポートにはTiDBの公式ツール「Dumpling」、TiDB CloudへのインポートにはTiDB Cloudコンソールのインポート機能、データの整合性チェックには（データとスキーマの差分を比較・検出する）「sync-diff-inspector」を採用している。

　当初は無停止移行のための「DM（Data Migration）」や切り戻しを想定した「TiCDC（Change Data Capture）」の利用も検討したが、十分なメンテナンス時間を確保できたこと、最終的に「Amazon Auroraへの切り戻しは行わない」方針としたため、これらの利用は見送られた。

　この「切り戻しは行わない」という方針は、「問題が生じても、その先の面倒は何があっても自分が見る」という、浦谷氏のTiDBへの信頼と経験に裏打ちされたものだ。

　もし、何かあった際に切り戻しをすることを前提とすれば、切り戻しのための準備が必要になるだけでなく、システム構成が複雑化することで移行の成功率も下げてしまうリスクがある。だからこそ浦谷氏は、シンプルに移行したほうが成功率は上がると考えた。

予測不能な「ドタバタ劇」とTiDBの柔軟性　緊急対応から得た教訓

　実際の本番移行は入念なリハーサルの成果もあり、スムーズに進んだものの移行直後に予測困難なトラブルが発生した。

　メンテナンス明けから10分後、社内から「エラーが多い」「アプリが重い」といった声が上がり、ユーザーからも通信エラーの問い合わせが殺到。すぐにメトリクスを確認すると、TiKVのCPUリソースが急激に消費されていることが確認できた。

　このときゲーム内のプレゼント機能におけるスキャン処理がボトルネックとなり、Amazon EBS（Elastic Block Store）のIOPS上限に張りついた状態となっていた。負荷試験時、本番よりも少ない件数で検証していたため、ボトルネックに気づけなかったのだ。

　そこで浦谷氏は、TiDBがノーメンテナンスでTiKVのスケールアウトができることを知っていたため、即座にスケールアウトを実行。これによりAmazon EBSの負荷が分散され、問題は即座に解決された。この経験を通じ、TiDBの柔軟なスケーリングがサービス継続の安心感を支えていることを再認識したという。

　TiDBの移行翌日にも、もう一つトラブルに遭遇している。それはコスト削減を追求するあまり、計画になかったTiKVのスケールイン操作を実施したことに起因するものだ。リソースが使われていない日中の時間帯に、「コストカットを図り、TiDBの性能を発揮しよう」と考えた浦谷氏は、午後にTiKVを9台から3台へ一気にスケールインする操作を実施した。

　しかし、スケールインの処理がユーザー流入前のピークタイムまでに完了しないことが判明。 リージョンの移動をともなうスケールインは時間が必要なため、一気に台数を減らしたことが裏目に出たのだ。この状況に直面した浦谷氏は「（あまりの焦りに）震えが止まらなかった」と振り返る。そこで浦谷氏がヘルプを要請したのは、PingCAPのサポートチームだ。

　PingCAPは、進行しているリージョンの移動をともなう、“スケールインの中断”という技術的に困難な対応を即座に実施。一時的にリバランスは不完全な状態となったものの、ユーザー流入のピークタイムを無事乗り切ることができた。

　浦谷氏は、このトラブルの発生から解決に至るまでの経験を通じて、ベンダーサポートの重要性をあらためて実感したという。緊急時に相談できる相手がいることは運用上のリスクを大きく減らす要素である。そして、PingCAPのレスポンスの速さと正確さは「極めて心強い」と評価する。

　なお、この経験は浦谷氏個人の教訓としても、「計画していないことを本番環境で実行しない」「必ずリハーサルで計測・確認した上で実施する」という基本を強く再認識する機会にもなったという。

コスト削減と運用自動化を実現　TiDBが「デフォルトDB」となる未来予想図

　オルトプラスではTiDBへの移行プロジェクトを経て、最大の目的であったコスト削減と運用負荷の軽減を無事達成している。2月から10月までの8ヵ月の期間において、約30%のコスト削減につながった。

　特にソーシャルゲームのトラフィックには波があるため、TiDBの柔軟なスケーリング機能を利用し、ピーク時には十分なリソースを利用しつつ、利用が少ない時間帯にコストを抑える運用が効果を発揮しているとする。

　また、運用負荷も大幅に軽減された。TiDB Cloudのマネージドサービスとしての利便性に加え、TiDB Cloud API（v1 Beta）を活用することで、コンソールを介さずにクラスターのスケーリング操作をコード（Python）で実行する自動化も実現した。

　現在は、アクティブユーザーの流入にあわせてスケールアウトし、その後スケールインするような運用をスケジューラーで自動実行している。これにより運用負荷は軽減され、運用コストの面では「現在考え得る理想に近い状態」にあると浦谷氏。シャーディング管理の手間がなくなったことも、運用の効率化に大きく貢献しているとして、この移行プロジェクトは、コスト削減と運用負荷の軽減の両面での成功事例であると位置づけた。

　今回の成功事例を踏まえ、オルトプラスはTiDBをデフォルトのデータベースとして運用していく方針だ。他のゲームタイトルに適用可能なものがあれば、積極的に活用していくとする。

　また、TiDBへの移行を牽引した浦谷氏は、TiDBの導入事例や魅力を積極的に発信し、イベント登壇やエンジニアブログなどを通じて、TiDBユーザーグループ（TiUG）などコミュニティの拡大にも貢献していく考えだ。グローバルで展開されているTiDBチャンピオンプログラムへの貢献も視野に入れ、TiDBの発展に寄与したいという。

　今回のTiDBへの移行は、コスト削減と運用負荷軽減というビジネス的な目的から始まりつつ、Amazon Auroraのシャーディングにおける構造的な課題をTiDBのアーキテクチャで根本的に解決した好事例だ。

　移行直後のトラブル対応では、TiDBの柔軟なスケーラビリティがサービス継続に直結することを実証し、さらにPingCAPの迅速なサポートが運用の安心感を支える重要な要素であることを再認識させた。同社のデフォルトのデータベースとして、今後のサービス継続性と拡張性を支えていくことがTiDBには期待される。