データベース開発のギャップを越え、分散データベース技術の動向について議論する

[[269004]]

1. 金融業界におけるアーキテクチャ変革の需要

モビリティとインターネットの継続的な発展に伴い、わが国の金融業界のビジネスモデルとテクノロジーシステムは、徐々に西洋諸国とはまったく異なる道を歩み始めました。周知のとおり、欧米諸国の携帯電話普及率は我が国よりはるかに低く、人口基盤も桁違いに異なります。その結果、国内金融業界と海外金融業界が直面する業務の種類、データ量、同時実行性に大きな違いが生じ、IT インフラストラクチャ全体に対する要求がまったく異なることになります。

過去 1 ～ 2 年、中国の技術的に先進的な銀行のいくつかは、マイクロサービスと分散技術の探求を主導しており、いくつかの新しく設立されたインターネット金融ビジネスも、アプリケーションの開発と保守にマイクロサービス アーキテクチャ、分散技術、DevOps フレームワークを使用する実験を始めています。将来的に増大するビジネスプレッシャーとデータ量に対応するために、次世代のコアシステムアーキテクチャを計画する際に、分散アーキテクチャを適切に導入しようとする銀行も出てくるでしょう。

新世代の分散アーキテクチャと比較すると、ミドルウェアとデータベースを組み合わせた従来の「煙突型」アーキテクチャでは、膨大なデータ、高い同時実行性、高い応答速度を備えたビジネス アプリケーションに対応する際に多くの問題が発生します。

• 業務部門やシステムの観点から見ると、業務が複雑になると企業内に多数の分散したシステムが存在し、データは完全に分離され共有できなくなります。
• このシステムは柔軟な水平スケーラビリティに欠け、パフォーマンスのボトルネックが明らかで、ハードウェアのボトルネックが発生しやすいため、弾力的な拡張というビジネス ニーズを満たすことができません。
• システムは、突発的に発生する大量のリクエストに迅速に対応できません。例えば、ダブルイレブンやフラッシュセールなどのビジネスによる瞬間的な爆発的な成長に対応することは困難です。
• 調達、運用、保守にかかるコストが高い。ミニコンピュータ機器とソフトウェアおよびハードウェアは別々に購入および保守されるため、総所有コストが高くなります。
• 自主的な管理能力がなく、海外メーカーへの依存度が高いため、深刻な問題が発生した場合、現地のサポートチームが短期間で問題を解決することが難しく、生産および運用のリスクが増大します。

II.銀行構造の進化

過去約 20 年間で、我が国の銀行の IT アーキテクチャはいくつかの段階の変化を経てきました。私の国の第一世代の銀行コアシステムはメインフレーム上に構築され、典型的な大規模な集中型アーキテクチャを採用していました。

SOA コンセプトの導入により、一部の銀行はメインフレームから徐々に離れ、コアビジネスシステムをメインフレームまたは 400 から UNIX ミニコンピュータに移行し始めました。仮想化技術の強化により、一部の銀行や金融機関では、インフラストラクチャに仮想化メカニズムを導入し、開発環境や一部の運用環境アプリケーションを仮想マシン上に展開できるようになりました。

現在、多くの銀行が分散型および PC サーバー アーキテクチャに基づくビッグ データ プラットフォームを構築しており、マイクロサービス システムに基づく一部のアプリケーションでは、ビジネス ロジックをコンテナー化し、バックエンドの分散ストレージおよびデータベース テクノロジと組み合わせて、エンドツーエンドの分散アーキテクチャ システムを実現しています。

多くの銀行の技術部門が、コアシステムを集中型から SOA に移行する際の困難さを経験してきたように、現在のミニコンピュータ システムから分散アーキテクチャへの移行も、テクノロジー スタックの選択、アプリケーション開発、DevOps システムの構築など、大きな課題に直面しています。

