金融トランザクションにNewSQLが使えるか検証してみた - db tech showcase 2022 Tokyo

オンライン決済のニーズは高まり続けており、決済トランザクションは増え続けています。決済を支える仕組みとして、高い可用性はもちろんのことスケーラビリティは以前にも増して要求が高まっています。
このスライドでは、柔軟に水平拡張可能な現世代型データベース：NewSQLのひとつであるTiDBについて、特徴と金融系サービスの要件軸で検証した結果をご紹介します。（旧来型のRDBと比較も）
出典：db tech showcase 2022

トピック：
・TISの会社・事業部紹介
・決済ネットワークで求められる要件
・決済ネットワークにおける昨今の課題感
・これまでを支えてきたRDB
・RDBとNewSQLについて
・TiDBとは
　　--検証
--性能
--耐障害性
--拡張性
・まとめ、今後の展望

アーカイブ動画：
https://youtu.be/vte7j3_0haI

Transcript

1. © 2022 TIS Inc. 2022/11/16
 金融事業本部　カードネットワーク事業部　
 
カードネットワーク基盤ソリューション部
 
 ••••••••••••••••••••• 
 金融トランザクションにNewSQLが使えるか検証してみた
 石原　賢人
2. © 2022 TIS Inc. 2
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性
 – 拡張性 • まとめ、今後の展望
3. © 2022 TIS Inc. 3
 会社・事業部紹介

4. © 2022 TIS Inc. 4
 会社・事業部紹介
 https://www.tis.co.jp/company/organization/
5. © 2022 TIS Inc. 5
 会社・事業部紹介
 カードネットワーク基盤ソリューション部 
 日本のキャッシュレス基盤を支えているインフラエンジニア集団 このカード使えますか？ 
 YES
 請求します！
 お支払い
 消費者が利用するお店 
 クレジットカード会社 
 （小売店や飲食店など） 

6. © 2022 TIS Inc. 6
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
7. © 2022 TIS Inc. 7
 決済ネットワークで求められる要件
 24時間365日、システムの停止や誤作動が合ってはならない。
 大規模災害に備えたシステム設計も必須。
 1
 超ミッションクリティカル
 PCI DSS(Payment Card Industry Data Security Standard)の遵守。
 クレジットカード情報を扱うため、高いセキュリティは必須。
 2
 高いセキュリティ
 現在のあるシステムでは、約19,500QPS（ピーク時）
 3
 サービスレベルを満たす性能

8. © 2022 TIS Inc. 8
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件
 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB
 • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
9. © 2022 TIS Inc. 9
 決済ネットワークにおける昨今の課題感
 コロナやキャッシュレス化の波などお客様環境の変化により、トランザクション量が増大。 トランザクション量の増加に伴うデータベース構築が必要であり、コストが高くなりがち。 →これまでの製品ではない、次世代ソフトウェアの候補を探り、低コスト化を実現したい +α 柔軟な拡張性とコストバランス PCI DSS(Payment Card Industry Data Security Standard)の遵守。クレジット カード情報を扱うため、高いセキュリティは必須。
 高いセキュリティ 3 2 現在のあるシステムでは、約19,500QPS（ピーク時）。
 サービスレベルを満たす性能 24時間365日、システムの停止や誤作動があってはならない。
 大規模災害に備えたシステム設計も必須。
 超ミッションクリティカル 1
10. © 2022 TIS Inc. 10
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
11. © 2022 TIS Inc. 11
 これまでを支えてきたRDB
 DB Server
 DB Server
 DB Server
 DB Server
 database
 共有ストレージデータ管理
 table
 table
 index
 index
 　 
 サーバの冗長化
 ストレージを共有
 SQL
 SQL
 SQL
 SQL
 ログ
