Webサービス運用において、データベースの負荷対策は永遠の課題の一つです。 はてなで運用しているマンガビューワGigaViewerでは、特定の時間に極端にアクセス負荷が高まる傾向があります*1。 特に書き込み負荷のスパイクは、一般的なRDBMSの構成ではスケールアップの限界に直面しやすいポイントです。
といった背景があり、将来的な超高負荷時に備えた「技術的な手札」を増やすため、分散型SQLデータベース（NewSQL）サービスとして注目されている TiDB Cloud の検証を行いました。
本記事では、普段 Aurora for MySQL をメインで使用しているサービスチームが、どのような検証を行い、どのようなパフォーマンスの実測値や運用上の気づきを得られたかについて共有します。
この記事は 
id:koudenpa が主にGeminiと相談しつつ書きました。
「そう言えば」TiDB Cloudを検証「していた」話、というそこそこ過去形な記事タイトルなのは、検証自体は2025年上旬に実施していたからです！
検証の背景と「低労力」戦略
今回の検証では、既存の開発・テスト資産を最大限流用することで、コストを抑えつつ実効性の高い検証を行うことを重視しました。
なぜTiDB Cloudか？
NewSQLにはいくつかの選択肢がありますが、以下の2点を理由にTiDB Cloudをターゲットとしました。
- MySQL互換であること
- 現在Aurora for MySQLで運用しているアプリケーション資産との親和性が必須要件でした。
- TiDBにはMySQL互換があります。
- フルマネージドであること
- 運用工数をAuroraと同程度に抑えるため、インフラ管理の手間が少ないことが望ましいためです。
- TiDB CloudはPingCAPがTiDBをフルマネージドで提供するDBaaSです。
プレビュー環境の流用
負荷検証前の動作確認には、GigaViewerの開発フローですでに導入していた「Pull Requestごとに独立したプレビュー環境が立ち上がる仕組み」を流用しました。
社内の mirage-ecs によるコンテナベースの環境構築基盤を活用し、DB接続先の設定をTiDB Cloudに向けるだけで、アプリケーションが動作する環境を即座に用意することができました。
このプレビュー環境を用いて、まずは大まかな疎通確認とMySQL非互換部分の修正を行い、本命の負荷検証に備えました。
この際にはServerlessクラスタ（現在はStarter）を用いることで、TiDB Cloudのコストも節約できました。
負荷試験資産の流用
負荷検証には既存の環境とシナリオを流用しました。
過去のリプレイスやその後の構成変更の際に「本番相当の負荷環境」と「試験シナリオ」を作り込んでいたため、これらを再利用することで、新たな仕組みを整備することなくTiDB Cloud環境での性能計測が可能となりました。
負荷検証はDedicatedクラスタのサイズを変えつつ行いました。
検証結果：実測値と運用上の気づき
ここからは、実際に負荷をかけてみて分かった「数字」と「挙動」について紹介します。
検証の目的
主な検証観点は以下の2点です。
- Aurora for MySQLとの互換性：アプリケーションコードを改修せずに移行可能か。
- 負荷耐性の傾向とスケーラビリティ：ノード追加によってリニアに性能が向上し、Auroraの限界を超えうるか。
互換性
今回の疎通確認や負荷試験の範囲では、公式ドキュメントに提示されている非互換・留意事項以外の問題は発生せず、非常に高い互換性が確認できました。
スケーラビリティ
TiDB（コンピュート）ノードとTiKV（ストレージ）ノード を増やすことで、処理能力が順当に向上することを確認しました。より小さいクラスタサイズでは過負荷となったワークロードも、クラスタサイズを上げることで安定して処理できました。
パフォーマンス比較（対 Aurora）
既存のAurora環境と比較して、アプリ側のチューニングなし（接続先変更のみ）で計測した場合の挙動は以下の通りです。
- スループット: Aurora比で 100〜110% 程度
- Aurora向けの負荷試験シナリオをほぼ同等のスループットで通過しました。
- 分散DBとしての特性により、書き込み（Write）のスループットはボトルネックにならず順当に出ることが確認できました。
- レイテンシ: Aurora比で 20〜30%程度悪化
- スループット重視のアーキテクチャであること、またチューニングなしの状態としては想定範囲内です。
- アーキテクチャ上のネットワークホップ数の増加に加え、今回の検証ではTiDB側でのPlan CacheのHit率が低く、CPU負荷が高まりやすい傾向が見られました。
- こちらはPrepared Statementの活用によるCache率向上などで、改善の余地があると考えています。
クラスタの規模はAuroraは最大級のWriterインスタンス、TiDB CloudはTiDB、TiKVそれぞれ9ノード（デフォルトクオータの2/3程度）です。 試験時のリソースの使用率、余力が異なるため、単純にこれが同等というわけではありません。 TiDB Cloudは更にキャパシティを上げる余地がある点が重要です。
スケーリングの実際
所要時間の実測値
TiDBの魅力である「ダウンタイムのないスケーリング」ですが、コンソール上で変更を適用してから実際に完了するまでの時間を計測したところ、以下のようになりました。
- TiDBノード（SQL処理）のスケールアウト
- 3ノード → 9ノードへの変更：約45分
- 挙動：6ノードの追加に対し、概ね1ノードあたり5〜10分程度の時間を要しました。
- TiKVノード（ストレージ）のスケールアップ
- 9ノード（16 vCPU） → 9ノード（32 vCPU）への変更：約1時間
- 挙動：9ノードの変更に対し、こちらも1ノードあたり5〜10分程度で順次適用される動きでした。
運用スケジュールの制約（6時間クールダウン）
また、クラウドプロバイダ（AWS/Azure）上でホストする場合、TiKV等のサイズ変更後に6時間のクールダウン期間が発生するという制約があります。
前述の「スケーリング完了までにかかる時間（約1時間）」と、この「クールダウン（6時間）」の仕様を加味すると、以下のような細かいコスト最適化運用は難しいことが分かりました。
- 日付変更時のスパイクに合わせてスケールアップ
- その後、深夜のリクエストが少ない間はスケールダウン
- 朝の通勤時間帯のリクエスト増に合わせて再度スケールアップ
「必要な時に瞬時にリソースを増やし、終わったらすぐ戻す」という運用よりは、あらかじめ高い負荷が予想される期間に向けて余裕を持ってスケールさせておく運用が適していると言えます*2。
まとめ：高負荷時の「強力な手札」として
今回の検証を通じて、TiDB Cloudは「Auroraの単体スケールアップ限界を超えるような極端な書き込み負荷」が発生した際の有力な選択肢になり得ることが確認できました。
- 高い移植性：MySQLとの互換性は十分で、既存アプリからの移行障壁が低い。
- 物理的な限界突破：課金（リソース投入）によって、書き込み性能の限界を物理的に引き上げることができる。
現状の運用ですぐに乗り換える必要がなくとも、「どうしても捌ききれない負荷が来たときは、TiDB Cloudへオフロードする」という選択肢を持てたことは、サービスを長期的に安定運用していく上で大きな安心材料となりました。
引き続き、データベース技術の進化を注視しつつ、最適なシステム構成を検討していきたいと思います。
