金融業界のミッションクリティカルなシナリオでTiDBを活用（パート1）

※このブログは2021年3月30日に公開された英語ブログ「Using TiDB in Mission Critical Scenarios of the Financial Industry (Part I)」の拙訳です。

著者: Jun Yu (solution architect at PingCAP)

トランスクリエーター: Ran Huang; エディター: Tom Dewan

金融業界、特に銀行には、複雑なトランザクションに対応できる堅牢なシステムが必要です。テクノロジーが発展する中、コアバンキングシステムが、従来の中央集権型システムから分散型サービス指向アーキテクチャ（SOA）へと進化してきています。

オープンソースの分散型SQLデータベースであるTiDBは、銀行、セキュリティ会社、保険会社、オンライン決済会社、フィンテック企業の間で幅広く採用されています。また、各ユーザーは、20種類以上のミッションクリティカルなビジネスシナリオでTiDBを有効活用しています。

この記事では、金融業界におけるクリティカルなビジネスシナリオや、金融業界が最新テクノロジーを利用する際に直面する問題点について解説します。その後、こうした問題点に取り組むための、3つのTiDBソリューションを紹介します。

金融サービスにおけるデータベースの利用方法

銀行のビジネスは複雑です。コアバンキングビジネス（アカウンティングや決済業務）から周辺ビジネス（預金、ローン、両替）まで、さらにはインターネット指向の金融ビジネスが含まれます。

将来の成長を促進するため、多くの銀行がトランザクションアプリケーションおよびリアルタイム分析アプリケーションやデータ処理レイヤーに分散テクノロジーを導入し始めています。また、コアバンキングシステムにクラウドコンピューティング、マイクロサービス、サーバーレステクノロジーを導入しようと試みています。

データベースは、分散型アーキテクチャ内で重要な役割を担っているため、以下のような厳しい要件を満たしていなければなりません。

• 安全性、安定性、信頼性が高い。
• 分散型コンピューティングと分散型データ管理に対応しているとともに、柔軟性の高いオンライン拡張性を備えている。
• 同時実行性が高くかつ遅延が少ない、高スループットを実現できる。
• オンライントランザクションと日時バッチ処理のハイブリッドワークロード、データ報告やデータ送信のワークロード、信頼性とパフォーマンスが高い分散オンライントランザクションをサポートしている。
• 複数のデータセンター（DC）内へのデプロイをサポートしている（最低限2つの都市に3つのDC）。複数のデータセンターを使用したディザスタリカバリを行う。RPOが0である。RTOが、当局と銀行が求める高可用性要件を満たしている。
• コアビジネスアプリケーションの開発やリファクタリングの妨げとならない。
• メンテナンスと管理を簡単に行うことができる。

従来型データベースの問題点

現在、大部分の銀行が、コアバンキングシステムのデータベースソリューションとして、従来型の集中型データベースやMySQLベースのシャーディングソリューションを利用しています。しかし、集中型データベースには以下の短所があります。

• 専用のハイエンドハードウェアに大きく依存している。
• 水平方向にスケールアウトできない。
• 実装とメンテナンスにかなりのコストがかかる。
• DB2データベースやOracleデータベースによるテクノロジーロックインに陥る可能性がある。
• 次世代の分散型SOAとシームレスに連携できない、またはクラウドコンピューティングのメリットを得られない。

MySQLベースの分散型データベース、つまりMySQLシャーディングソリューションにも以下の限界があります。

• 分散ミドルウェアの成熟度や信頼性が不十分である可能性がある。
• シャーディングはアプリケーションに対して影響を与えるなので、多くのコード変更が必要になる。
• アプリケーションモデルとデータモデルが結合しているため、アプリケーションの柔軟性が低い。
• バッチ処理スケーリング機能、柔軟なスケーリング機能、オンラインでの自動バランシング機能に限界がある。
• 分散トランザクション、厳密な整合性、高可用性の確保が難しい。
• ディザスタリカバリプランの導入が複雑である。例えば2つの都市の3つのセンターにわたってクラスタをデプロイすることや（1つの都市に1つの稼働センターと1つのディザスタリカバリセンターをデプロイ、もう1つの都市に1つのディザスタリカバリセンターをデプロイ）、1つの都市内で複数のアクティブセンターを利用することなど。