アプリケーション開発が従来のアーキテクチャから分散アーキテクチャに移行するにつれて、最初に変換されるのは当然、アプリケーション フレームワークです。今日のマイクロサービス フレームワークはすでに非常に成熟しており、その代表的なアーキテクチャには、プロトコル処理、サービス アセンブリ、アトミック サービス、基盤となる永続性の 4 つのレイヤーが含まれることがよくあります。ビジネス ロジックは、従来の単一のミドルウェアから多数のマイクロサービス モジュールに分割されます。各マイクロサービス モジュールは、完全に同等のコンテナーのシリーズで構成されます。コンテナを追加するだけで、サービスのスループット処理能力を拡張できます。

ただし、マイクロサービスを分割すると、各サービスが独自の独立した実行ロジックとストレージを持つことになります。データベースの観点から見ると、マイクロサービス システムの分割はデータベース ストレージに大きな課題をもたらします。各マイクロサービスが依然として従来の単一ポイント データベースにデータを保存している場合、マイクロサービス コンテナーの数が増えても、そのストレージおよび処理機能は同等のスケーラビリティを提供できなくなります。この場合、データベースはマイクロサービス システム フレームワークのパフォーマンスとスケーラビリティを制限する最大のボトルネックになります。

各マイクロサービスがストレージに独立したデータベースを使用すると、エンタープライズ IT 全体のデータ アーキテクチャが断片化されます。データベースの数は数百から数万にまで分割され、運用保守チーム全体の管理コストやデータベース調達コストが指数関数的に増加しています。

したがって、分散データベースの目的は、従来の Oracle または DB2 の単一の代替品として機能することではなく、複数の物理マシン上の 1 つのデータベースに保存できないデータを保存することです。実際の環境では、ほとんどの銀行は比較的完全なデータライフサイクル管理戦略を採用しており、通常、運用環境では大量の履歴データが蓄積されることはありません。したがって、一般的に、データの量は分散データベースを使用する最も重要な理由ではありません。

3. 分散データベースアーキテクチャシステム

分散データベースの核となる価値は、分散アプリケーションに柔軟かつスケーラブルなデータ サービス リソース プールを提供することにあり、これは DBPaaS プラットフォームとも呼ばれます。

その主な機能は、さまざまな開発者、さまざまなビジネス タイプ、さまざまな SLA セキュリティ レベル、さまざまなデータ タイプからの何万ものマイクロサービスに対して、弾力的にスケーラブルで、応答性が高く、保守が容易なデータベース サービス プラットフォームを提供することです。同時に、高可用性構成、災害復旧戦略の定義、マルチテナント、ビジネス データの論理的および物理的な分離、トランザクション分析のハイブリッド モード分離、異なるマイクロサービス データ間のホット データとコールド データの分離など、一連のデータ分離およびガバナンス メカニズムをサポートする必要があります。

マイクロサービス アーキテクチャを採用しているインターネット企業の中には、数十万の異なるデータベース インスタンスをサポートできる 20 人以上のデータベース運用および保守チームを擁しているところもあります。運用保守の中核は、企業向けの統合 DBPaaS プラットフォームを構築することです。これにより、分散データベースの自己修復や弾力的な拡張などのメカニズムを通じて、運用保守担当者によるデータベースの管理が大幅に簡素化されます。

業界には多くの分散データベース製品があり、主に 3 つのアーキテクチャ システムに分けられます。

1. 垂直分割を適用する

垂直アプリケーション分割は、最も伝統的な分散概念です。実装方法の 1 つは、アプリケーションを複数の独立したサブサービスに分割し、各サービスを全体のデータの一部に対応するようにすることです。別の実装方法は、1 つのサービスで複数のデータベースを接続し、アプリケーション内のビジネス ルールに従ってデータ ソースを選択することです。たとえば、アプリケーションはユーザー アカウント ID に従ってセグメント化されます。 ID が 1 から 100 万までのユーザーはデータベース A に保存され、ID が 100 万から 100 万から 200 万までのユーザーはデータベース B に保存されます。

このメカニズムは、アプリケーションにルールを事前設定します。データにアクセスするたびに、まずターゲットが配置されているデータベース インスタンスがルール ベースからフィルター処理され、次にアクセス用の接続が直接取得されます。

