分散環境におけるコアバンキングシステムの構築

本ブログシリーズでは、分散環境でコアバンキングシステムを構築する際に生じる主要な技術的課題について考察します。第1回目となる今回は、初期のコアバンキングシステムが持つ主な特徴を探り、文脈を整理します。続いて、世紀の変わり目頃に登場した「第3の波」とも言えるバンキングシステムを取り上げ、当時の銀行が抱えていた課題をどのように解決しようとしたのか、そしてなぜ普及に苦戦したのかを分析します。最後に、1970年代に開発されたメインフレームを今なお運用している銀行が、危機的な状況から次世代システムへと移行するために必要な、システムの主要な特性を紹介します。

まずは、「コア」や「記録システム（System of Record）」とも呼ばれる、コアバンキングシステムの主要な機能について簡単に見ていきましょう。

Typical capabilities of a ‘core’ — 「コア」の一般的な機能

元帳（レジャー）：コアの心臓部であり、処理された取引の変更不可能なリストです。銀行における資金移動の「信頼できる唯一の情報源（ソース・オブ・トゥルース）」と見なされています。
口座：顧客口座に対応するものだけでなく、銀行保有口座や、ノストロ口座、ウォッシュ口座といった特殊な会計記録に対応するものも含まれます。元帳の各取引は、借方と貸方の両方の口座を参照します。
残高：コアはすべての口座の残高を計算します。コアの複雑さにもよりますが、単純な口座残高の管理から、資産、通貨、資金の隔離など、各口座内の多次元的な情報を追跡する高度な構造まで多岐にわたります。
プロダクトエンジン：コアが口座に対して行うあらゆる「プロダクト」に関する意思決定を包括する広義の用語です。最も単純なケースでは、特定の取引を元帳に追加してよいかどうかの判断（通常は残高チェックを伴う）を行います。プロダクトエンジンの範囲はコアによって異なり、利息計算から、複雑な処理ルールに基づいた口座間での資金移動（スイープ）まで、あらゆる処理が含まれます。

用語の定義は重複することも多いですが、一般的に銀行が「コア」と言う場合、これらの中心的な機能を指しています。また「コアバンキングシステム」と呼ぶ場合は、より広範な機能を含むスタック全体を指している可能性があります。市販の「バンク・イン・ア・ボックス」や「ブラックボックス」型のコアバンキング製品には、こうした広範なスタックが含まれていることが多く、現在、多くの銀行にとって、こうしたシステムの刷新がIT課題の中心となっています。

台頭する次世代コアバンキングシステム

コアバンキングシステムの進化を振り返ると、ある興味深い傾向が見えてきます。それは、銀行システムがソフトウェアアーキテクチャの新たな潮流を、ゆっくりと、しかし確実に追随しているという点です。現在市場に出回っている多くの銀行システムは、依然としてモノリシックなバッチ処理型アーキテクチャで構成されています。しかし、クラウドネイティブなマイクロサービスアーキテクチャ（分散環境とほぼ同義）という、ますます定着しつつある手法を取り入れた次世代システムが主流になるのは、時間の問題と言えるでしょう。

銀行業界の変革が他業界に比べて遅れている理由を理解するには、その出発点に目を向ける必要があります。1970年代前後に登場した「第一世代」のコアシステムは、何百年も続いてきた銀行業務のモデルを模倣するように構築されました。「うまく機能しているなら、あえて変える必要はない」という考え方は、当時としては理にかなっていたのです。

このモデルでは通常、午後5時に閉店する支店網が前提となります。閉店後、一日の締め処理が行われ、その結果が銀行の会計データの中心的なリポジトリである「総勘定元帳」に集約されます。第一世代のシステムが登場した際、顧客がどの支店でも取引できるようにするための統合ネットワークが不可欠でした。当時は安定したパブリックインターネットが存在しなかったため、サーバー間の通信は低速で信頼性に欠けていました。そのため、システムは一般的にクライアント・サーバーモデルで接続され、メッセージの到達を保証するために2相コミットプロトコルが使用されましたが、これが通信コストをさらに押し上げました。この問題を回避するため、銀行は主要なシステムとデータをすべて単一のメインフレームに集約しました。その結果、初期のコアバンキングシステムはモノリシックな構造となり、銀行の全支店からのクライアント・サーバーセッションを処理できる唯一の機器であった高価なメインフレーム上で稼働するように設計されました。

