楽天ポイントの次世代プラットフォームにNewSQLのTiDBが採用決定。その背景と評価結果を楽天のエンジニアが解説［PR］

今回は「楽天ポイントの次世代プラットフォームにNewSQLのTiDBが採用決定。その背景と評価結果を楽天のエンジニアが解説［PR］」についてご紹介します。

関連ワード （利用、構成、運用等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

日本を代表するインターネット企業の1つである楽天。その楽天が展開する多様なビジネスのエコシステムを牽引するのが「楽天ポイント」です。

2002年にサービスを開始した楽天ポイントは現在、同社の70以上の全事業で利用され、累計で3.3兆ポイント（2022年12月30日時点）が発行されています。

この楽天ポイントを支えるポイントプラットフォームが次世代プラットフォームへと刷新される際に、そのデータベースとしていわゆるNewSQLと呼ばれる分野の代表的な製品の1つである「TiDB」の採用が決定されました。

2023年12月に都内で開催されたイベント「db tech showcase 2023 Tokyo」で、楽天の次世代ポイントプラットフォームの開発に関わった方々が行ったセッション「日本最大のポイントサービスがTiDBを採用する理由と背景・そして将来を見据えた展望について 」では、従来のポイントプラットフォームがどのような課題を抱えていたのか、そしてそのソリューションとして次世代プラットフォームになぜTiDBが選択されたのかが語られています。

写真左から、楽天グループ株式会社 ローヤルティープラットフォーム開発課 課長 陳曦（Vicky Chen）氏、楽天グループ株式会社 ローヤルティープラットフォーム開発課 開発マネージャー 松村未来氏、楽天グループ株式会社 ローヤルティープラットフォーム開発課 ソリューション アーキテクト 榊原祐輔氏

この記事では、そのセッションの内容をダイジェストで紹介していきます。

楽天ポイントを支えるプラットフォームの要件とは

多くの方が既にご存じのように、楽天ポイントとはユーザーが楽天市場や楽天カードなどを利用すると利用額に応じてポイントが付与され、付与されたポイントは次回の支払いに使える、というものです。

ポイントプラットフォームはこうしたポイントの付与や使用、ユーザーの取引履歴や所持しているポイント数の参照機能、ポイントに関わる会計処理などをAPIやレポートを通じて提供するシステムとなります。

そして楽天ポイントは急速に発行数が伸びており膨大なデータ量になること、そしてキャンペーンなど特定の日にポイントの処理が集中することがある、などの特徴があります。

ポイントプラットフォームは、こうした処理が集中している状態でも遅延することなくポイントの付与が行えること、残高情報を高速に返せること、そしてシステムが停止しないこと、などがシステム要件となります。

次世代ポイントプラットフォームの要件とは

このポイントプラットフォームの現行システムは商用のリレーショナルデータベースを用いたモノリスなシステムであり、その課題として、システム停止なしでのバージョンアップが容易ではないこと、障害時の調査がベンダー依存になることなどがありました。

これらの課題を解決するために、開発されたのが次世代ポイントプラットフォームです。

次世代ポイントプラットフォームは2つの部分に大別されます。

1つ目は、ポイントの付与や残高管理などのポイント取引の中心となる機能を担う部分（図の上半分）。

ここは無停止で提供する必要があり、その上でコストやメンテナンス性、楽天社内のナレッジなどを考慮した結果、NoSQLデータベースのApache Cassandraをマルチデータセンターで構成することになりました。

2つ目は、その取引データを受け取って蓄積し、履歴や集計処理、会員ランクなど、ポイントに関連するさまざまな処理を担う部分（図の下半分）です。

この履歴・集計システムのデータベースにTiDBが選定されました。

ここでは蓄積した情報からユーザーの取引履歴を返す、あるいは統計情報として月次の取引結果や会員ランクを返す、あるいはポイントに関する支払い処理や会計処理を行うなどの処理を担います。