TiDBベースのコアバンキングソリューション

TiDBは、ハイブリッドトランザクション/分析処理（HTAP）ワークロードに対応した、オープンソースのNewSQLデータベースです。MySQLとの互換性を持ち、水平方向の拡張性、厳密な整合性、優れた可用性を備えています。TiDBは現在、北米、中国、日本、東南アジアの金融業界はもちろん、世界中の非金融企業によって幅広く利用されています。

現在のTiDBでは、以下の3つのコアバンキングシステムソリューションを利用できます。

• TiDBをプライマリデータベースとして利用する。
• TiDBをバックエンドに置きながら、MySQLを利用してオンライントランザクションを処理する。
• TiDBをバックエンドに置きながら、MySQL（ユニット化アーキテクチャ）を利用してコアトランザクションを処理する。

下表は、従来の集中型ソリューション、MySQLベースのソリューション、TiDBベースのソリューションを比較したものです。各カテゴリー内で、パフォーマンスが最も優れているものは太字になっています。

ソリューション	従来の集中型ソリューション	MySQLベースの分散型ソリューション	TiDB（コアデータベース）	MySQL（プライマリ） + TiDB（バックエンドコアデータベース）
オンライントランザクションのスループット	ハードウェアリソースによって制限される	高、スケーラブル	高、スケーラブル	高、スケーラブル
オンライントランザクションの遅延	低	低	中または低（負荷によって左右される）	低
バッチ処理	ハードウェアリソースによって制限される	低	高	高
集計クエリ	高（集中型アーキテクチャ）	低	高（リアルタイムクエリ）	高（リアルタイムクエリ）
必要なアプリケーション変更	最小限度の変更	大幅な変更。データベースはアプリケーションロジックに対して侵入的	最小限度の変更。データベースはアプリケーションに対して透過的	最小限度の変更。プライマリデータベースは各ユニットに分割される。バックエンドデータベースはアプリケーションに対してトランスペアレント
拡張性	低	静的スケーリング	動的スケーリング	動的スケーリング
拡張の柔軟性	低	低	高、オンラインスケーリング	高、オンラインスケーリング
可用性の高さ	高	中（プライマリ-セカンダリ複製）	高（Raftに基づいた厳密な整合性）	プライマリデータベース（プライマリ-セカンダリアーキテクチャ）、バックエンドデータベース（Raftに基づいた厳密な整合性）
ディザスタリカバリ	同一都市と別の都市の両方でのディザスタバックアップ	中（プライマリ-セカンダリ複製）	高（Raftとスケジューリングに基づいた厳密な整合性）	高（Raftに基づいた厳密な整合性）、TiDB（バックアッププラン）
ビルドコストとメンテナンスコスト	高	低ビルドコスト、高メンテナンスコスト	低	低

TiDBをプライマリデータベースとして利用

このソリューションでは、TiDBをコアバンキングシステムのプライマリデータベースとして利用します。TiDBはアプリケーションに対して透過的であるため、アプリケーションやデベロッパーはTiDBを従来型スタンドアロンデータベースと同じように利用することができます。そのディテールはアプリケーションに対して透過的です。ソリューションのアーキテクチャを下図に示します。

コアトランザクションアプリケーションが成長すると、トランザクションはアカウントディメンション内だけでなく顧客ディメンション内でも実行されるようになります。したがって、単にデータベースをアカウントごとにシャーディングしただけでは、ビジネスの柔軟性が失われてしまいます。TiDBを利用すれば、アプリケーションモデル、データモデル、トランザクションモデルを手動でシャーディングする必要がなくなります。

