NewSQLは金融システムのミッションクリティカルで高セキュリティな要件に応えられるか？ TISが評価結果を明らかに［PR］

今回は「NewSQLは金融システムのミッションクリティカルで高セキュリティな要件に応えられるか？ TISが評価結果を明らかに［PR］」についてご紹介します。

関連ワード（指摘、接続、障害等）についても参考にしながら、ぜひ本記事について議論していってくださいね。

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

「NewSQL」と呼ばれる、新しい世代のデータベース製品が登場してきています。

NewSQLは、現在主流となっているリレーショナルデータベース製品と同様にリレーショナルなデータ構造に対応し高度なオンライントランザクション能力を備えつつ、NoSQLデータベースで実現されているような高いスケーラビリティ性能も備えています。

その代表的な製品の1つがPingCAP（ピンキャップ）社がオープンソースで開発している「TiDB」（タイデービー）です。商用のソフトウェアとして、またクラウドサービス「TiDB Cloud」としても提供されています。

TiDBは、アプリケーションからMySQLと同様にアクセスできるMySQL互換のプロトコルを備えています。そして内部構造はSQL文を処理する「TiDB」とデータを処理する「TiKV」に分かれ、それぞれが動的にスケールアウト／スケールインに対応するため、実行中でも性能の拡大と縮小が可能です。

OLTPとOLAPの両方に対応し、1つのTiDBクラスタで600TB以上のデータ容量、1つの分散テーブル内で数兆行のデータを扱えるとされています。

金融トランザクションにNewSQLが使えるか検証してみた

このTiDBの持つ性能やスケーラビリティ、耐障害性などが、ミッションクリティカルで高セキュリティを要求する金融トランザクションの分野で使えるものなのかどうか。

金融分野で45年以上の経験を持つTIS株式会社。同社のカードネットワーク基盤ソリューション部の石原賢人氏による検証内容を発表するセッション「金融トランザクションにNewSQLが使えるか検証してみた」が、株式会社インサイトテクノロジー主催のイベント「db tech showcase 2022 Tokyo」（2022年11月16日から18日まで開催）で行われました。

同社のカードネットワーク基盤ソリューション部はクレジットカードの決済ネットワークを担当しており、日本のキャッシュレス基盤を支えていると石原氏は説明します。

「決済ネットワークにおいては24時間365日、システムの停止や誤動作があってはならず、大規模災害時に備えたシステム設計も必須となります。また、クレジットカード業界の国際的なセキュリティ基準であるPCI DSSの遵守をはじめとする高いセキュリティの実現も求められつつ、当然ながら大量のトランザクションを高速に処理できる性能も要求されます」（石原氏）

同社で現在稼働しているシステムの1つは、ピーク時には約1万9500QPS（Query Per Second：1秒当たりのクエリ数）に到達しているとのこと。

加えて石原氏は「昨今の課題感として捉えているのが柔軟な拡張性とコストバランスの確立です。従来のリレーショナルデータベースですと、ノードの増減やハードウェアのスケールアップなどの拡張作業が大変で、データベースを構築する立場としては限界を感じています」と、高可用性や高性能でありつつ、柔軟なスケーラビリティや高いコストパフォーマンスも求められるようになってきていると指摘しました。

「そこで、将来的に低コスト化を実現するための次世代ソフトウェアの筆頭として、今回TiDB Cloudを検証させていただきました」（石原氏）

検証の結果、果たしてTiDBは要件に応えられたのでしょうか？

結論を先に書いてしまうと、TiDBは同社の決済ネットワークで求められる性能、セキュリティ、耐障害性、拡張性などすべての面で、十分実用に足る、あるいは対応できると評価されました。

その上で、同社の現行システムと比較してコストを約5分の1程度に抑えることが期待されると、コスト面での高い評価も得たのです。

検証結果のポイントを、石原氏のセッションから見ていきましょう。

検証項目とシステム構成

検証は以下のスライドにある4項目で、特にデータベースの高可用性に軸足が置かれています。2つめのPCI DSSについてはTiDB CloudがPCI DSSの遵守を実現しているため、今回の検証作業には含まれませんでした。

検証に用いたシステムはAWS上に構築されました。Amazon EC2のインスタンスで負荷テストツールであるJdbc Runnerを実行。同じくAWS上のTiDB CloudにVPC Peeringで接続し、その挙動を観測しています。

現システムの3倍程度のQPSにも十分対応可能

最初の検証は性能面について。ここでは現システムの3倍程度のQPSに対応できるかどうかが検証されました。

「その結果、（SQL解析レイヤーの）TiDBが4台、（データストアレイヤーの）TiKVが3台あれば、現システムの3倍程度のQPSをさばくことができました」（石原氏）。

この構成を基本として、次の耐障害性に関する検証が行われました。

高可用性、耐障害性の検証

高可用性の観点では、今後予想されるトランザクション量を流した状態でTiDB Cloudの各ノードに障害が起こったときの挙動や特性が確認されました。

具体的には、負荷テストツールでデータベースに負荷をかけたまま、主要なコンポーネントであるSQL解析レイヤーのTiDBのノード、データストアレイヤーであるTiKV、そして全体を管理するクラスターであるPD Clusterのノードをそれぞれ1つ落とし、その挙動を観測しています。

PD Cluster内には、役割が異なるリーダーのノードとフォロワーのノードが存在するため、それぞれのノードを落としたときの挙動も観測しました。

結果のサマリは以下のようになっています。

TiDBノードを落としたときは約3分間、最大で13.57％の性能劣化。TiKVノードを落としたときは約3秒間、最大で10秒程度の応答遅延。PD Clusterのノードを落としたときには、リーダーでは最大で約15秒間の応答遅延、フォロワーでは影響なし。となりました。

石原氏は、「TIDBノード障害時の性能劣化については、TiDBノード数をあらかじめ障害時も想定したノード数とすることで障害時影響を低減できます。TiKVノード障害については、今回TiDBの一部パラメータを変更することで、サービスレベルを概ね満たせる解決策があることがわかりました。PDノード障害についてはTiDBの次回のアップグレードで、障害影響時間の短縮が予定されています」と付け加えた上で、これらの耐障害性の結果について、サービスへの影響は短時間かつ限定的で、許容できそうだと評価しました。