12. © 2022 TIS Inc. 12
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
13. © 2022 TIS Inc. 13
 RDBとNewSQLについて
 RDB NewSQL アーキテクチャ（例） •横方向にスケール（限度あり） •縦方向にスケール（限界はHWの性能） •横方向にスケール（ノード追加） CAP定理(※) CA（+P） CP（+HA） クエリ SQL SQL Read スケーラビリティ 〇 ・リードレプリカ ◎ ・ノード追加 ※レプリケーション遅延なし Write スケーラビリティ 〇 ・マルチマスター ・シャーディング ◎ 分散アーキテクチャ (大きい1テーブル対応可) Primary
 スケールアップ
 見かけ上は単一DB
 スケールアウト
 スケールアウト
 ↓R/W
 ↓R/W
 コンピューティングノード
 ストレージノード
 ↓R/W
 Primary
 ↓R/W
 ・・・
 ※CAP定理とは、以下の３つを同時には満たせないという定理。 　一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance） スケールアウト
 Primary

14. © 2022 TIS Inc. 14
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
15. © 2022 TIS Inc. 15
 TiDBとは
 ストレージノード
 
 データストアレイヤー ( TiKV Cluster )
 
 コンピューティングノード 
 
 SQL解析レイヤー ( TiDB Cluster )
 
 TiDB クエリの増加 
 ノード追加で対応 
 TiDB TiDB 負荷分散・領域管理 
 3ノードのみ必要 
 TiDB TiKV TiKV TiKV TiKV 容量拡張
 ノード追加で対応
 TSO / Data Location
 Metadata
 PD PD PD MySQLプロトコルでデータベースと対話
 Raftを採用したKVSでバックアップを兼ね備える
 TiDBの司令塔
 ( Placement Driver )
 ①スケールアウト型のNewSQLデータベース
 ②マルチプラットフォーム可能、フルマネージドサービスも(TiDB Cloud)
 ③OLTPとOLAPを一つのDBで（HTAP）*今回は未検証

16. © 2022 TIS Inc. 16
 TiDBとは
 ストレージノード
 
 データストアレイヤー ( TiKV Cluster )
 
 コンピューティングノード 
 
 SQL解析レイヤー ( TiDB Cluster )
 
 TiDB TSO / Data Location
 Metadata
 TiDBの司令塔
 ( Placement Driver )
 - MySQLプロトコルをKV形式に変更 - Optimization - joinではhash joinや、sort merge joinを使うな どの判断。HTAP用途においては、TiKV(row型)かTiFlash(cloum 型)が良いか判別 - 分散Key-Value StoreとしてRocksDBにデータを保存。ログ用・データ保 存用の２つのインスタンスを保持。 - 96MBを1つのRegionとする、レンジによるパーティショニングによる分散 方式。 - 3面コピーによるデータ冗長性。障害時のデータの一意性などは Raftモ ジュールによって実現。 - Region管理（どのRegionがど のKVノードに保存されているか） - 分散トランザクションなどで使用 するTSOを発行 ①スケールアウト型のNewSQLデータベース
 ②マルチプラットフォーム可能。フルマネージドサービスも
 ③OLTPとOLAPを一つのDBで（HTAP）*今回は未検証

17. © 2022 TIS Inc. 17
 TiDBとは
 TiDBにおけるデータレイアウトのイメージ 
 ・Region（96MB）単位で管理
 ・データは3面コピーされている
 ・リーダーに対してIOが行われる 
 
 TiKVノード① Region 3
 フォロワー
 Region 1
 リーダー
 Region 2
 フォロワー
 TiKVノード② Region 3
 フォロワー
 Region 1
 フォロワー
 Region 2
 リーダー
 TiKVノード③ Region 3
 リーダー
 Region 1
 フォロワー
 Region 2
 フォロワー
 例：ユーザーテーブル
 データサイズは、デフォルト96MB 
 ※小さいサイズにする事で柔軟性を確保
 １つの読込/書込ポイント（リーダー） 　と　 2つのバックアップ（フォロワー）
 96MB 
 96MB 
 96MB 