さらに、TiDBにビルトインされたマルチアクティブディザスタリカバリメカニズムにより、デプロイ、管理、コストがシンプル化されます。TiDBの分散トランザクションモデルでは、アプリケーションロジックを追加する必要がなく、ユーザーはスタンドアロンデータベースと同じようにTiDBを利用することができます。TiDBは動的スケジューリングメカニズムを備えており、オンラインサービスにインパクトを与えることなく、各ノードをスケールアウトすることができます。

要約すると、TiDBをコアトランザクションシステムのプライマリデータベースとして利用すれば、以下のメリットが得られます。

• コアトランザクションデータベースを改良する際に生じる複雑さとリスクが軽減される。
• アプリケーションモデルやデータモデルをデータベースアーキテクチャに適応させる必要がない。
• コンピューティングとストレージが透過的分散されているため、メンテナンスコストを削減できる。
• スループットとパフォーマンスを水平方向にスケーリングすることができる。
• TiDBは標準的なSQL構文、分散トランザクション処理、HTAPワークロードに対応している。バンキングビジネスの柔軟性を確保し、分散型コアアプリケーションに適応できる。
• コアシステムは厳密な整合性、高可用性（RPO = 0、RTO < 30秒）、マルチデータセンターディザスタリカバリに対応している。

TiDBは、多くの市中商業銀行のコアトランザクションシステムに簡単に統合できるように開発されています。TiDBは、Sunlineコアバンキングシステムの必須モジュール、すなわちアカウント、負債、ローン、クレジットカード発行、キャッシュ管理および資産残高モジュールに完全に適合しています。TiDBは、機能性、正確性、パフォーマンスの面で最適化されており、約200回のバッチ処理テストを含む2,000回以上の機能テストをパスしています。

次のステージでは、当社はSunlineとパートナーを組み、TiDBを新しいコアバンキングシステムとARMベースプラットフォーム上でテストすることになっています。

TiDBをバックエンドに置きながら、MySQLを利用してオンライントランザクションを処理

2番目のソリューションは、以下に示すとおり、オンライントランザクション処理（OLTP）にMySQLクラスタを用い、オンライン分析処理（OLAP）にTiDBを用いるというものです。

コアトランザクションアプリケーションは、アプリケーションロジックに基づいて分割されています。データ処理では、以下の3つのステップを踏みます。

1. ユーザーが、基本的なOLTPワークロードをMySQLとその分散データベースミドルウェアで実行する。
2. 変更データキャプチャ（CDC）ツールがデータをMySQLシャードからTiDBに準半リアルタイムで複製する。
3. TiDBがMySQLのバイナリログを変換し、そのデータを分散クラスタにマージする。TiDBクラスタがバッチ処理、複雑なコンピューティング、複雑なリアルタイムクエリを実行する。

TiDBをバックエンドに置きながら、MySQL（ユニット化アーキテクチャ）を利用してコアトランザクションを処理

先程説明したソリューションと同様に、コアトランザクション向けにMySQL、バックエンド向けにTiDBを置きます。異なる点は、各アプリケーションが別々のマイクロサービスやユニットに分割されることです。

• カスタマーセンター、プロダクトセンター、アカウンティングセンターの3つのサービスは、他のすべてのトランザクションで利用される。これらのサービスは、トランザクションシステムから個別のユニットに分割することができる。
• 預金システムやローンシステムなどのオンライントランザクションやアカウントサービスは、アプリケーションロジックを分割することによって、別々のユニットに分割できる。これにより、アプリケーションレイヤーを水平方向にスケーリングすることができる。
• また、シェアードサービスセンターをトランザクションシステムから分離し、マイクロサービスレイヤーに統合させることもできる。シェアードサービスセンターは、各モジュールがそのサービスを呼び出すための標準的インターフェースを備えている。

このアーキテクチャでは、複数のデータベースがコアデータベースに対応しています。TiDBは、コアバンキングシステムのバックエンドデータベースとして働き、CDCによってグローバルデータベース（カスタマーセンター、プロダクトセンター、アカウンティングセンター）からすべてのデータを取り込みます。