1980年代に入ると、消費者向け銀行業務は支店中心から脱却し始めました。第一世代のシステムは、ATMやコールセンターといった新たなチャネルをサポートするために拡張されました。これにより、これらの新しいチャネルやサーバー容量への需要増大に対応できる「第二世代」のシステムが登場しましたが、その基盤となるアーキテクチャはほとんど変わらないままでした。

銀行はこれらの初期システムに巨額の投資を行っており、その結果、今日の基準から見ても非常に高い回復力と、低レイテンシでの膨大なスループット処理能力を備えていました。今日でも多くの銀行がこれらのシステムを稼働させていることは、その成功の証です。しかし、重要なトレードオフも存在します。これらのシステムは運用コストが非常に高く、特に月末の精算処理といったピーク時の負荷に合わせてサイジングする必要があるため、稼働率の低い時間帯には高価なリソースが遊休状態になってしまうという課題がありました。

初期のシステムは長らく成功を収めてきましたが、現在、多くの銀行がコアシステムの刷新に注力し始めています。これは、多くの銀行が「燃え盛るプラットフォーム（危機的な状況）」の上で運用を続けていることを示唆しています。第一世代のコアシステムは70年代の銀行商品に合わせて設計されており、規制当局の要件や消費者のニーズは当時から大きく変化し、今もなお変化し続けています。CACIの2019年のレポートによると、英国では2500万人の顧客がモバイルバンキングアプリを利用しており、この社会的トレンドだけでも、継続的な変化への対応や、モバイルバンキング特有の不安定かつ24時間365日の稼働ニーズに応える必要性が高まっています。残念ながら、メインフレームに縛られている銀行にとって、システムの運用コストだけでなく、変更にかかるコストも非常に高額です。さらに、コスト削減への圧力も強まっており、状況はより深刻化しています。

第三世代

こうした課題に対応するため、世紀の変わり目頃から「第三世代」と呼ばれる新しいコアバンキングシステムが登場し始めました。これらのシステムは、銀行が直面していた多くの問題を解決しました。パラメータ設定可能な商品エンジンを備え、変更にかかるコストとリスクを低減しました。ウェブ/オンラインバンキングの普及の波に乗り、リッチなUI機能を備えることも多かったのですが、UIと密結合していることが多く、この柔軟性を新しい方法で活用することは困難でした。

これらのシステムは一般的に、よりモダンなプログラミング言語で記述され、アプリケーションサーバーにデプロイ可能であったため、銀行が高価なメインフレームから脱却する道を開きました。しかし、これらのアプリケーションは一般的にステートフルであり、セッション管理に依存していたため、垂直方向以外のスケーリングは困難でした。

この新しい波のコアバンキングシステムは、銀行が抱えていた多くの課題に対処したものの、いくつかの主要な問題は残りました。これらのシステムは依然としてバッチ処理が中心でモノリシックな構造であり、高価ながらも高性能なメインフレームから切り離されたことで、実際には 以前のシステムよりも 回復力やパフォーマンスが低下していることが見て取れます。これが、第三世代が普及に苦戦した理由かもしれません。ティア2銀行まではある程度の導入実績があるものの、ティア1市場への浸透は限定的でした。

これは大手銀行にとって問題となりました。コア刷新プロジェクトを前に進めることが困難だったからです。メインフレームからの移行というリスクを避けたい銀行は、レガシーコアの問題を回避するために、以下のような独創的な方法を見出しました。

「コアの空洞化（Hollow out the core）」は、急速に事実上の標準戦略となりつつあります。これは、商品エンジンやその他の主要機能をコアから切り出す手法です。その結果、銀行はよりモダンな製品を活用してレガシーコアの欠点を補うことができますが、一方で運用が複雑化し、統合の難易度が上がるという欠点があります。さらに、こうした戦術的なシステムが乱立することでデータサイロが発生し、データのマスター管理、出所管理、照合、証明といった面で追加のオーバーヘッドが生じることになります。
メインフレームにAPI「シム」を導入する手法です。一部の銀行は、メインフレームに直接ソフトウェアをインストールし、これまで抽出が困難だったデータをモダンなAPI経由で公開する道を選びました。PSD2やオープンバンキングの到来により、このアプローチの注目すべき実装例がいくつか生まれました。しかし、ここには危険なトレードオフがあります。基盤となるシステムには、結果として生じる不安定なワークロード量に対応できる弾力的なスケーリング能力がないため、銀行は意図せずして自社のコアシステムに対してDDoS攻撃を仕掛けてしまう可能性があるのです。