18. © 2022 TIS Inc. 18
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
19. © 2022 TIS Inc. 19
 
 TiDBの大きな特徴
 　　　　　　オンラインでのスケーラビリティ　ですが、
 
 
 決済ネットワークシステムの要件
 　　　　　　　何があっても止めてはいけない　が大前提。
 
 検証

20. © 2022 TIS Inc. 20
 検証
 今回の検証では、
 現行システムにおいて必達であるDB領域の高可用性に軸足を置いて検証 
 1 超ミッションクリティカル 高可用性 (対障害性) 今後予想されるトランザクションピーク時において、 TiDBにノード障害が発生した場合の可用性 （挙動やNewSQL独自の特性など）を確認する 2 高いセキュリティ セキュリティ ※TiDBCloudはPCIDSSを遵守している。 3 サービスレベルを満たす性能 性能 現システムの3倍程度のQPSがさばけるかを確認する。 （あわせて、耐障害性及び拡張性試験での基本構成を定める） ４ 柔軟な拡張性 拡張性 スケール時のサービス影響有無を確認する。 また、現行DBでは拡張時に大きく工数をかけていることから、 スケール時の操作性や運用性についても確認する。
21. © 2022 TIS Inc. 21
 検証

22. © 2022 TIS Inc. 22
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
23. 23
 検証　– 性能 結果
 あるシステムの最大トランザクション量の3倍量以上は、本構成で対応可能 JdbcRunner
 SQLタイムアウト：10秒
 同時接続数：400
24. © 2022 TIS Inc. 24
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能
 – 耐障害性 – 拡張性 • まとめ、今後の展望
25. © 2022 TIS Inc. 25
 検証　- 耐障害性
 【試験概要】
 
 • ３つのコンポーネントに対してそれぞれ負荷掛け中にノードを１台落とす
 ※PDはTiKVのRegionと同様にリーダーとフォロワーのノードがあるため、それぞれ実施 

26. © 2022 TIS Inc. 26
 検証　- 耐障害性
 JdbcRunner実行条件 • Script filename : scripts/sysbench.js • Number of agents : 400 • Connection pool size : 400 • records pre-table : 10000000 • tables : 32 • Connection life time : 300秒 • JDBC params: useSSL=false&autoReconnect=true&maxReco nnects=4 &connectTimeout=1000&socketTimeout=100 00 トランザクションの内訳 • Point select : 10 • range select: 4 • Insert : 1 • Delete: 1 • Update index : 1 • Update non-index : 1 【実施条件 - ベンチマークツール】 
 
 • トランザクションの内訳（select/insert比率）やTimeout値(10s)などは とあるシステム を模倣 

27. © 2022 TIS Inc. 27
 検証　- 耐障害性
 【結果サマリ】
 許容出来そう
 ・サービスへの影響は短時間かつ限定的（性能劣化/応答遅延）
 対象 コンポーネント 障害影響時間 障害時影響 所感 TiDB 約3分間 性能劣化 ・ TPSが最大で約 13.57% 低減 (2.58K→2.23k) TiKV 約3秒間 応答遅延 ・Slowクエリ10秒以上が4件（最大10.4秒） ・TPSゼロあり（1秒）※3秒間性能劣化 PD-Follower ー 影響なし PD-Leader 約15秒間 応答遅延 ・Slowクエリ10秒以上が477件（最大14.9秒） ・TPSゼロあり（約10秒）※15秒間性能劣化
28. © 2022 TIS Inc. 28
 検証　- 耐障害性
 【結果：TiDB】TPS低減　→　障害時を見越したコンピューティングノード数で構成 
 対象 コンポーネント 障害影響時間 障害時影響 TiDB活用に向けた対策 TiDB 約3分間 性能劣化 ・TPSが最大で約 13.57% 低減 (2.58K→2.23k) ・障害直後に通信エラーが一部発生 ・TiDBノード数を障害時バッファを見込んだ構成にする 　（そもそも試験の構成がギリギリ過ぎた） ・通信エラーに関しては、 　アプリ側の実装としてリトライ処理や、べき等性のある実装は必要 障害時も想定したノード数で構 成しておく
 約3分間