シャーディングされたデータベースの場合で、それがアプリケーションレイヤーで垂直方向に分割されているときは、CDCによって、データをTiDBのグローバルデータベースに集約することができます。グローバルデータベースでは、複数のサービスユニット間で、複雑なクエリやレポーティングなどのバッチ処理オペレーションを実行できます。一方、各サービスを共有しているデータベースは、依然としてTiDBクラスタ内で、分離性のあるロジカルデータベースとして存在し、各アプリケーションにサービスを提供します。

WeBankの新世代コアシステムアーキテクチャ

ユニコーン企業であるWeBankは、中国のネオバンクです。そのミッションクリティカルなシステムで、このソリューションを利用しています（詳細については、こちらのケーススタディを参照してください）。

WeBankは、コアバンキングシステムのユニット化でイノベーションを実現しました。過去4年間、データセンターノード（DCN）をベースとした、拡張可能な分散型フレームワークを採用し、コアトランザクション処理を行ってきました。同行は、アプリケーションレイヤーを簡単に拡張できるほか、シンプルなデータベースレイヤーを維持することができます。

DCNとは、フル機能を持つロジカル「銀行」を言います。多くのDCNが連携し、実際の銀行業務をサポートします。銀行の支店などの独立した組織は、DCNを水平方向にスケーリングすることによって、ビジネスの成長に対応することができます。また、WeBankは、MySQLシャーディングをベースとしたオンライントランザクションデータベースを利用しています。また、各トランザクションをアカウンティングから分離させています。分散型データベーステクノロジーを応用することによって、バッチ処理とアカウンティングのオペレーションをバックエンドデータベース（分散クラスタ）に転送しています。

TiDBを利用する理由

TiDBをバックエンドデータベースとして利用すれば、以下のメリットが得られます。

• MySQLベースの分散プランにおいて、コンピューティングとデータ処理のためにデータを集約するという課題を解決できる。
• 標準的なSQL構文、分散トランザクション、マルチテーブルの複雑な結合オペレーションに対応することによって、大量データをノード間で高速にバッチ処理できる。
• TiDBのHTAPアーキテクチャには、行ベースのストレージエンジンとカラムベースのストレージエンジンの両方があるため、リアルタイムコンピューティングを容易に実行できる。
• データの完全な増分複製のためのツール一式を利用できる。オンラインデータベースからデータをリアルタイムで複製できるとともに、いつでもTiDBをバックアッププランとして利用できる。
• TiDBのスループットとパフォーマンスを水平方向にスケーリングすることができる。
• TiDBのカーネルによって、厳密な整合性、高可用性、マルチデータセンターによるマルチアクティブディザスタリカバリメカニズム（RPO = 0、RTO < 30秒）がサポートされている。

また、TiDBは、コアバンキングシステムなどのミッションクリティカルなシステムに今後対応するための準備も整っています。TiDBはクラウドネイティブであり、Kubernetesで動作させることができます。したがって、パブリッククラウドとプライベートクラウドで実行するための基盤が築かれています。TiDBは最近、OpenShiftやRancherなどの一部のクラウドインフラストラクチャプラットフォームに対応できるようになりました。TiDBのクラウドリソーススケジューリング機能によって、クラウド内のマルチテナンシーを実現することもできます。

また、TiDBでは行ストアとカラムストアが1つのアーキテクチャで結合されるため、将来のアプリケーションにスムーズに移行することができます。さらに、TiDBをApache Flinkに連携させることによって、ストリーム処理ソリューションを開発し、リアルタイムデータ処理を強化することができます。

最後に、TiDBでは、データをデータセンター間で配置することができます。マルチセンターアーキテクチャにより、データをデータセンターと動的に関連付け、ロケーションに応じてデータテーブル間の関連付けを確立することができます。これにより、サイト間リクエストと遅延が低減します。さらに、コールドデータからホットデータを分離し、それらを柔軟にスケジュールすることができます。

金融業界におけるTiDBの活用例をもっと知りたい方は、当社のSlackチャネルに参加していただくか、今後のブログ投稿に引き続き注目してください！