はじめに
合同会社Re:versionは、Play by Web（PBW）と呼ばれるオンラインロールプレイングゲームのプラットフォームを運営しています。PBWとは、プレイヤーがテキストや画像でキャラクターを表現しながら、Web上でゲームの物語を進めていくスタイルのゲームで、根強いファンを持つジャンルです。
私たちが運営する Lost Arcadia ではゲームの核となるコンテンツを提供するクリエイターの方々が活躍しています。クリエイターはゲームシステムとは独立したシステムで募集、実技審査しています。これまでは小規模なVPS1台でシンプルに運用していましたが、10年以上塩漬け構成でそろそろマイグレーションが必要な状況でした。
本記事では、このシステムをServerless Framework+TiDB Cloudを用いてモダナイズした際の経緯や、TiDB Cloud Starterを採用した理由、実際に使ってみた評価などを紹介します。
以前の構成と課題
以前の構成は以下のようなシンプルなLAMPでした：
- サーバー: VPS 1台
- アプリケーション: PHP Laravelアプリケーション
- データベース: MySQL（VPS上に直接インストール）
- アップロードファイル: VPS上のファイルシステムに配置
- デプロイ: 手動SSH+git pull
この構成自体は安価に必要十分なシステム運用を行えるのですが、遥か昔にEoLしたOS/ミドルウェアに目をつぶっている状況であり、継続運用性に難がありました。
新しいアーキテクチャ
今回のモダナイズでは、Serverless Frameworkを採用し、フルサーバレスアーキテクチャへ移行しました。データベースにはTiDB Cloud Starterを採用しています。
システム全体のアーキテクチャ図
構成の要点は以下のとおりです。
- バックエンド
- PHP/LaravelをLambda関数のBref（PHP Lambda Runtime）上で実行。
- MySQLプロトコルでTiDB Cloudに接続。
- フロントエンド
- CloudFront+S3で静的ホスティング。
- LaravelアプリケーションへのリクエストのみLambdaへ転送。
- データ移行
- 既存MySQLからCSVをエクスポートし、Amazon S3へアップロード。
- TiDB CloudのデータインポートUI経由でインポート。
- スキーマ管理はLaravelのマイグレーションをそのまま適用。
- ※移行用リソースは図上には未記載
TiDB Cloud Starterを選んだ理由
データベース選定にあたり、主に以下の観点を重視しました。
MySQL互換の完全従量課金サーバレスDB
最大の採用理由は、MySQL互換の完全従量課金サーバレスデータベースという組み合わせです。既存のコードがLaravel（MySQL向け）で書かれていたため、MySQL互換性は必須要件でした。一方、サーバレスアーキテクチャに合わせて、使った分だけ課金されるモデルが求められていました。
AWSにも類似サービスとしてAmazon Aurora Serverless v2がありますが、Aurora Serverless v2は「専有リソースをオートスケールする」仕組みであり「共有リソースの完全従量課金」とは性質が根本的に異なります。アイドル状態でも最低限のACU（Aurora Capacity Units）分のコストが発生するため、アクセスが少ない時間帯のランニングコストが相対的に高くなります。
TiDB Cloud Starterは共有インフラ上での完全従量課金型で、アイドル時のコストが大幅に抑えられます。PBWのようにアクセスが不規則・時間帯によって大きく変動するサービスに適していると判断しました。
比較すると、以下の違いがあります。
- Aurora Serverless v2
- 専有リソースのオートスケール。
- アイドル時でも最低ACU分のコストが発生。
- TiDB Cloud Starter
- 共有インフラ上の完全従量課金。
- アイドル時コストを大幅に抑制可能。
無料枠の充実
また、TiDB Cloud Starterには無料枠が用意されており、小規模なサービスであればほぼ無償で利用できます。スタートアップや小規模システムにとって非常に入りやすいプランで、まず試してみるハードルが低い点も選定理由の一つです。
Auroraの場合の参考（2026-03時点の概算、コンピューティングのみ）:
- Aurora Serverless v2を最小規模で常時動作: 月間最低$55程度
- オンデマンドのt3.small: 月間$45程度
MySQLからの移行のしやすさ
既存のLaravelアプリケーションとの親和性が高く、接続先をTiDB Cloudのエンドポイントに変更するだけで動作しました。MySQLドライバーをそのまま利用できるため、コードの修正は最小限で済みます。小規模なサービスではありますが、互換性の問題は発生していません。
実際に利用して感じたTiDB Cloudの評価ポイント
管理コンソールの充実
TiDB Cloudの管理コンソールには、運用に必要な基本的なツールが一通り揃っています。
- データインポート機能が便利
- Amazon S3に配置したCSVファイルをGUIでインポート可能。
- 既存データの移行がスムーズで、今回の移行ではデータ移行スクリプトを書かずに完了できました。
- 設定不備が起きやすいIAMロール/ポリシー向けに、CloudFormationテンプレートが用意されています。
- インポート画面から直接適用できるため、運用設計がよく考えられていると感じました。
- クラスタ接続の案内が分かりやすい
- 管理画面上で必要な情報や設定手順が自然に案内され、接続時の迷いが少ないです。
- Webコンソールのクエリエディタが実用的
- 小規模システム・小規模チームでは、運用中DBを直接参照/編集する場面があります。
- 以前はVPS上でphpMyAdminを同居運用していましたが、当面はこのクエリエディタで運用予定です。
- メトリクス/モニタリング機能が標準で充実
- CPU使用率・接続数・スループット・レイテンシなどの基本メトリクスを標準提供。
- スロークエリに加え、発行クエリごとの統計情報も確認でき、性能チューニング時にRUやレイテンシの把握に活用できます。
- 追加コストなしで使える点が助かる
- これらが無料で標準提供されるのは大きな利点です。
- Aurora for MySQLで同等のモニタリングを行う場合、Database Insightsに相当な課金が発生します。
スパイクトラフィックへの耐性
TiDB Cloud Starterは巨大なTiDBクラスタの一部を共有するアーキテクチャで動作しており、トラフィックのスパイクに対してリニアなスケールが期待できます。
この点を評価している背景は以下のとおりです。
- PBWサービスでは、シナリオ更新やキャンペーン期間中にアクセスが急増することがある。
- TiDB CloudはHTTP型サービスのスパイクに対応できるDB側キャパシティを持つと想定している。
- 募集サイトでは懸念は小さいが、PBWサービス本体への適用を検討する価値がある。
マネージドサービスとしての安心感
小規模チームで運用しているため、DB運用管理に工数をかけにくい状況では、次のような自動化の恩恵が非常に大きいです。
- バックアップ
- セキュリティパッチ適用
- 可用性の確保
感じた課題と今後TiDB Cloudに期待すること
IaC（Infrastructure as Code）サポートの充実を期待
現在、最も強く改善を期待している点はIaCサポートの充実です。TiDB CloudにはAPIとTerraformプロバイダーが提供されていますが、現時点では対応されているリソースが限定的に感じています。
今回のプロジェクトでは、以下のような状態になりました。
- TiDB Cloudのクラスタ設定は全般に手動で実施（IaC管理外）。
- AWS側リソース（Lambda、API Gateway、S3など）はServerless Frameworkでコード管理。
- 結果として、TiDB Cloud側だけが「手動管理」となり、一貫性の観点で課題が残る。
今後は、TerraformプロバイダーでTiDB Cloud上のリソースをより広くサポートし、ネットワーク設定等を含めてIaC管理できるようになることを期待しています。
まとめ
今回のプロジェクトの要点は次のとおりです。
- VPS1台で動かしていたクリエイター募集サイトを、Serverless Framework+TiDB Cloud Starterのフルサーバレス構成へモダナイズ。
- TiDB Cloud Starterは、MySQL互換の完全従量課金サーバレスDBというニッチを埋める選択肢。
- AWSサーバレス構成と組み合わせることで、Aurora Serverless v2では実現しにくい「真のアイドル時ゼロコスト」に近い運用が可能。
- 管理コンソールも充実しており、マネージドDBとしての移行・運用体験は良好。
- IaC対応の充実には改善余地があるものの、小規模〜中規模サービスでは十分実用的。
特に、不規則なアクセスパターンを持つサービスや、コストを抑えながらスケーラビリティを確保したいケースでは、有力な選択肢として検討できます。
※本記事は広告・PRを目的として作成されたものです。