一方で、このメカニズムを使用すると、データベース間のトランザクションを実装することが非常に困難になります。一方、アプリケーションの観点から見ると、分散機能のビジネスは非常に侵襲的であり、基本的なビジネス ロジックを完成させるには多くのカスタマイズされた開発が必要になります。同時に、各拡張ではアプリケーション ロジックの完全なエンドツーエンドのレビューが必要となり、多くのリスクと二次的な開発作業が伴う可能性があります。

2. ミドルウェアのサブライブラリとサブテーブル

分散ストレージ機能の必要性が高まるにつれ、ミドルウェア ライブラリとテーブル シャーディングと呼ばれる別のタイプの技術システムが業界で徐々に登場してきました。このタイプの技術システムの考え方は、アプリケーションとデータベースの間に SQL パーサー サービスを構築し、従来の SQL を解析して、基礎となる各データベースに対応するサブクエリに変換し、クエリを基礎となる従来のデータベースに直接送信して実行することです。

このメカニズムの利点は、データ ストレージは従来のリレーショナル データベースをそのままベースに維持できる一方で、上位層はアプリケーション インターフェイス用にある程度カプセル化されることです。しかし、業界全体の観点から見ると、サブライブラリとサブテーブルのミドルウェアの仕組みは、従来のシングルポイントデータベースから分散データベースへの移行段階であると考えられます。

PC サーバー上に構築された新しい分散データベースが普及する前に、緊急にデータ分割が必要な一部のアプリケーションでは、この方法を使用して、急増するビジネスおよびデータ量のプレッシャーを軽減できます。しかし、将来、ネイティブ分散データベースが成熟し、検証されると、その利点を維持することは難しくなります。

同時に、このテクノロジはアプリケーションに対して 100% 透過的になることはできません。一般的に、アプリケーションで SQL を組み立てる際には、いくつかのパラメータを指定したり、より独特な構文を使用したりする必要があるため、アプリケーションに対して完全に透過的で知覚できないものにすることは困難です。

3. ネイティブ分散データベース

ネイティブ分散データベースは、ミドルウェアデータベースやテーブルシャーディング技術とは異なり、PC サーバーをベースとした基盤ストレージエンジンから直接再構築され、データストレージ構造、データセキュリティメカニズム、分散トランザクション制御など、複数の領域で分散ストレージと実行に最適化されています。

ネイティブ分散データベースは、ミニコンピュータ システムを完全に放棄して、最下層から完全にゼロから開発されます。これは、PC サーバー ハードウェア アーキテクチャに基づいて設計された分散データベースであり、高可用性、災害復旧、分散などのメカニズムをデータ ストレージ システムのすべての側面に自然に統合します。

たとえば、一部の分散データベース製品では、MySQL と 100% 互換性がありながら、アプリケーションに対して完全に透過的な分散ストレージおよび実行機能を実現できます。開発者の観点から見ると、ユーザーはテーブルに数億件または数十億件のレコードが含まれているかどうかを心配する必要はありません。テーブルの作成時に容量と最大物理リソース消費戦略が構成されている限り、データはクラスター内の複数の物理デバイス間で自動的に分散されます。アプリケーションの観点から見ると、標準テーブルにアクセスするのと同じように、読み取りおよび書き込み要求が直接行われます。

4. ネイティブ分散データベース技術の動向

将来の IT マイクロサービス フレームワークをサポートするには、分散トランザクション データベースの導入を、従来のテクノロジとの互換性と新しいテクノロジの先見性という 2 つの側面から評価する必要があります。

ACID サポートと SQL 整合性サポートは、新しい分散データベースが従来のデータベース テクノロジとの互換性を提供できるかどうかを評価するための 2 つの重要な指標です。

1) ACIDサポート

セキュリティの観点からは、新しいテクノロジーが使用されるか従来のテクノロジーが使用されるかに関係なく、データが正確であり、失われないことを保証することは、すべてのデータベースにとって不可欠な基盤です。

