日本最大のポイントサービスがTiDBを採用する理由と背景・そして将来を見据えた展望について

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

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
@ [email protected]

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

日本最大のポイントサービスがTiDBを採用する理由と背景・そして将来を見据えた展望について

日本最大のポイントサービスがTiDBを採用する理由と背景・そして将来を見据えた展望について

More Decks by PingCAP-Japan

Other Decks in Technology

Featured

Transcript