決済システムにおけるTiDB導入の検証とその効果 - SBペイメントサービス株式会社 - TiDB User Day 2023

イベント開催日：2023年7月7日
講演者：SBペイメントサービス株式会社　システム運用統制部 推進課
　　　　前島 竜太郎 氏

本スライドでは、SBペイメントサービスがなぜTiDBの検証に至ったかの背景やTiDBを選択した理由、検証までの流れとその結果についてそれぞれ紹介します。SBペイメントサービス社がTiDB検証を行うきっかけとなった背景である課題や要件についてお話しした後、検証にあたって考慮したTiDB特有のポイントについて決済システム目線でお話しします。その後、検証を行った結果を元に、TiDBのパフォーマンスやスケーラビリティ、運用の容易さなど、様々な面で得られた知見を共有させて頂きます。分散DBを利用したい、TiDBを利用するにあたってのポイントやどのように検証すればいいかを知りたいといった方々に本スライドが少しでもお役に立てれば幸いです。

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

Transcript

1. 決済システムにおけるTiDB導⼊の 検証とその効果 SBペイメントサービス株式会社 前島 竜太郎 TiDB User Day Tokyo 2023 2023/07/07
2. ⾃⼰紹介 前島 ⻯太郎(@dohq) 趣味は⾃宅でサーバーを作ったり壊したり 現在の業務 : インフラ‧プラットフォームの 構築‧運⽤‧改善を担当 2
3. アジェンダ • 会社紹介 • NewSQLを検証した背景 • 弊社が求めた要件 • 検証内容 • 検証結果のピックアップ • まとめ 3
4. 会社紹介 - SBペイメントサービス 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電⼦書籍/動画 決済サービス 全て⼀本化 チケット クレジット 携帯キャリア決済 コンビニ⽀払い プリペイドカード ⼝座振替 ポイント⽀払い アカウント連携 当社 当社 API型 オンライン決済サービス 画⾯リンク型 ECサイト向けに様々な決済⼿段を提供 加盟店に決済APIを提供するシステム 4
5. 会社紹介 - SBペイメントサービス API型 画⾯リンク型 加盟店 決済機関 通販サイト ゲーム 教育 不動産 その他 電⼦書籍/動画 決済サービス 全て⼀本化 チケット ECサイト向けに様々な決済⼿段を提供 加盟店に決済APIを提供するシステム クレジット 携帯キャリア決済 コンビニ⽀払い プリペイドカード ⼝座振替 ポイント⽀払い アカウント連携 当社 当社 オンライン決済サービス 5 加盟店システムと決済機関システムの間に位置 する⾃社だけでは完結しないWebシステム
6. NewSQLを検証した背景 • ⽇々増加する取扱件数に対して障害、メンテナンス時の ダウンタイムによる影響が顕著に • 複雑化したクエリのチューニングの為DBAとのQAが増え 開発のリードタイムが増加 • NewSQLめっちゃ興味あった 6
7. 弊社が求めた要件 • ACID txをサポートしているDB • MySQL互換 • マネージド‧オンプレミス両⽅の環境構築が可能 • メンテ等での影響が限りなく少ない • 細かいチューニングをあまり気にしなくても性能が出る • スケールが容易 • 環境構築でterraform等IaCが出来る • ⼿厚いサポート 7
8. ＿人人人人人人人人人人人＿ ＞　TiDBいいじゃん！！　＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣ →という事でTiDBを選定 8
9. ざっくり検証項⽬ • 構築 ◦ Webコンソールの操作性 ◦ Terraform Providerの使い勝⼿ • 開発 ◦ 既存アプリを利⽤した互換性確認 ◦ 性能 • 運⽤ ◦ 監視 ◦ アップデート時の影響 ◦ 障害時の影響 9
10. 検証結果ピックアップ 既存のDBと同じ使い勝⼿を求めつつ、 更に現状の課題を解決出来るか確認したかった 為、特に以下の4点を重点的に検証しました • 既存アプリとの互換性 • クエリレスポンスタイムの変化 • アップデート時の影響 • 障害時の影響 10
11. 検証環境 API Gateway App 決済機関向け サービスApp 決済機関 モック ログ 配信⽤ キュー ログシッパー App 約20r/s Total 約300q/s HTTP 同 期 ⾮同期 Select Insert Update Insert amqp 11
12. 検証環境 TiDB Cloud 2 vCPU, 8 GiB x 2 2 vCPU, 8 GiB x 3 AWS Aurora for MySQL 2 vCPU, 16 GiB マルチAZ有効 Writer x 1 / Reader x 1 エンジンバージョン 5.7.mysql_aurora.2.07.8 12
13. 注意事項 我々が実施したTiDBの導⼊検証は、 あくまで我々の環境と要件に基づいて⾏われたものであり、 その結果が他の環境や状況において同様に適⽤できるという 保証はありません。 導⼊を検討する際には、必ずご⾃⾝の環境と要件に基づいた 検証を実施して下さい! 13
14. 検証結果ピックアップ • 既存アプリとの互換性 • 性能 • アップデート時の影響 • 障害時の影響 14
15. 検証対象のアプリケーションは 元々AWS Auroraで稼働していたが 既存のコードを⼀切変更せず にTiDB環境へ適応させる事が可能でした😊 検証結果(既存アプリとの互換性) 15
16. 検証結果ピックアップ • 既存アプリとの互換性 • 性能 • アップデート時の影響 • 障害時の影響 16
17. 検証結果(クエリレスポンスタイム) TiDB Aurora 平均 Select: 5ms Insert: 10ms Update: 13ms 平均 Select: 0.3ms Insert: 5ms Update: 5ms Select: 約16倍 Insert: 約 2倍 Update: 約 2倍 17
18. 検証結果(クエリレスポンスタイム) とはいえ… 例えば数億件を連続で捌くバッチシステムであれば クエリ速度の影響は顕著に出るが、 リアルタイムシステムであれば影響は無視しても問題無い 増加量だという結論になってます。 18
19. 検証結果ピックアップ • 既存アプリとの互換性 • 性能 • アップデート時の影響 • 障害時の影響 19
20. 検証結果(アップデート時の影響) Aurora DBに対する Connection reset により、5件の リクエストエラー DBインスタンス再起動時に起きた クエリ遅延によって、 3~15秒程のクエリ遅延が約60件発生 アクセスログ件数 リクエストレスポンスタイム リクエストレスポンスタイム 20
21. 検証結果(アップデート時の影響) TiDB リクエストエラーは 確認出来ず🥰 Auroraと同様に遅延は認められたが、 1~1.5秒の遅延が約20件と 突出した遅延にはならず アクセスログ件数 リクエストレスポンスタイム 21
22. 検証結果ピックアップ • 既存アプリとの互換性 • 性能 • アップデート時の影響 • 障害時の影響 22
23. 検証結果(障害時の影響) PingCAP Japanと連携し、擬似的な障害テストとして TiDB及びTiKVをそれぞれ1台づつ落として貰い検証を実施 23
24. 検証結果(障害時の影響) アップデート時と同じく、 リクエストエラーは無し! 24
25. 検証結果(障害時の影響) ・・・ 25
26. 検証結果(障害時の影響) TiDBを落とした際は影響無し しかしTiKVを落としたタイミングで ログシッパーアプリのInsert処理において 10秒以上のクエリ遅延が100件発生 26
27. 検証結果(障害時の影響) 後⽇PingCAP Japanへ確認をとったところ、 リーダーインスタンスから応答が無くなった際の 新しいリーダー選出インターバルが10秒となっている為 仕様どおりの挙動とのこと 障害時もロールバック等はおこらず、⼀部クエリの遅延のみ におさまるのはよくできている… 27
28. まとめ • TiDBは既存のRDBMSと⽐べても決して劣りはしない • CRUDしか利⽤していない場合既存コードに⼿は⼊れなくてよい🥳 • クエリのLatencyは⾼めなので向き不向きは考慮すべき • 各種試験時に1件もエラーが起きなかったのは驚き🎉 • ただしクエリの遅延は発⽣するのでアプリ側での リトライやタイムアウトなど適切なハンドリングは必要 • PingCAP(Japan)のサポートめっちゃいい🥰 28
29. まとめ ユースケースを想定した 事前検証は⼤事!!
30. ご静聴ありがとうございました