この処理を行うためのデータベースの要件として、増大し続ける全取引データに加えて統計データなどの大規模なデータを保持できること、そうした大規模なデータに対して履歴や統計などある程度複雑なクエリでも迅速に実行できること、そして今後も増え続けるデータに対してストレージを増やすことで容易に対応できること、などがありました。

さらに学習コストやサポートなどについても重視されました。

TiDB選定の理由は柔軟なスケーラビリティ、MySQL互換性など

ポイント取引の中心となる機能をApache Cassandraで構築することにしたのは、既に別の集計処理でApache Cassandraを使っており馴染みがあったためだと説明されました。

しかしApache Cassandraは、ユーザーが現在何ポイント持っているのかなどの集計処理を迅速に提供する用途には向いておらず、そこで同社がたどり着いたのが、従来のデータベース製品よりスケーラビリティなどに優れたNewSQLデータベースです。

同社はTiDBを含む複数のNewSQLデータベース製品を調査したところ、水平スケーリングやACID特性などはいずれも甲乙付けがたい状態でした。

その中でTiDBを選定した理由として、次の3つが挙げられました。

• 水平スケーリングに関しては、計算処理を行うためのノードであるTiDBと、データをストアするTiKVなどのコンポーネントが組み合わさって機能を提供していることで、柔軟なスケーリングができるアーキテクチャになっていること
• 非常に高いレベルでのMySQL互換によりアプリケーションのコードをあまり変更することなくアプリケーションを載せ替えることができること
• TiFlashという列指向データベースの機能を追加することで、集計処理に特化した機能を持たせることができること

強い整合性を保ったままでの書き込み性能などを検証

その上で次のようなパフォーマンス検証も行われました。

まず検証環境として、オンプレミスのデータセンターにTiDBのクラスタ（TiDB 4ノード、TiKV 4ノード）を構築。

1つ目のテストは、Apache Cassandra上の9000万レコードを10分ごとに繰り返しバッチ処理で300万件をスキャンし、TiDBに投入するという書き込み性能の検証です。

さらにこの処理をしつつ、同時に参照APIによる500QPSのIDの検索を実行する2つ目のテストも行いました。

このような強い整合性を保ったままでの書き込み処理、その上で同時に読み込み処理を行った場合でも、1割程度の書き込みスループットの低下、そして参照APIへも平均17.8ミリ秒で安定的にデータを返せることが確認できました。

ユーザー集計情報の性能を検証

さらに、集計処理の検証を目的として実施されたパフォーマンステストとして、1億件余りのデータを付与実績テーブルにインサートし、1000万のダミーユーザーを作成します。

そしてそのユーザーを5つのグループに分けて、最も利用量が多いグループには1万件から1万5000件の利用履歴、一番利用実績が少ないグループは1件から500件の利用履歴のデータを作り、それらの利用実績データに対してそれぞれ同時に1000QPS、合計で5000QPSをランダムに同時アクセスをするようなテストを実行しました。

このテストではTiDBのCPU利用率、メモリ利用率が80%程度と非常に高い値でしたが動作は安定的しており、80パーセンタイルのレイテンシが1.95ミリ秒、95パーセンタイルでもレイテンシが8ミリ秒と、非常に望ましい結果を得ることができました。

結果、どのテストにおいてもTiDBでは期待値以下のレスポンスタイムでデータを取得することが確認できました。

このようにTiDBはその機能やアーキテクチャ、そして性能検証、さらに各種オペレーションや運用した際に生じる障害などに対するオペレーションの検証を踏まえて、次世代ポイントプラットフォームにおける集計などのためのデータベースとして選定することが決定されたのです。

楽天ポイントの次世代プラットフォームは、すでに一部が稼働開始しているとのことです。

≫TiDB – MySQL互換 – NewSQLデータベース- PingCAP株式会社

（本記事はPingCAP株式会社提供のタイアップ記事です）