分散データベース業界では、インターネット技術向けに設計された一部の製品で、分散性 (Partition Tolerance) と高可用性 (Availability) の実現を目指しています。しかし、セキュリティや一貫性（Consistence）の観点からデータの正確性を保証することはできず、金融サービスで広く利用することは困難です。

したがって、銀行が懸念している新しい分散データベースでは、まずデータのセキュリティと一貫性を確保する必要があります。分散トランザクション、分散ロック、および 4 つの分離レベルのサポートは、すべてこの指標の重要な技術的ポイントです。

2) SQL整合性のサポート

SQL 整合性とは、新しい分散データベースと従来のリレーショナル データベースの開発のしやすさを指します。

分散データベースが成熟するほど、SQL 構文と従来のリレーショナル データベースの互換性が高まり、データ セグメンテーションがアプリケーションに対して透過的になります。現在、ほとんどの分散データベース テクノロジは MySQL 構文をサポートしていると主張しており、主流の新しいアプリケーションも、サポートされるデフォルトのデータベース オプションとして MySQL を使用しています。したがって、MySQL 構文プロトコルのサポートの強さは、分散データベースの SQL 整合性サポートを判断する鍵となります。

新しいテクノロジーの先見性とは、分散データベースが将来の開発方法や IT アーキテクチャと一致しているかどうかを指します。

3) 分散型で柔軟な拡張機能

データ サービス リソース プールとしての分散データベースは、上位層のマイクロサービスの種類と数を継続的に増やすために、弾力的にスケーラブルである必要があります。同時に、各マイクロサービスについて、そのデータが 1 つの物理デバイスに保存されるか、複数の物理デバイスに保存されるかは、アプリケーション コードに対して完全に透過的である必要があります。

4) マルチモードエンジン

さまざまな開発者、さまざまなビジネス シナリオ、さまざまなデータ タイプからの上位層マイクロサービスを提供するには、分散データベースで複数の SQL プロトコルとコンピューティング エンジンをサポートする必要があります。ストレージ エンジンの観点から見ると、構造化データと半構造化データの両方がアプリケーションで同時に使用される可能性があります。したがって、新世代の分散データベースでは、アクセス インターフェイスからストレージ構造まで、マルチモデル エンジンをサポートする必要があります。

5)HTAP(ハイブリッドトランザクション/分析処理)

HTAP は、ハイブリッド トランザクション分析および処理機能の略です。従来の銀行 IT アーキテクチャでは、オンライン取引システムと統計分析システムでは異なるテクノロジーと物理的な機器が使用されることが多く、定期的に実行される ETL を通じてオンライン取引データが分析システムに移行されます。データ サービス リソース プールとして、同じデータがさまざまな種類のマイクロサービスによって共有され、アクセスされる可能性があります。

一部のオンライン トランザクションと監査サービスが同じデータに対して同時に実行されている場合、トランザクション分析サービスが妨害されないように、リクエストが完全に分離された物理環境で実行されるようにする必要があります。

一般的に、分散データベース技術の動向は、従来の技術の互換性と新しい技術の先見性という 2 つの側面から判断する必要があります。 ACID データ セキュリティと SQL 整合性は、従来のテクノロジの互換性の重要な指標であり、一方、弾力的なスケーラビリティ、マルチモード エンジン、および HTAP は、新しいテクノロジの先見性を示す重要な基準です。

5. 金融分散データベースの応用シナリオ

現在の金融業界では、分散データベースは、データ ウェアハウス、ビッグ データ プラットフォーム、コンテンツ管理プラットフォーム、データ ミドル プラットフォーム、オンライン トランザクションの 5 つの主要領域で使用されています。オンライン分散データベースの使用に関して、業界では現在 3 種類のビジネス シナリオに重点を置いています。

1) オンライン取引システム

オンライン取引システムは銀行にとって重要な生産・運用環境です。

