日本最大のポイントサービスがTiDBを採用する 理由と背景・そして将来を見据えた展望について 楽天グループ株式会社　ロイヤリティプラットフォーム開発課 陳 曦 / 松村 未来 / 榊原 祐輔

2

3 1997年 従業員6人で創業 2022年 従業員数：32,000人超 出身国・地域：100超 楽天グループ株式会社 ※https://corp.rakuten.co.jp/about/map/crimsonhouse/　2023年11月時点 ※https://corp.rakuten.co.jp/careers/services/　2023年11月時点

4 サービス / 事業 70以上の事業、32,000人以上の従業員を持ち グローバルに展開する インターネット＆テクノロジーカンパニー 70+ グローバル 展開拠点 30 グループサービス 利用者数 17億 + 2022年度 グローバル流通総額 33.8兆円 ※https://corp.rakuten.co.jp/careers/services/　2023年11月時点 カ国・ 地域

5 楽天エコシステムを牽引する楽天ポイント サービス開始 2002年 にてサービス提供 30カ国・地域 累計発行ポイント数 ※2022年12月30日時点 3.3兆超 2022年発行ポイント数 約 6,200億 全事業で利用 70+ ※https://corp.rakuten.co.jp/investors/assets/doc/documents/22Q4CEOPPT_J.pdf

6 アメリカ 次世代ポイントプラットフォーム Country A DC 1 Country B DC 2 Point Microservices Platform Country C Public Cloud History Service Campaign Service Redeem Service Grant Service Exchange Service Balance Service -- -- -- --- …… Location One Platform Business anywhere ...... Country A Public Cloud User Rank Service 統合されたプラットフォームとして、世界中の事業・ユーザに楽天ポイントのサービスを提供 楽天サービス A 楽天サービス B 楽天サービス C 楽天サービス D 日本 ヨーロッパ

7 楽天ポイントプラットフォーム 開発マネージャー 2009 楽天入社 榊原 祐輔 楽天エコシステム開発 シニアソリューションアーキテクト 2019 楽天入社 松村 未来 楽天エコシステム Point Platform Campaign Platform 楽天エコシステム E-mailing Platform Membership Platform Point Platform

8 楽天ポイントの特徴

9 ポイントプラットフォームとは サービス利用 （購買、支払い…） ポイント利用 ポイント付与 ポイント情報参照 会計 楽天ポイント エンドユーザー ポイント関連機能を グループサービスに提供 獲得グラフ 獲得・利用履歴 残高 会員ランク ※https://point.rakuten.co.jp/　2023年11月時点 楽天サービス A 楽天サービス B 楽天サービス C :

10 楽天ポイントの特徴 データ量が多い 特定日に大量の キャンペーン ポイント • 2022年の発行ポイント数は約6,200億 • クリック広告で1ポイントずつ獲得する ユーザーも多い • 通勤時間に付与されたか確認に来る ユーザーも多い 1 2 ※https://corp.rakuten.co.jp/news/update/2022/0719_01.html?year=2022&month=7&category=corp%20ec　2023年11月時点

11 主要機能の変遷 ダイヤモンドランク新設 201 2 会員ランク条件に「楽天カード保有」追加 ポイントカード開始 201 4 オフラインでの利用拡大 獲得予定ポイント表示 201 6 今後どれだけ獲得できるかを見える化 2016 - 2017 通算ポイント表示 生涯バリューとしての訴求 ※https://campaign.rakuten.jp/poionaire/ (2023/11) 201 9 ポイント獲得グラフ表示 より視覚的な「お得感」の表現 2022 獲得カレンダー表示 より視覚的な獲得予定の共有

12 エンターテイメントとしての楽天ポイント 楽天ポイントの「お得感」を どうユーザーに見せるか？ ※https://event.rakuten.co.jp/group/point/pointzukan/　2023年11月時点

13 インフラとしての楽天ポイント 一方でシステム要件として 大量の付与を 遅延なく処理する 残高情報を 高速に返す （特にお買い物イベント時のリクエスト急増にも対応） サイト障害時も システム停止しない 重要

