[
こんにちは、テクノロジー戦略本部の松井と申します。
弊社は会員数1.3億人のVポイントサービスを運営しております。 その中でテクノロジー戦略本部は、Vポイント基盤やVポイントアプリ、それに付随する各マイクロサービス、また分析を行うデータ基盤、データサイエンス、AI領域などの幅広い領域の開発と運用を担っており、私は現在その責任者をしております。
はじめに：大規模トランザクション基盤の課題
当社が運用するVポイントシステムは、1.3億人規模のユーザーを抱え、ピーク時には数万QPSのクエリ処理が求められる大規模システムです。
インフラを最新化しつつ、15年以上にわたり安定稼働してきた一方で、いくつかの構造的な課題が顕在化してきました。
- 高コスト構造：DBソフトウェアライセンスも含め、年間数億円レベルのインフラコストが発生
- 柔軟性の欠如：ピーク負荷に合わせた固定的なリソース構成
- 技術革新への対応：レガシーなアーキテクチャによるエンジニアコストの増加や最新技術習得の機会損失
これらの課題に対応すべく、2025年9月から12月までの約4ヶ月間、水平スケーリング可能な分散SQLデータベース「TiDB」を用いた性能検証を実施しました。本記事では、その中間結果と今後の展望をご紹介します。
【本記事の位置づけ】
本記事は、次世代ポイント基盤の技術選定に向けた検証プロセスの「第一段階」の結果報告です。
基盤システムの安定性を維持しながら、柔軟性の向上とコスト最適化も実現するという、今まで以上にチャレンジングな設計により事業貢献を高めたいと考えています。
アーキテクチャ構成はTiDB以外の複数の製品を含め、今後1年ほどの期間を掛けて検討し、数年がかりで移行していくこととなります。そのため、TiDBを採用するかも含めた最終的な採用判断は、今後の追加検証を経て決定していく予定です。
またこのプロジェクトは弊社の若手メンバーが中心となり、経験豊富なシニアエンジニアも参画しながら推進しています。新しいテクノロジーの検証を通じて、組織の世代交代を図る一手となっております。
TiDBとは：分散SQLデータベースの特徴
TiDBは、PingCAP社が開発したオープンソースの分散型NewSQLデータベースです。
主な特徴： - MySQL互換のプロトコル - 水平スケーラビリティ - OLTPとOLAPを単一システムで処理 - AWS/Azure/Google Cloudでマネージドサービスを提供
公開されている採用事例では、楽天ポイントのポイント履歴・集計DBやカプコン社のマルチプレイヤーオンラインゲームなど、大規模トランザクション処理での採用実績があります。
今回、このTiDBが当社の次世代ポイント基盤の候補となり得るか、実データと実負荷で検証しました。
検証設計：現実的な負荷での実証
検証環境
- プラットフォーム：Azure上のTiDB Cloudマネージドサービス（TiDB Cloud Dedicated on Azureはパブリックプレビュー中）
- データ規模：TB級（本番同等のデータ量）
- 目標性能：数万QPSレベルのトランザクション処理
- 検証期間：2025年9月〜12月（約4ヶ月）
評価の観点
大規模な本番システムでは、単なるベンチマーク値ではなく、実際のワークロードでの性能が重要です。今回は以下の4つの観点で評価しました。
- 性能：実負荷での処理能力とレイテンシ
- 運用性：障害時の挙動と復旧時間
- 互換性：既存システムからの移行可能性
- コスト：TCO（総所有コスト）の削減効果
互換性については、DBLINKやストアドプロシージャなどの非互換機能が存在しますが、代替手段や移行方法はある程度見通しが立ちました。 性能面では要件を満たす可能性を確認できました。コスト面については、基盤のクラウド化とライセンス構造の見直しにより削減効果が期待できます。一方で、DR環境などの非機能要件を含めた全体構成での最適化を、今後の詳細検証で図ります。 その中で、本記事では、特に性能と運用性の検証結果に焦点を当ててまとめていきたいと思います。
負荷試験シナリオ
本番システムの利用パターンを分析し、3つのシナリオで検証しました。
- 短期ピーク負荷試験：ピーク時の数万QPSを再現
- 24時間耐久試験：長時間の安定性を確認
- 複合負荷試験：リアルタイム処理とバッチ処理の並行実行
性能検証結果：試行錯誤の軌跡
初期検証での壁
本番相当のデータを投入した初期段階では、期待した性能を得ることができませんでした。
直面した課題： - 特定のクエリで想定の数倍のレイテンシ - DBリソース（特にCPU）の使用率が異常に高い - 実行計画が頻繁に変動し、性能が不安定
これは、従来のRDBMSの設計をそのまま持ち込んだことが原因でした。TiDBは分散Key-Valueストアをベースとしており、異なる設計思想が求められます。
チューニング① パーティション戦略の見直し
最も大きな影響があったのが、パーティションテーブルの扱いです。
当初の設計： 既存システムのパーティション設計を踏襲し、特定のカラムでハッシュパーティションを構成していました。
発覚した問題： アプリケーションからのクエリには、パーティションキーを含まない検索条件も存在します。この場合、TiDBは全パーティションをスキャンする必要があり、リソース負荷が急増しました。
対応策： アクセスパターンを詳細に分析し、頻繁にアクセスされるテーブルをパーティションから通常テーブルへ転換しました。
結果： 該当テーブルへのクエリレイテンシが劇的に改善し、DBリソース使用率も正常化しました。
チューニング② 主キーのクラスタリング設計の最適化
TiDBでは主キーのクラスタリングをするかどうかがデータの物理的な配置を決定します。これは、分散環境でのデータ配置の基本となる重要な概念です。
最適化のアプローチ： - クエリの検索条件と主キーを一致させ、クラスタリングさせる（clustered index） - 複合キーの順序を慎重に設計 - アクセス頻度の高いテーブルから優先的に最適化
具体例： 会員番号とアクセス日時の複合キーで検索されるテーブルでは、主キーの定義を変更し、clustered indexとして適切に機能するよう再設計しました。
結果： 適切なクラスタキー設計により、特定のクエリパターンで数倍の性能改善を確認できました。
チューニング③ インデックス戦略の再考
従来のRDBMSでは、「インデックスを追加すれば性能が向上する」というのが定石です。しかし、TiDBでは逆のケースがありました。
興味深い発見： 特定のクエリで、インデックスを削除することで性能が向上しました。
理由： TiDBのオプティマイザが、Key-Value型のクラスタキースキャンを選択すべき場面で、インデックススキャンを選択してしまうケースがあります。不要なインデックスを削除することで、オプティマイザが適切な実行計画を選択するようになりました。
教訓： 分散データベースでは、従来のRDBMSの常識が必ずしも通用しません。アーキテクチャの特性を理解した上での設計が不可欠です。
最終的な性能検証結果
段階的なチューニングを経て、以下の成果を得ることができました。
短期ピーク負荷試験
- 負荷：数万QPSレベル
- 平均レイテンシ：許容範囲内（数十〜数百ミリ秒）
- レイテンシの安定性：最大値が従来システムより小さく、安定
- 0.5秒超過率：低水準を維持
従来システムと比較して、平均レイテンシはやや増加したものの、最大レイテンシが小さく、より安定した応答特性を確認できました。
24時間耐久試験
- 実施内容：ピーク相当の負荷を24時間連続実行
- リソース使用率：CPU・メモリともに安定推移
- エラー発生：プラットフォーム起因のエラー0件
長時間稼働でも性能劣化は見られず、本番運用に耐えうる安定性を確認しました。
複合負荷試験
バッチ処理（大量データの取り込み）とリアルタイムAPI処理を並行実行した場合でも、リアルタイム処理のレイテンシへの影響は限定的でした。
スケーラビリティ検証
TiDBの最大の特徴である水平スケーリングの柔軟性を検証しました。
- ノードの増減：ダウンタイムなく実行可能
- スケーリング中のレイテンシ：ほぼ影響なし
- 自動的な負荷分散：新規ノード追加後、自動的にデータが再配置される
これにより、ビジネスの成長やキャンペーンによる急激な負荷増加にも、 柔軟に対応できる可能性が見えてきました。
課題と今後の展望：
一方で、今回検証したTiDB Cloud Dedicatedでは、スケーリングは手動操作となります。 キャンペーンなど予測可能なピーク時には事前スケーリングで対応可能ですが、 予測困難な突発的な負荷増加への即座の対応には限界があります。
スケーリングの自動化や高速化は今後の製品採用においては重要な要素の一つであり、これらの対応は弊社として強く要望する機能となります。
そのような中、PingCAP社は2025年10月に「TiDB X」という新アーキテクチャを発表しました。 これは、ワークロードに応じたリアルタイム自動スケーリングを実現し、突発的なトラフィックスパイクにも自動対応する設計となっています。
現状TiDB Cloud Dedicatedへの対応はされていませんが、次フェーズでは、今後の対応状況を踏まえつつ、TiDB Xの評価や、より高速なスケーリングの実現可能性についても検証を進める予定です。
運用性の検証：障害時の挙動
性能と同様に重要なのが、障害時の挙動です。分散アーキテクチャの高可用性を実測しました。
TiKVノード障害試験
稼働中のTiKVノード（データストレージ層）を強制停止し、復旧までの挙動を観測しました。
結果： - トランザクションエラー：発生せず - レイテンシへの影響：縮退稼働中も安定 - オートヒーリング：約2分で自動復旧 - データ再配置：復旧後、自動的に負荷が再分散
分散アーキテクチャの利点を活かした高い可用性を実現できることを確認しました。
TiDBノード障害試験
TiDBノード（SQLレイヤー）の障害では、瞬間的なエラーが発生しましたが、すぐに他のノードへ処理が振り分けられ、約2分で自動復旧しました。
今後の検証計画：より実践的なシナリオへ
今回の検証により、基本的な性能要件を満たす可能性が見えてきました。一方で、本番適用には以下の追加検証が必要です。
フェーズ2：DR環境と複合ユースケース（2026年Q1-Q2予定）
1. DR（災害復旧）環境の検証
- リージョン間レプリケーションの性能
- RPO/RTO要件の確認
- フェイルオーバー時の影響測定
- データ整合性の検証
2. より複雑なワークロード
- より多様なデータパターンでの性能確認
- 大規模バッチ処理との並行負荷
- 数週間〜数ヶ月レベルの長期安定性
- ピーク変動パターンでの動的スケーリング
- TiDB X等の新アーキテクチャの評価
- TiFlashによるOLTP/OLAP分離の効果測定
3. 運用性の深掘り
- 監視・アラート戦略の確立
- オートスケーリングポリシーの設計
- バックアップ・リストア性能の測定
- 運用自動化の実現
まとめ：期待と慎重さのバランス
得られた成果
今回の4ヶ月間の性能検証を通じて、以下のことが明らかになりました。
ポジティブな発見： - 適切な設計とチューニングにより、数万QPSレベルの要件を満たす可能性 - 水平スケーリングによる柔軟なリソース管理の実現 - 分散アーキテクチャによる高可用性の確認 - 従来システムより安定したレイテンシ特性
技術的な学び： - 分散データベースには独自の設計思想が必要 - パーティション戦略、クラスタキー、インデックスの考え方が従来と異なる - 段階的なチューニングで性能を大きく改善できる
継続検証の必要性
一方で、本番適用には以下の点でさらなる検証が必要です。
- DR環境を含めた本番構成での検証
- より長期・複雑なユースケースでの評価
- 運用体制の確立
次世代基盤への挑戦
今回の検証は、単なるデータベースの移行ではありません。クラウドネイティブなアーキテクチャへの段階的な移行を通じて、以下を実現することが目標です。
- 柔軟性：ビジネスの変化に迅速に対応できるインフラ
- 経済性：必要な時に必要なリソースを使う従量課金型の運用
- 信頼性：分散アーキテクチャによる高可用性の実現
- 拡張性：スケーラブルで将来の成長に対応できる基盤
技術選定は慎重に、しかし前向きに進めていきます。今後も検証の進捗や得られた知見を、継続的に共有していく予定です。
また、ポイント基盤に採用する前に別のサブシステムで実際に運用可能か先行した導入も検討しております。 しかしながら、TiDB Cloud Dedicated on Azureはパブリックプレビュー中であるため、今後商用環境で採用するためには、General Availability（一般向けリリース）を待ちつつ、より精緻な検証を継続していきたいと思います。
同様の検証を行っている方、TiDBの運用経験をお持ちの方からのフィードバックもいただけたら大変嬉しい限りです。
【次回予告】
様々な技術を検討しながら、2026年Q2頃には、上記のDR環境検証と複合ユースケースの検証結果などもまた記事にできれば良いなと考えています。