分散技術の探求の最前線に立つ我が国の銀行の中には、いつでも発生する可能性があるビジネスの成長のニーズに合わせてクラスターを柔軟に拡張できるように、コアビジネスプロセスシステムを IBM や Oracle のメインフレームやミニコンピュータのアーキテクチャから分散環境に徐々に移行し始めているところもあります。分散データベースを使用する一般的なシステムとしては、オンラインローンコア、チャネル統合、クレジットカードポイントなどがあります。

2) データセンター

現在、多くの企業がミドルオフィスに重点を置き、フロントオフィスを無視した IT アーキテクチャを提案しています。データミドルプラットフォームは、企業のITデータ統合の重要なプラットフォームとして、柔軟で変化に富んだフロントエンドのビジネスニーズと、比較的固定されたバックエンドのデータモデルを組み合わせ、「フロントエンドとバックエンド間のデータの集約と接続」の役割を果たします。たとえば、銀行はまず、過去の取引請求書の照会と印刷から始めて、ユーザー ポートレートや資産ビューなどの準リアルタイム データ サービスに徐々に拡張することで、生産システムのスリム化を目指すことができます。

3) コンテンツ管理プラットフォーム

従来のコンテンツ管理プラットフォームは、主に事後監視や監査を目的として構築されており、フロントエンドビジネスは基本的に非構造化データの利用に直接関与することはありません。セルフサービスデバイスやモバイルアプリケーションの普及に伴い、ますます多くのプロセス処理に非構造化データの直接的な参加が必要になります。

そのため、多くの銀行ではコンテンツ管理プラットフォームもバックエンドからフロントエンドに移行しています。多数の顧客アプリケーションがコンテンツ管理プラットフォームに直接接続されています。口座開設、クレジット、さらにはセルフサービス機器などの一部のプロセスは、コンテンツ管理プラットフォームのリアルタイムのインタラクション機能に大きく依存しており、コンテンツ管理システムは従来の内部バックエンド監査から外部オンライン サービスに移行しています。

分散データベースは、銀行のオフライン分析ビジネス シナリオで長い間広く使用されてきたことがわかります。オンラインビジネスに関しては、MPP データ ウェアハウスとビッグ データ プラットフォームは、信頼性、同時実行性、応答速度の面で要件を満たすことができません。

IV.まとめ

現在、分散技術に関する徹底的な研究を行った一部の銀行では、分散データベースの試験的な適用を開始しています。分散データベースの本質的な価値は、従来のデータベースに保存できないデータを複数の物理デバイスに分散して保存することだけではありません。より重要なのは、さまざまな開発者、さまざまな SLA レベル、さまざまな高可用性と災害復旧機能、さまざまなビジネス タイプからのデータに対応する、将来のマイクロサービス アプリケーション開発モデルのための弾力的なスケーラビリティとマルチモード インターフェイスを備えたデータ サービス プラットフォーム (DBPaaS) を提供することです。

現在の技術担当者がよく尋ねる質問: 将来、分散データベースは Oracle に取って代わることができるでしょうか?

この質問に対する答えは非常に直感的であると言えます。分散アプリケーション フレームワークと PC サーバー クラスタリングは、IT 開発の将来の方向性となるはずです。また、マイクロサービスが煙突型ソフトウェア アーキテクチャに取って代わり、必然的にデータベースを従来の「ポイント」からプラットフォームの「表面」に転送する必要が出てきます。

各アプリケーションには対応する反復サイクルがあります。今日では、多くのアプリケーションが、デフォルトでサポートされているデータベース オプションとして MySQL などのオープン ソース データベースを使用し始めていることがわかります。将来的には、Oracle を使用する必要があるシナリオはますます少なくなります。

したがって、将来的には、分散データベースが Oracle などの従来の単一ポイント データベースに取って代わることは避けられません。銀行の技術部門は、チムニーモデルからマイクロサービスへと移行する銀行の IT アーキテクチャの将来のトレンドに適応するために、分散データベース技術に関する将来を見据えた研究をできるだけ早く実施する必要があります。