14 現行システムから次世代ポイントプラットフォームへ

15 現行システムの課題 ... ... • 拡張性の低い実装 • DB性能への高依存 アプリケーションの課題 • データ容量の増加に伴う拡張性 • 高い維持コスト • メンテナンス性 • バージョンアップ/Fail Over等、システム 停止なしで実施が難しい • 障害時の調査に有償サポートが必要 データベースの課題 API DB キャッシュ D B

16 DC 2 DC 1 DC 2 次世代ポイントプラットフォーム 現行 システム 付与 利用 DC 1 同一クラスタ レプリケーション 履歴 会計 会員 ランク • リアルタイム性 • 耐障害性 （更新系も無停止） • スケーラビリティ • 柔軟なクエリ • 集計処理 • スケーラビリティ 履歴・集計 システム 履歴 会計 会員 ランク データ移行 データ移行 残高管理 付与 利用 残高管理

17 履歴・集計システム ポイント履歴 統計情報 いつどんなアクティビティがあっ たか・ある予定か 獲得グラフ・通算ポイント サービスごとの獲得状況 会員ランク ポイント獲得・その他条件を元 に計算 会計 用途ごとの付与・利用額集計 請求書作成 取引データを利用した「その後」のためのシステム

18 履歴・集計システムのデータベース要件と課題 データ量 大量の取引データ、ならびにその統計データを保存 クエリ 複数カラムの条件で検索 / オンライン処理に十分な速度 学習コスト 人員交代があっても運用しつづけられる 拡張性 データ増に伴い、サービス停止なしで拡張できる サポート パッチが適用されている / 運用サポートが受けられる

19 TiDB選定に至るまで

20 TiDB選定で行った検証事例を一部ご紹介 　TiDB選定に至るまで – 履歴・集計DBに求められる要件について TiDBのパフォーマンス検証１ – ポイント履歴情報 Insert & Select TiDBのパフォーマンス検証２ - ユーザー集計情報 Select

21 集計システム簡略図 コアシステム ポイントプラットフォームのメイン機能： 付与 , 充当（利用） • セール時など、ピークタイムには大量のInsert/Updateが行われる 履歴・集計システム • ランク, 履歴, 集計, 会計など • サービス利用時にコアシステムへのパフォーマンス影響を与えないことが求められる • コアシステムの可用性担保のため、データソースとして集計サービスを切り離した運用が求められる 付与 利用 残高管理 履歴 会計 会員 ランク コアシステム 履歴・集計システム New DB Proposal

22 チームが検証していたアプローチとその課題 高い開発コスト 高メンテナンスコスト スケーリングの難しさ 大規模なデータセットでのパ フォーマンス劣化 MySQL + シャーディングによる実装 Cassandra + Apache Spark Transactionのサポート 高メンテナンスコスト 集計処理の 高いレイテンシ 集計時の高いDB負荷

23 これらの課題を解決するためのソリューションとして チーム内で新しいソリューションを模索 New SQL

24 TiDB選定に至るまでの過程 – ソリューションの比較 Feature RDBMS(SQL) NoSQL NewSQL リレーショナル Yes Relational model No. Key-Value Storage Yes Relational model ACID特性 Yes No アプリケーション側で実装 Yes SQLの利用 Yes No ※または制限あり Yes Queryの取り回しの良さ Indexの利用など Yes ※複雑なクエリに対応可能 No ※複雑なクエリに対応不可 Yes ※複雑なクエリに対応可能 クラスタ追加による スケーリング Difficult ※水平スケーリングが困難 Easy Easy 分散型DB No Yes Yes Source: http://www.xenonstack.com/blog/sql-vs-nosql-vs-newsql