29. © 2022 TIS Inc. 29
 検証　- 耐障害性
 【結果：TiKV】応答遅延　→ Timeout値は検討 
 対象コンポーネント 障害影響時間 障害時影響 TiDB活用における対策 TiKV 約3秒間 応答遅延 ・TPSゼロあり（1秒）※3秒間性能劣化 ・Slowクエリ10秒以上が4件（最大10.4秒） ・実アプリと疎通して検証のうえ、アプリ側で Timeout値 　およびTiKVパラメータ調整を業務/アプリ要件を踏まえ検討 約17分間 約3秒間
30. © 2022 TIS Inc. 30
 検証　- 耐障害性
 【補足】応答遅延が発生する背景と対策 
 TiKV TiKV TiKV TiKV障害時の挙動
 
 ハートビートによりTiKVノード障害を検知すると、 
 Region-フォロワーのいずれかがリーダーに昇格することで 
 IOが継続される仕組み 
 フォロワーがリーダーに昇格するまでの時間、がひとつのポイント 
 ・TiDB Cloud：TiKVパラメータの調整 
 ・アプリ：Timeout値の検討 
 TiKVノード別のRegion-リーダーの数 
 昇格（リーダ） 

31. © 2022 TIS Inc. 31
 検証　- 耐障害性
 https://docs.pingcap.com/tidb/dev/tikv-configuration-file#tikv-configuration-file 
 変更パラメータ 説明 今回設定値（デフォルト） raft-election-timeout-ticks RaftによるRegion-Leaderの選挙開始時に引き渡される tickの数。 Raftグループにリーダーがない場合は、 raft-base-tick-interval*raft-election-timeout-ticksの時間間隔の後に リーダーの選挙が開始される。 3 (10) raft-heartbeat-ticks ハートビートが送信されるときに渡される tickの数。 raft-base-tick-interval*raft-heartbeat-ticksの時間間隔で ハートビートが送信されます。 1 (2) raft-max-election-timeout-ticks RaftによるRegion-Leaderの選挙開始される最大 tick数。 数値が0の場合、raft-election-timeout-ticks*2の値が使用されます。 5 (0) raft-store-max-leader-lease Region-Leaderの最長信頼期間。 2s (9s) raft-base-tick-interval Raftステートマシンがtickする時間間隔。 1s (1s) 【補足】TiKVのパラメータ調整　※Region-リーダー昇格（選挙）に関連 

32. © 2022 TIS Inc. 32
 検証　- 耐障害性
 【結果：PD-Leader】応答遅延　→ Timeout値は検討 
 対象コンポーネント 障害影響時間 障害時影響 TiDB活用における対策 PD-Leader 約15秒間 応答遅延 ・Slowクエリ10秒以上が477件（最大14.9秒） ・TPSゼロあり（約 10秒）※15秒間性能劣化 TiDB Cloud次期アップグレードで障害時影響短縮化が見込める →実アプリと疎通して検証していきたい 約30秒間 約15秒間
33. © 2022 TIS Inc. 33
 検証　- 耐障害性
 【補足】応答遅延が発生する背景 
 PD-リーダー障害時の挙動 
 トランザクションでTiDBがPD-リーダーより TSO(Time stamp Oracle)取得 
 ①PD-新リーダーへの昇格(再選挙) 
 ②トランザクションのTSO取得 →この処理の応答待ちが発生 

34. © 2022 TIS Inc. 34
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
35. © 2022 TIS Inc. 35
 検証　- 拡張性 事前 スケール アウト TiDB 4台 5台 TiKV 3台 6台 JdbcRunner
 SQLタイムアウト：10秒
 同時接続数：400
36. © 2022 TIS Inc. 36
 検証　- 拡張性
 【結果：TiDB】拡張時の性能劣化、応答遅延なし 
 レイテンシー