その結果、大手銀行はレガシーコアの周囲を近代化することで生き延びてきました。これは一時的には機能するかもしれませんが、避けられない事態を先延ばしにしているに過ぎません。死にゆくコアを抱えたまま生き残れる期間には限界があります。コアから切り出せば切り出すほど、中層システムに複雑さが蓄積され、データサイロ化が進み、システム全体の脆弱性が高まってしまいます。

世界金融危機の後、銀行は厳しい課題に直面し、綻びが見え始めました。市場で競争力のある銀行商品を維持するためにITインフラのコストを削減しつつ、変化する消費者の期待や、ますます厳格化する規制当局の要求に適応しなければならなくなったのです。後者の顕著な例が、バーゼル合意の第三次規制「バーゼルIII」の導入です。これは、日中の流動性管理の要件など、一日の締め処理を行う従来のバッチ処理モデルと真っ向から対立するように見える方法で、コアシステムの適応を銀行に強く求めています。

突然、銀行は互いに矛盾する二つの主要な課題に直面しました。インフラコストを削減するには、メインフレームを廃止してより軽量なインフラで運用する必要がありましたが、それはシステム処理能力の上限を下げてしまうことを意味しました。同時に、規制変更に適応するためにはバッチ処理の頻度を増やす必要があり、それにはより高い処理能力が必要でした。

さらに問題を複雑にしているのは、コアバンキングシステムが「コア元帳が閉じている時」にしか実行できないように設計されていることが多い点です。これには、バッチ処理とオンライン通信の間のリソース競合を避けるため、あるいは安定した（静的な）データセットに対して変換処理を実行するためなど、合理的な理由がいくつかあります。従来の銀行モデルは午前9時から午後5時までしか営業していなかったため、初期のシステムにおいてコアを停止させることは理にかなっていました。消費者の需要が変化し、24時間365日の銀行業務が当たり前になると、第三世代のシステムは、コアの停止時間を短縮したり、一日の締め処理への移行中に決済をバッファリングする「スタンドイン（代行）」モードで動作できるようにすることで適応しました。しかし、これには独自の複雑さが伴います。スタンドインを処理するために「銀行の中に銀行を作る」ような状況になり、翌営業日の開始時にスタンドイン元帳を統合するために多大な労力を費やすことになるのです。結局のところ、銀行の営業時間中にバッチ処理を継続的に実行することは、多くの場合現実的ではありません。

銀行が抱える既存のコアシステムの課題について検討してきた内容をまとめると、一つの共通した限界が浮かび上がります。それは、本質的にモノリス（単一構造）であるため、垂直方向へのスケーリングしかできないという点です。この構造は、変化への適応やコスト削減という観点において、銀行の俊敏性を根本から阻害しています。

幸いなことに、銀行には希望があります。私たちが直面しているのは、金融サービスの内外を問わず多くの領域で共通する問題であり、マイクロサービスベースのアーキテクチャによって解決の糸口が見えてくるものです。このようなアーキテクチャでは、システムの各パーツが動的にスケールイン・スケールアウトできるため、処理負荷に応じてアプリケーションを柔軟に拡張できます。同時に、影響を受けない部分は縮小させておくことで、システム全体のフットプリント（ひいてはコスト）を低く抑えることが可能です。その結果、マイクロサービスベースのアーキテクチャは、スケーラブルでリアルタイム性を重視した次世代のコアバンキングシステムへの道を切り拓きます。

では、なぜ第3世代のコアシステムは、既存のシステムをリファクタリングしてモノリスをマイクロサービスベースのアーキテクチャに分割しようとしないのでしょうか。

コアバンキングのモノリスを解体する