25 TiDB選定に至るまでの過程 – ソリューションの比較 スケーリング特性 インターフェース ACID特性及び Transaction サポート HTAP その他 TiDB 水平スケーリング TiDBとTiKVそれぞれ 独立したスケーリングが可能 • MySQL Compatibility • Indexのサポート OK YES TiFlashによる 拡張性 • Web UIやDashboard • コミュニティの規模 • 日本でのビジネスサポート Solution B 水平スケーリング • PostgreSQL Compatibility • Indexのサポート OK 限定的 • 他チームでの運用実績がポイント チームの運用における課題となった Solution C 水平スケーリング • PostgreSQL Compatibility • Indexのサポート OK 限定的 • 社内の利用実績が少ない Solution D 水平スケーリング • SQLの使用ができない • Updateが不得意 • IndexのサポートNG 限定的 限定的 OLAPに強み • メモリサイズの要件が厳しい

26 TiDBパフォーマンス検証 1 – ポイント履歴相当 大量データ

27 TiDBパフォーマンス検証 1 – ポイント履歴相当 大量データ ケース１：書き込み ケース２： 書き込み + 読み込み 参照API 検証環境 検証用テストデータ： 9000万レコード TiDB: 4ノード PD: 3 ノード (32core / 36GB) TiKV: 4ノード TiCDC: 1ノード 検証内容 ケース1 10分ごとにバッチ処理で300万件をスキャンし、TiDBに投入 ケース2 ケース1 ＋ 最大5000QPSで参照APIによるTiDBのSelectを実施

28 TiDBパフォーマンス検証 1 - ポイント履歴相当 大量データ Case Job 実行時間 最大書き込み スループット 整合性 TiDB CPU利用量 TiDB Memory利用量 参照API レスポンス ケース1 Selectなし 120 – 150 sec 25k tx/sec OK 30% 19% N/A ケース2 Selectあり 5k QPS 132 – 162 sec 22.7k tx/sec OK 60-65% 19% Avg 17.8ms

29 TiDBパフォーマンス検証 2 – ユーザー集計情報計算API

30 TiDBパフォーマンス検証 2 – ユーザー集計情報計算API

31 TiDBパフォーマンス検証 2 – ユーザー集計情報計算API 10000 - 15000 5000 - 10000 1000 - 5000 500 - 1000 1 - 500 検証用データセット テーブル内テストデータ件数：１億件 検証用ダミーユーザー数：1000万レコード ５つのユーザーグループを模した 検証用データセットを作成 高頻度利用ユーザー（最大 15000件の利用）~ 低頻度利用ユーザー（ 500件程度の利用） それぞれのグループに対してクエリを 並列実行（計5000QPS）し負荷を計測 検証用Query例 select user_id, sum(amount) from dev_agg_service.history where grant_time BETWEEN CURDATE() - INTERVAL 6 MONTH AND CURDATE() and user_id=?; 1000QP S 1000QP S 1000QP S 1000QP S 1000QP S

32 TiDBパフォーマンス検証 2 ユーザー集計情報計算API 検証結果

33 POCでの検証結果 API ノード数 テストデータ量 参照API(QPS) Response Time ポイント履歴 API TiDB (4 node) Ti Kv (4 node) 利用履歴300万件 を継続的に書き込み 5000 Avg 17.8ms ユーザー集計情報 計算API TiDB (4 node) Ti Kv (4 node) 利用履歴１億件 5000 80パーセンタイル Latency 1.95ms 95パーセンタイル Latency 8ms

34 CONTACT US Rakuten Crimson House 1-14-1, Tamagawa Setagaya-ku, Tokyo @ pro-point-all@mail.rakuten.com

No content

36 集計サービスのソリューションに求められた要件 • 1テーブルあたりのレコード数：1年超の全取引・変更データ • ディスク使用量：履歴文言のような文字列を含む大量のデータ データのキャパシティ • 複数DCに跨ったデータベース運用 BCP対応 • 複数DC間でのデータの一貫性 データの一貫性 • ビジネスの展開に伴うデータやトラフィック量の増加に対応が可能 スケーラビリティ • 多元的なクエリによるデータの取得 • ACID特性を持ったデータベース 高いパフォーマンス特性と フレキシブルな集計