銀行の基幹系システムはなぜ古臭いのか？
おはよう人類。
こういう話を書いた。
タイトル詐欺である。今回も反省せずに続きといきたい。
前回も示したが、ざっくりとした銀行の基幹系システムは「勘定系」「情報系」「チャネル系」の三つの構成になっているという図が上である。ざっくりとしたものなので、実際にはもっと複雑(特にメガバンクでは)だし、これがあるのにアレがない、とかいったものはある。細かいところを気にしすぎると禿げるぞ。
今回は、銀行の基幹系がなぜ古臭いのかという話をしたい。古臭いと言ってもいろいろあって、特にエンジニア界隈からは「メインフレームを使ってる」とか「COBOLみたいなカビの生えた古代言語を使ってる」とか、とにかくイケてないシステムの代表例のように言われることが多い。対して、預金者の側からはネットとの親和性だとかサービス面の不満からくるイケてないという話が多いと思うのだが、これはどちらかというとシステムの話ではなくて、サービス設計とかその背景になるビジネスモデルの話になるので今回は触れない。
銀行でメインフレームやCOBOLを使っているのは一部だけ
かつて銀行では多数のメインフレームが運用されていて、最盛期の90年代後半のある都市銀行では100台近くのメインフレームが使われていた。ただ、価格性能比が優れたオープン系システム(UNIX、Windows、Linux)などのサーバに徐々に置き換えが進んだ結果、現在もメインフレームが使われているという領域は、銀行基幹系システムの中でも勘定系周辺に限定されている。
メインフレームの特徴として、高い信頼性、サポートライフサイクルの長さ、圧倒的な処理性能といったものがあるが、互換性の高さというのも重要である。銀行のシステムは、特に勘定系では10年近くHWを入れ替えずに運用されることが多く、最長で20年運用したという例もある。こういった長期運用を高い信頼性の元で実現するには、コスト的にはメインフレームの方が安くて最適であることが多い。逆に言えば、情報系やチャネル系の多くはもっと短いライフサイクルでよく、水平分散型アーキテクチャが取りやすいので、現在ではほとんどがオープン系サーバで構築されている。
オープン系に置き換えられた領域でも、ハードウェア的にはメインフレームを使っている例もある。最近のメインフレームでは、Linuxを動かすことができるので1台のメインフレームで多数のオープン系サーバを仮想化したうえで自社のデータセンタで統合運用するという例もある。クラウド化するよりも、レイテンシの確保が容易で責任分岐点も明確になりやすいというメリットもある。
ただ、メインフレームのHWでオープン系OSを動かすだけでは、元々メインフレームが実現している性能や信頼性、高い互換性は実現できない(ハードウェア的な信頼性は確保できるけど)。勘定系のような重要で特殊なシステムでは、メインフレームOSと専用のミドルウェアが使われる例が多い。
COBOLは結構新しい方？
メインフレームというと、COBOLを思い浮かべる人が多いかと思うが、銀行の勘定系システムでは元々COBOLはあまり使われていなかった。勘定系オンラインシステムでは、長いこと性能要求からアセンブラやPL/Iなどのレガシー言語が多く使われていた。
メインフレームのCPUはCISCプロセッサである。メインフレームのアセンブラは、長年のアーキテクチャの拡張で豊富な命令体系を備えていて、アセンブラだけで相当複雑なシステムが構築可能だった。また、オンラインシステムのデータ管理モデルはVSAMというファイルシステム上で構築されたファイルを直接プログラムから管理する方式が多かった。といっても、VSAMはISAMと違ってトランザクションをサポートするファイルシステムで、プログラム上で容易にオンラインシステムやデータベースを構築できる(VSAMをサポートするトランザクションモニタも数多くある)。
さすがに、VSAMベースのシステムは減っているが、ネット銀行などを除いて勘定系システムのほとんどがIBM IMSなどの階層型データモデルを使っている。IMS上で構築されたIBM SAILは、世界中の金融機関で使われている金融トランザクション・ミドルウェアで、かつてはPL/IやDL/I(IMS専用の問い合わせ言語。PL/Iっぽい)で構築されていたが、2000年くらいからCOBOLをサポートするようになって、こういったレガシー言語はCOBOLで置き換えられた。
一方で、情報系などのライフサイクルが短くて、オープンアーキテクチャが多く使われているシステムでは、Javaが主流になっている。Webとの親和性が高いという理由もあるのだが、基幹系で使うには性能がそこそこ良く、COBOLとメインフレームの組み合わせほどではないが、互換性も取りやすい。勘定系でも新規構築されるシステムでは、Javaが使われることが多くなっている。メインフレームでも強力なJavaサポートがあり、Java専用プロセッサやIBM製のVMもあるのでかなりポピュラーな存在だ。
銀行の勘定系は規模がとても大きい
他方、ネット銀行や一部の地銀向けで使われる勘定系パッケージでは、RDBMSが使われることが多く、JavaやC言語が多く使われている。代表的な例だと、Oracle Flexcubeや富士通W-Bank、日立オープン勘定系システムなんかも登場してきた。日本ではほとんど使われていないが、勘定系パッケージで世界シェアトップのTemenos T24などはパブリッククラウドをサポートしている。国内でも、日本ユニシスのBankVisonがAzure対応を、富士通FBaaSがソニー銀行向けにAWS/Amazon Aurora対応を表明していて現在構築中でもある。
ただ、大手の地銀やメガバンクではRDBMSと今どきの開発言語で再構築するのは難しい。みずほ銀行が新規に構築した勘定系システムMINORIでも、最も要件が厳しい流動預金システムの構築ではSAILとIMSの組み合わせで構築している。
これはなぜかというと、一つはオープン系システムに適した金融トランザクション・ミドルウェアが少ない点だ。IBMのNEFSSや、JRI(SMFGのシステム子会社)のOpenDIOSA、日本ユニシスのMIDMOST、その他アクセンチュアなども手掛けているが、金融システムに適合した高信頼性ミドルウェアがあまりない。その上、地銀と言えども規模がかなりでかい。
地方銀行では、口座数が100万から大きいところでは800万口座ちかいし、メガバンクともなれば1000万から5000万近くにもなる。ピーク時秒間1万近いトランザクションが流れて、しかも複数のインメモリDB(メインフレームは得意)をなめるような処理が多い。新規で作れなくもないが、とてつもない費用が必要になる。構築だけで銀行経営が傾くレベルの話になる。
だから、古くから継承されたプログラムを安定的に稼働するメインフレームがプラットフォームとして選ばれ、古いプログラムを少しづつ置き換えていくという手法がとられる場合が多い。あまり変化点が少なくて、長期に使われる領域ではCOBOLが、新規で変化が多くてWebとの親和性が要求されるような分野ではJavaといった使い分けが一般化している。
大手銀行のシステムはどうなっているか？
さて、ざっくりとしてふわっとした銀行システムの話をしてきたのだが、大手銀行では具体的にはどういう実装をしているか。まぁこれもふわっとした話なのだけど、勘定系の構成については各行考え方が違っていて面白いのでちょっと概略だけ紹介したい。
まず、最大手の三菱UFJ銀行の基幹系システムから。さっくりとした構成は、最初に示した勘定系のモデル図と似ている。口座数は、ゆうちょ銀行に次いで多い4500万口座を管理し、国内のほとんどの大手企業と取引するホールセール部門を有し、海外事業にも積極的というオールマイティな銀行でもある。システムとしては、HUBと書かれたEAI/ESBシステム(IBM MQ)をベースに各システムが疎結合化されている。
勘定系を中心に各システムが密結合されていた時代とは違い、HUBを中心として疎結合されたシステムでは、HUBに送る通信電文を標準化して、各システムをサービスとして扱いやすくなる(密結合されていると周辺系のサービス変更に全部勘定系のプログラムに手を入れる必要がある)。こういったシステム構成をハブ・アンド・スポークモデルと呼び、ここ20年くらいの大手銀行のシステムや一般企業の大規模システムでは一般化している構成だ。
勘定系システムは、SAILベースで旧三菱銀行がIBMに特注したIMSのバージョンが使われている。複数のメインフレームを束ねたクラスタリング構成で、同じ構成の待機系システム(コールドスタンバイ機)をバッチ更新機として、一定間隔で本番系(更新系)と待機系を切り替える構成になっている。80年代に最初のシステムが構築されてから、旧あさひ銀行のCAP(現在のりそな銀行の基幹系システム)や、Chanceなど他のシステムにも強い影響を与えたシステムでオーソドックだが信頼性の高いシステムだ。
三井住友銀行(SMBC)のシステムは、三菱UFJとは異なり勘定系システムを一定の支店の集団(店群)に分割して、店群サーバ同士が独立したシステムのようにふるまう水平分散アーキテクチャを採用している。水平分散アーキテクチャの利点は、ハードウェアの構成とノード間の通信量は増えるが、ノードを自由に足すことで大規模化が容易で、将来的なオープンアーキテクチャへの置き換えも視野に入っている。また、バッチ処理をすべてオンラインで実行するバッチレスシステム化も早くから進んでいて、バッチ障害の危険性を極小化している。
現在から見ても先進的に思えるが、元になるシステムが構築されたのは1994年と割と古く、その間でもHWの入れ替えや、さくら銀行との合併に伴う規模の拡大といった大きなイベントも発生したが、他の銀行よりも1桁少ない構築費用で済んでいるのは設計の先進性にあると思う。
現行システムは、2015年に稼働開始した3世代目のシステムで、勘定系のHWにはNEC製の国産メインフレームACOS4(iPX9800 A100)を採用している。3世代目のシステムから、東日本と西日本のデータセンターを両方本番のセンターとして、リアルタイムで相互のセンターにバックアップを取る方式となった。2025年頃をめどに、現行システムをベースに次期システムに置き換える予定。
みずほ銀行の基礎勘定系システムMINORIは、2011年の大規模システム障害を契機に、旧みずほ銀行のSTEPSと旧みずほコーポレート銀行のC-Baseを全く別の第三のシステムを新規構築する形で構築した新しいシステムだ。流動預金系システムと取引メイン・HUBが稼働する部分以外は、AIXやLinuxなどのオープン系システムとDb2やOracleなどのRDBMSで再構築されている。COBOLの使用範囲も流動預金系の一部だけに止められている。
MINORIの特徴は、三菱UFJの垂直統合・クラスタモデルや、SMBCの水平分散モデルとは異なり、勘定系の持っている機能をサービスに分割して疎結合化したSOAモデルを全面的に採用している。稼働しているハードウェアも、流動預金系以外は個別のシステムに分割できていて、開発ベンターも流動預金系の場合はシステムは富士通だが、稼働HWはIBMメインフレームと、調達と開発を分離するマルチベンダー開発体制で構築された。
SOAモデルの良い点は、勘定系の持つ機能を完全にサービスに分離して、新しいサービスや規模の拡大にも柔軟に対応できる点で、今後機能ごとに別プラットフォームに移行したり、クラウド化も容易となる。今後は、こういったアーキテクチャのシステムが主流になるとは思うが、システムの実現している機能はちょっと周回遅れな感じがある。最新技術で20年前のシステム要件を実装したみたいな。
核となる流動預金システムはActive-Activeスタンバイ構成のメインフレームクラスタで構成されている。各サービスにメッセージブローキングする取引メインや、通信インターフェースとなるHUBなども同じメインフレームで動作していて、メインフレームの使用台数は待機系も含めて4台と極めて少ない。その他のシステムは、UNIXやIA系サーバのクラスタ構成で、「みずほクラウド」と呼ばれている各ベンダーが提供するプライベートクラウド上で動作している。なお、他の二行とは異なり、稼働センターは首都圏の別の場所に設置されているので、東日本が停電したらどうするつもりなんでしょうね？
今回はちょっと長く書きすぎた。単調で乱文だったので読みにくいことこの上なかったと思うが、次からは気を付けていきたい。