この問いに答えるには、モノリシックアーキテクチャの主な利点に目を向ける必要があります。モノリスには単一の物理クロックが存在するため、単一のグローバル（全体）な順序付けを容易に把握できます。この全体的な順序付けがあることで、リクエストの正確性を保証することが比較的容易になります。しかし、モノリスを分割すると共通のクロックが失われ、結果として順序付けも失われてしまいます。つまり、正確性を維持することが困難になるのです。アプリケーションのロジックは、ネットワーク遅延に起因する競合状態やボトルネックに対処するために、大幅なリファクタリングを迫られる可能性があります。システムを根本から完全に作り直さなければ、因果関係のあるイベントを正しい順序で処理しつつ、システムのスループットを大幅に犠牲にしないようにすることは、しばしば解決不可能な問題となります。さらに、「分散モノリス」を単に作り上げてしまうという罠に陥りやすく、結果として両方のパラダイムの最悪の特性を背負い込むことになりかねません。

クラウドへの移行か、クラウドファーストか

第3世代のシステムがモノリスの解体に苦戦し、市場から「クラウドへの移行」という圧力を受ける中で、ベンダーはしばしば「リフト＆シフト」戦略を採用します。これは、モノリシックなアプリケーションサーバーをコンテナ化し、クラウドにデプロイするという手法です。技術的にはクラウド戦略と言えますが、効果的とは言い難いでしょう。クラウドの利点を何一つ活用できていないからです。特に弾力的なスケーラビリティという恩恵は得られず、本質的には同じモノリスを、より高コストなデータセンターで運用しているに過ぎないのです。

こうした状況を踏まえると、クラウドの弾力的なスケーラビリティを最大限に活かし、マイクロサービスベースのアーキテクチャを採用してゼロから構築された、第4世代のコアバンキングシステムが登場する機は熟していると言えるかもしれません。

なぜ、まだ実現していないのでしょうか。

次世代のコアバンキングシステムがようやく現れ始めたばかりである理由として、いくつかの要因が考えられます。

銀行は一般的に動きが遅い組織です。歴史的に慎重な性質を持っており、管理するデータの重要性を考えればそれは理解できます。ITの変更にはリスクを軽減するために多くのガバナンスが伴いますが、それが意図せずして物事のスピードを遅らせるという副作用を生んでいます。
効果的な開発エコシステムと文化を組織的に育むには何年もかかることがあります。銀行は、COBOLのような主要なスキルが市場から失われつつあるというジレンマに直面しており、より現代的な開発エコシステムに焦点を当てた新しい社内チームを構築することは、長期的な取り組みとなります。
最近まで、規制当局はクラウドを十分に信頼しておらず、銀行がクラウドインフラを活用してスケーラブルなインフラへの参入障壁を下げることを阻んでいました。

しかし、私たちが考える最大の理由は、単に「分散環境で銀行システムを構築するのは難しい」という点に尽きます。

マイクロサービスベースのアーキテクチャを扱うということは、本質的に分散環境を扱うということです。つまり、幅広い遅延に対応しなければならないシステムを扱うことになります。システム内での処理の多くは、サービス間のネットワーク通信に費やされることになります。Gregg (2013) が例示したように、もしCPUサイクルが1秒かかるとすれば、サンフランシスコからニューヨークへのネットワークホップには4年もかかる計算になります。また、これは「分散コンピューティングの誤謬」に翻弄されることを意味します。前述した共通クロックの欠如に加え、リクエストが無限に遅延したり、完全に消失したりする可能性のある、信頼性の低いネットワークと向き合わなければならないのです。

他の多くの業界では、メッセージの多少の欠落や、時折発生する競合状態を許容できるかもしれません。しかし、銀行業務において正確性は最優先事項です。メッセージを一つでも失えば、顧客の残高が同期されなくなったり、多額の資金が消失したりするなど、あらゆる事態を招きかねません。

分散システムにおいて正確性を保証することは困難な課題であり、それゆえにマイクロサービスベースのコアバンキングシステムを構築することは非常に大きな挑戦なのです。

では、「第4世代」の勘定系システムとはどのようなものなのでしょうか。

次世代の勘定系システムは、クラウドファーストの考え方に基づいて構築されなければなりません。弾力的なスケーラビリティ、正確性を保証するメカニズム、そして極めて柔軟な構成変更機能が、設計の根幹に組み込まれている必要があります。こうしたシステムは、膨大なトランザクションを処理するためにスケールアウトできると同時に、アクティビティが低い時間帯には最小限のリソースで稼働するスケールイン機能も備えていなければなりません。また、リアルタイム性が求められるのはもちろん、データ損失は一切許されず、計画停止もゼロであること。そして何より、勘定系を停止させないことが不可欠です。