37. © 2022 TIS Inc. 37
 検証　- 拡張性
 【結果：TiKV】拡張時の性能劣化、応答遅延なし 
 レイテンシー
 レイテンシー

38. © 2022 TIS Inc. 38
 検証　- 拡張性
 【補足】TiKV拡張時の挙動
 Read I/O
 Write I/O
 Region Leader
 約15分
 約15分
 約15分

39. © 2022 TIS Inc. 39
 検証　- 拡張性
 【評価】
 ・拡張中の挙動について、応答遅延や性能劣化なし
 ・容易な拡張ができた
 As-Is To-Be • 予め大きなシステムを構築することが必須
 
 • CPUやメモリの増設など、HWの拡張
 
 • DBの拡張 • 必要に応じて拡張作業を都度実施できる
 
 • 速やかな拡張
 
 → 不確実なサイジングからの解放 

40. © 2022 TIS Inc. 40
 Agenda
 • 会社・事業部紹介 • 決済ネットワークで求められる要件 • 決済ネットワークにおける昨今の課題感
 • これまでを支えてきたRDB • RDBとNewSQLについて • TiDBとは
 • 検証 – 性能 – 耐障害性 – 拡張性 • まとめ、今後の展望
41. © 2022 TIS Inc. 41
 まとめ、今後の展望
 TiDBの評価
 
 ・耐障害性
 　十分実用に足ると評価 
 　現行システムで利用しているDBと同等の可用性と障害時影響時間を満たす事ができた。 
 
 ・性能
 　今後トランザクション量が増える中でも対応できると評価 
 
 ・拡張性
 　現行システムと比較して拡張準備に要する工数を大幅に減らすことができ、 
 　不確実なサイジングを不要としたシステム開発が可能 
 
 ・コスト
 　トランザクション量の増大に対しても有効の候補であると評価 
 　 5年間でかかるコスト：使用料ベースの試算で、 
 　　　　　　　　　　　　TiDBは現行システムの約 ５分の１程度に抑えることが期待できる。 
 

42. © 2022 TIS Inc. 42
 まとめ、今後の展望
 今後のアクション 
 アプリケーションを交えた継続評価を実施。
 
 ・障害試験における停止時間（TPSが0の時間）は 
 　アプリケーション領域のリトライ設定、タイムアウト値の適正化などで 
 　影響時間の更なる低減が見込める。 
 
 ・より実用を加味した運用/保守のツールの評価 
 
 ・TiDBへの移行する際の負担について検証する。 

43. THANK YOU

44. 44
 Appendix

45. © 2022 TIS Inc. 45
 リードレプリカ
 マスター(更新用)
 リードレプリカ
 （Read専用）
 レプリケーション
 リードレプリカ
 （Read専用）
 レプリケーション
 更新用SQL
 参照用SQL
 参照用SQL

46. © 2022 TIS Inc. 46
 パーティショニングとシャーディングの違い
 Vertical partitioning（パーティショニング）
 Horizontal partitioning（シャーディング）
 DATE NAME 2020/1/1 中野 2020/5/1 世田谷 DATE NAME 2021/1/1 品川 DATE NAME 2022/3/1 目黒 2022/9/1 足立 2020年 2021年 2022年 DATE NAME 2020/1/1 中野 2020/5/1 世田谷 2021/1/1 品川 2022/3/1 目黒 2022/9/1 足立 DATE NAME 2020/1/1 中野 2022/3/1 目黒 DATE NAME 2020/5/1 世田谷 2022/9/1 足立 DATE NAME 2021/1/1 品川
47. © 2022 TIS Inc. 47
 LSMツリー(Log-Structured Merge-tree)
 メモリ上とディスク上に木が存在し、 
 直近の処理はメモリ上の木で管理。 
 
 メモリ上の木の大きさがしきい値を超えると 
 ディスク上の木にメモリの葉を移す。 詳しくはこちら参照してみてください。 
 https://nryotaro.dev/posts/lsmtree/