何百万人もの顧客にパーソナライズされた魅力的なコンテンツを提供するスケーラブルなデジタル バンキング ソリューションを構築するには、さまざまな技術的課題が生じます。Moneythor ソリューションの最新のデジタル バンキング テクノロジー スタックを使用して、これらの課題にどのように取り組んでいるかをご覧ください。
—
Moneythorでは、常にデザイン、開発、再定義を行っています。 デジタルバンキングプラットフォーム 世界中の金融機関のニーズに応えます。当社のソリューションは、データ ソースと顧客向けデジタル バンキング チャネルの間に位置し、高度にパーソナライズされた魅力的なエクスペリエンスをリアルタイムで提供する、完全に構成可能なオーケストレーション エンジンとサービスです。
私たちの使命は、堅牢なソリューションを構築するだけでなく、研究開発に投資し、従来のアーキテクチャの限界を超えて、より適切に拡張し、大量のデータをリアルタイムで処理および分析するなどの新しい困難なユースケースに対応することです。
各ソリューションにはそれぞれ長所と短所があります。特に、レガシーネットワークとディスクでシステムを実行し、CPUとメモリのコストを抑えていることを考えると、アラン・チューリングの時代まで遡ることなく、Moneythorソリューションが扱う問題の特性は、オンライントランザクション処理という2つの明確なカテゴリに分類されてきました。 (OLTP) およびオンライン分析処理 (OLAP).
OLTP
Moneythor ソリューションは、金融機関の記録システムとデジタル チャネルの間に展開されるエンジンを提供し、エンド ユーザーにとって魅力的でカスタマイズされたエクスペリエンスを実現します。そのため、当社のソリューションは、信頼性が高くスケーラブルな方法で大量のデータをリアルタイムで処理できることが期待されています。
リレーショナル データベース管理システム (RDBMS) は、ACID 準拠という非常に貴重な利点も提供するため、このような OLTP システムを実装するための効率的で信頼性の高い方法であることが歴史的に証明されています。
当社のソリューションには以下も含まれています パーソナル・ファイナンシャル・マネジメント (PFM) 予算、目標、サブスクリプションなどのパーソナライズされたオブジェクトを作成、読み取り、更新、削除できるAPIによって駆動される機能。したがって、当社のAPIを呼び出すデジタルチャネルが無条件に応答を信頼できることが重要であり、そのために当社のソリューションは、 原子性, 一貫性, 分離 そして 耐久性 RDBMS であるかどうかに関係なく、データベースの (ACID) プロパティ。
- 原子性 API 呼び出しによって要求されたすべての変更が全体として正常に完了することを保証します。つまり、応答が成功した場合は、要求されたすべての変更が処理されたと信頼でき、応答が成功しなかった場合は何も処理されないと信頼できます。3 つの予算を作成するために API を呼び出すと、0 または 3 つの予算が作成されますが、1 つまたは 2 つだけになることはありません。
- 一貫性 データベースの内部一貫性が維持されます。API 呼び出しは、たとえキャンセルされたとしても、データベースが望ましくない状態になることはありません。目標を削除する API を呼び出すと、目標自体だけでなく、その依存関係も常に削除されます。
- 分離 複数の API を同時に呼び出すことができ、呼び出しが 1 つずつ処理された場合と同じ結果になることを保証します。予算を作成するための API と目標を変更する API を同時に呼び出すと、両方の API がこれらの変更をすべて考慮して処理されます。すべての RDBMS は、この目的で何らかのロック メカニズムを使用しますが、Moneythor はデータベースのデッドロックを回避するために楽観的ロック アプローチを選択したことは特筆に値します。
- 耐久性 APIが成功した応答を返した後、障害が発生した場合にデータが失われないことを保証します。HTTP経由のAPIでは、ネットワーク障害が発生した場合にクライアントが応答をまったく受け取れないという一般的な問題が発生します。そのため、Moneythorは 冪等性 重複を作成するリスクなしにクライアントが再試行できるようにします。
OLAP
Moneythor ソリューションは、データに基づく洞察、推奨事項、各顧客に合わせたナッジの提供を可能にします。ここでソリューションの分析部分が活き活きと輝き、お客様は顧客に対して幅広いコンテキストに基づいたパーソナライズされたナッジを思い描くことができます。
このようなデータ分析は通常、そのタスクに最適化された OLAP システムに依存しており、OLTP と OLAP の両方に基づいてソリューションを構築しようとすると、摩擦が生じる可能性があります。
OLAP システムは、データでできることを賢く行う一方で、データが大きく変更されない場合にうまく機能します。これは、1 日に何百万ものトランザクションをリアルタイムで受信し、その時点でデータ分析が行われることが予想されるデジタル バンキング ソリューションでは一般的なシナリオではありません。また、データはユーザー自身によって変更される可能性があり、パーソナライズされたナッジに関しては、まったく異なる結果につながる可能性があります。
OLAP システムは、必ずしも応答時間の速さを最優先に設計されているわけではありませんが、Moneythor API 上に構築された新しいユーザー エクスペリエンスは HTTP 経由で提供されるため、同期されます。最近では、画面がレンダリングされるまでに数秒以上待つと、永遠のように感じられます。
分散システム
これらの制約を考慮して、Moneythor ソリューションは両方のタイプのシステムの長所を活用し、以下の特性を持つ分散アーキテクチャを通じてそれらの欠点を軽減します。
私） メリットが冗長性と追加処理のコストを大幅に上回る場合、永続ストアのデータはケースバイケースで非正規化されます。これにより、分析処理時間を制御しながらトランザクション データの処理を継続できます。
ii) Moneythorソリューションは他のシステムの間に位置し、分散イベントストリーミングプラットフォームとネイティブに統合されます。たとえば、 アパッチカフカ は非常に人気のツールであり、Moneythor ソリューションと組み合わせることで、全体的なパフォーマンスが大幅に向上し、実装とスケーラビリティが簡素化されます。これは、両方のシステムが設計上分散されているためです。API は上記の ACID プロパティに大きく依存し、応答を保証しますが、メッセージのストリームに関しては、Kafka やその他のツールでは通常、メッセージが配信される場合とされない場合がある、メッセージが複数回配信される可能性がある、メッセージが正確に 1 回配信される、という 3 つの異なるメッセージ配信モードが提供されます。最初のモードは、金融取引を扱う場合には明らかに不適切であり、「正確に 1 回」の配信を求めるのは魅力的かもしれませんが、これには追加のパフォーマンスと複雑さのコストがかかります。この理由と、Moneythor のメッセージはべき等であるため、当社のソリューションは「少なくとも 1 つ」の配信コンセプトに基づいて構築されています。これにより、メッセージが失われないことが保証され、消費者はべき等フラグのおかげで重複を簡単に制御できます。
ii) 最後に、分散システムについて議論する際には、 キャップ そして パチェルク 定理。最初の定理は、分散データ ストアは次の 3 つの保証のうち 2 つしか提供できないと述べています。
一貫性 (C): 現在のコンテキストでのすべての読み取り、すべての API 呼び出しは、データの最新バージョンまたはエラーを受け取ります。
可用性 (A): すべての API リクエストは (エラーではない) 応答を受け取りますが、最新のデータが含まれているという保証はありません。
パーティション耐性 (P): ノード間のネットワークによって任意の数のメッセージがドロップ（または遅延）されても、システムは動作を継続します。
ほとんどの場合、Moneythorソリューションは、データベースの論理インスタンスが1つしかない環境に導入されます（このデータベースシステムは通常、高可用性のためにクラスターで実行されます）。このコンテキストでのパーティションの数は1ですが、システムが一貫性と可用性の両方を同時に提供できると考えるのは間違いです。実際、パーティションがない場合、PACELC定理は、次のどちらかを選択する必要があると述べて、これらのルールを洗練させます。 レイテンシー （土地 一貫性 （C）。
Moneythor ソリューションは、処理能力を追加することで垂直方向に拡張し、クラスターにインスタンスを追加することで水平方向に拡張するように設計されています。また、最適なユーザー エクスペリエンスを実現するために、応答時間を可能な限り短くして、エンド ユーザーに豊富なインタラクティブ機能を提供するために使用されるフロントエンド API のセットを公開します。
これらの理由から、このソリューションはレイテンシに最適化されています。API が ACID モデルに依存していると述べた後では特に、この選択は直感に反するように聞こえるかもしれませんが、ここでは一貫性の定義が異なり、API によって操作および計算されるデータには適用されません。API はどのような場合でも一貫性を保つ必要がありますが、最新のデータがいつ利用可能になるか (即時または最終的に) を決定します。
逆に、一貫性を第一に目標とすると、ソリューションではメモリ内キャッシュを使用して処理と API 応答時間を高速化するため、システムはクラスター内の多数のインスタンスが同期されるまで待ってから応答を返す必要があります。その場合、クラス最高のネットワークと CPU があっても、ファーストクラスの応答時間を保証することは非常に困難です。
基本的に、同期されていないデータを読み取るリスクを大幅に減らすために実装できる単純な原則があります。 1 つの例は、現在のコンテキストのデータがすでに処理され、キャッシュされている同じインスタンスにクラスター内のリクエストをルーティングする、適切に構成されたロード バランサーです。
結論
トランザクション データと分析データを組み合わせた、拡張性に優れたリアルタイム ソリューションを構築するには、提供できる機能、期待される応答時間、そしてもちろん、そのようなシステムの導入と運用にかかるコストの間でトレードオフが必要になります。
分散型および非中央集権型アーキテクチャの構築は複雑になる可能性があり、その特性を理解して約束を守る必要があります。同時に、テクノロジーは進化しており、特にクラウド プラットフォームでは、高性能コンピューティングがますます利用しやすくなっています。これが、当社がこの方向性を選択した理由であり、現在ではあらゆる規模のデジタル バンクや金融機関のデータ主導のパーソナライゼーション ニーズにうまく対応できるようになりました。
Moneythorのソリューションと当社のテクノロジーの詳細については、 お問い合わせ.