「ヘッドレス・コア」

これを踏まえ、次世代の銀行システムは、そのスコープを慎重に定義することが重要です。メインフレームシステムは、コア部分が「空洞化」して機能が低下してしまうという問題を抱えています。一方、第3世代のシステムは、インターフェースと密結合しすぎているためにブラックボックス化し、結果として変更が困難になっています。現在、銀行が自社の変革ニーズを表現するために使い始めている新しい言葉が「ヘッドレス・コア」です。

第4世代のシステムがどのようなものであるかを具体的にイメージするために、前世代のシステムに見られる典型的な機能を見てみましょう。

Table 1: typical characteristics of generational core banking systems. It’s worth noting that different products in within each generation will typically vary (both better and worse) for each attribute — View fullsize表1：世代別勘定系システムの典型的な特徴。なお、各世代内の製品によって、各属性の良し悪しにはばらつきがあることに留意してください。

なぜ今なのでしょうか。

クラウドやマイクロサービスアーキテクチャは、つい最近まで「最先端」とされていました。しかし、その最先端技術が成熟し、標準的な手法として定着するにつれ、状況は急速に変化しています。クラウドベンダーは現在、規制当局と緊密に連携し、ネットワークの高速化と信頼性向上に伴い、インフラへの投資を加速させています。多くの銀行がすでにクラウド環境で本番システムを稼働させています。メインフレーム市場を支配してきた企業もこの変化に気づいており、IBMが最近発表した「世界初の金融サービス向けパブリッククラウド」の立ち上げはその一例です。Kubernetes、Istio、Kafkaといった、かつては理論上の存在だった分散コンピューティングを実用化するツールやフレームワークも登場しています。さらに、Google SpannerやCockroachDBといったNewSQLデータベースの人気が高まっています。これらは一般的にクォーラムベースの整合性を採用しており、どのノードに対しても書き込みが可能なため、データベースがアプリケーションとともにスケールし、真の線形スケーラビリティへの道が開かれました。その結果、私たちは間違いなく、小規模なコミュニティバンクから世界最大級のティア1銀行まで、あらゆるニーズに対応する第4世代の勘定系システムの黎明期という転換点に立っているのです。

Vault Core - 第4世代の勘定系プラットフォーム

Thought Machineにおいて、私たちが Vault Coreの開発に着手したとき、私たちはその課題を理解すると同時に、大きなチャンスがあることも認識していました。私たちは、正確性を犠牲にしたり、勘定系を停止させたりすることなく、分散環境で効率的に動作するシステムを一から慎重に設計しました。これを実現するためには、エンジニアリングとプロダクトに重点を置く組織であり続けることが不可欠であると確信していました。

私たちは、Vault Coreを、データ損失を一切発生させずに、妥当なレイテンシで高スループットを処理できるように設計しました。分散システムのエンジニアなら誰でも知っているように、システム特性の適切なバランスを見つけることは、トレードオフのゲームです。設計上のあらゆる決定は、スループット、レイテンシ、可用性、耐久性といった主要なシステム属性のトレードオフを伴います。物理法則が示す通り、すべてを完璧に満たすことは不可能です。Vaultは、適切な場所で適切なトレードオフを選択しています。

本シリーズの第1回は以上です。次回からは、Vault Coreの構築に使用したアーキテクチャパターンについて、技術的な深掘りを行っていきます。システム全体をどのように「全体的な整合性（ホリスティック・コンシステンシー）」として捉えることができるか、また、可能な限り結果整合性を活用しつつ、必要な場合には強力な整合性をどのように確保するかを探ります。さらに、シェアードナッシングアーキテクチャ、非同期／イベントベース処理、選択的バックプレッシャーといった確立されたパターンを活用して、システムをどのようにスケールさせるかについても解説します。また、冪等性を伴う「少なくとも1回（at-least-once）」の配信、リソースのバイテンポラリティ、楽観的ロックといったアプローチを用いて、どのように正確性を維持しているかについても触れます。次回のブログ記事では、ベクトルクロックと楽観的ロックを活用して、コアトランザクション処理パイプラインをスケールさせる方法について詳しく解説します。

———

Vault Coreの詳細はこちらをご覧ください。